Novo Nordisk Breach: One GitHub Token, 1.3TB Gone

Novo Nordisk, the Danish pharmaceutical company behind Ozempic and Wegovy, confirmed on 11 June that attackers had reached a "limited number" of internal systems and accessed pseudonymised clinical trial data: patient IDs, dates of birth, biomarkers, lifestyle factors, and contact details for associated healthcare professionals. That's the official version.

The group claiming responsibility, FulcrumSec, tells a noticeably bigger story. According to information shared with DataBreaches.Net, the attackers were inside the network for more than two months, left with around 700,000 files totalling 1.3TB, and demanded a $25 million ransom. The alleged haul includes source code, research on marketed and unreleased drugs, internal AI models, manufacturing records, and data on roughly 11,500 trial participants. Novo Nordisk reportedly declined to pay, and FulcrumSec has begun leaking. A second crew, TheUSERS007, claims a separate intrusion in early June targeting AI material.

The entry point is the interesting bit

FulcrumSec says it found a high-privilege GitHub personal access token sitting in client-side JavaScript on an obscure Novo Nordisk subdomain. From there it cloned private repositories, scooped up more credentials lying around in the code, and pivoted deeper. No perimeter was dramatically breached. The attackers logged in as a trusted developer and the system behaved exactly as it was built to.

That is the part that keeps catching organisations out. Code repositories are not just where source lives. They hold:

• infrastructure-as-code definitions
• deployment pipelines and CI/CD configs
• integration details and API wiring
• the documentation that explains how everything connects

As Matt Kimpel of Magna5 put it, getting into the repo is closer to opening the building plans than opening a filing cabinet. And the machine credentials scattered through those repos, API tokens, service accounts, deployment keys, rarely have a clear owner, a rotation schedule, or anyone watching them. They get created and forgotten.

Why one token becomes two months

When the access an attacker stumbles onto already reaches everywhere, there is no need to escalate privileges or move carefully. Branch approvals, code review and pipeline gating all assume the right person is doing the work. That assumption holds up poorly when the wrong person is holding a valid credential nobody knew existed.

There's also the small matter of attribution. Logs will show the developer's identity doing developer things, in business hours, from a reasonable place. The signal that something is wrong only emerges if someone is comparing behaviour against what that developer normally does, on what systems, with what cadence. Most organisations are not doing that for human accounts, let alone for the long tail of tokens issued years ago by someone who has since left.

The boring controls that would have helped

None of the fixes here are exotic. Secret scanning on every push and pull request. Short-lived tokens with narrow scopes. An inventory that knows which tokens exist, who owns them, and when they last rotated. Egress monitoring on the repo platform itself, because 700,000 files do not leave quietly if anyone is looking.

And the obvious one: do not embed credentials in client-side JavaScript. The browser is not a vault. Anything that ships to a user's machine ships to an attacker's machine too. That a token with the keys to the kingdom was sitting in a public-facing script is the kind of detail that turns a breach story into a cautionary tale told at conferences for years.