In March 2026, an extortion group known as FulcrumSec gained access to hundreds of private Novo Nordisk repositories using a GitHub personal access token that was sitting in client-side JavaScript. The token was not stolen through phishing or pulled from a breached secrets manager. It was embedded in the code itself, which is where machine credentials tend to end up when no one treats them as identities.

What followed, based on the group's own published claims as reported by Heise.de, SecurityWeek, and GovInfoSecurity, was more than two months of lateral movement through a credential graph that Novo Nordisk's tooling had never inventoried. By the time the company disclosed the incident on June 11, FulcrumSec claimed to have taken 4,748 source code repositories, more than 30 proprietary AI models, data on over 163,000 employees, and the formula for an experimental obesity drug. Novo Nordisk confirmed unauthorized access and the exposure of pseudonymized clinical trial data. Reuters reported it could not verify the rest.

This is not a story about a sophisticated attack. It is a story about a credential that was never governed.

The credential nobody was governing

The GitHub token at the center of this incident was a non-human identity, even though nobody in the organization was treating it as one. No employee was meaningfully attached to it. It never appeared in a quarterly access review, and it was never caught by an offboarding process when the team that created it moved on. It simply lived in a JavaScript bundle, scoped to hundreds of private repositories, with no expiry date and no record of what normal use should look like. This is what secrets sprawl looks like in practice. Credentials accumulate across codebases because engineers tend to think of them as configuration values rather than identities, and that distinction has real consequences. A configuration value carries no blast radius. A long-lived, broadly scoped token with read access to hundreds of production repositories carries an enormous one.

The danger of that token was never the access it granted on its own. It was the access it unlocked by exposing every other credential stored in the repositories it could reach. FulcrumSec described this as "spidering," which is not a novel technique so much as the predictable result of secrets sprawl meeting an attacker who knows how to read code.

The code was a directory of working credentials

Source code is more than logic. A repository is also a running record of everything the code connects to: every service it talks to, every environment it has been deployed into, and every credential that was hardcoded to make those connections work. According to FulcrumSec's claims reported by GovInfoSecurity, the initial repositories yieldedto be governed that the group then used to move deeper into the environment. For an attacker, this means a collection of repositories is not a network to scan. It is an identity graph to read. FulcrumSec did not look for open ports. It read the code, pulled out the machine identities embedded in it, and used the access those identities had never been scoped down from. Across 4,748 repositories, that graph was vast.

The architectural point here is worth stating plainly. Stealing source code and stealing the credentials embedded in that source code are not the same thing. One hands an attacker the logic. The other hands them working access to every system the logic was ever connected to. FulcrumSec claims this gave them reach into drug discovery databases, clinical trial systems, and active development programs, none of which Novo Nordisk has confirmed.

Why finding the breach did not stop it

According to Pharmaphorum, again citing FulcrumSec's claims, the group continued harvesting credentials and exfiltrating data for roughly two and a half months after Novo Nordisk first identified the breach. The company has not confirmed that timeline, but the underlying problem it points to is real regardless of the exact dates. Secrets sprawl does not resolve the moment you find the way in. Every credential already embedded across repositories, build pipelines, and environment files stays active until someone explicitly rotates it. Identifying a breach closes the original door, but it does nothing to the set of credentials the attacker has already collected and can keep using.

This is why blast radius, rather than entry point, is the right thing to measure during incident response. The useful question is not how the attacker got in. It is what they can still reach using everything they gathered before anyone noticed. Separately, Ransomnews ran its own analysis of infostealer logs tied to Novo Nordisk addresses and found hundreds of captured logins and nearly 3,000 active session cookies. A valid session cookie matters because it can resume an authenticated session without a password or a second factor, which means credentials sitting in those logs for weeks were part of the same exposed surface, not a separate issue.

Why the AI loss is different from a database breach

Novo Nordisk confirmed that pseudonymized clinical trial data was exposed, including patient IDs, biomarkers, and lifestyle factors, while noting that the data cannot identify patients on its own without separately held information that was not part of the incident. The claims about AI assets need to be treated more carefully, because Novo Nordisk has neither confirmed nor denied them. FulcrumSec published an inventory, reported by Heise.de and detailed further by Ransomnews, that included a large multimodal model checkpoint, proprietary training datasets, internal tooling, training run logs, and infrastructure configuration.

If that inventory is accurate, the loss is of a different kind from that of a typical database breach. A trained model, together with its training data and pipeline code, represents the distilled result of years of research, and it does not lose value when it leaks. A competitor or a state-backed lab that obtains it inherits the capability directly, and there is no equivalent to rotating a model's password once it has already been copied. Each of those AI systems also depends on its own layer of machine identities: the APIs that query the models, the storage that holds the data, and the pipelines that connect them. Almost none of it was designed with identity governance in mind.

The existing tools saw nothing wrong

None of Novo Nordisk's existing controls were positioned to catch this. Perimeter controls do not inspect repository contents for embedded credentials. SIEM tools watch for anomalous access, but a valid token operating at a moderate volume against a baseline that was never established will not trigger an alert. Endpoint detection does not detect server-side API calls made with legitimate credentials, and data loss prevention flags bulk transfers only after exfiltration is already underway.

The common thread is that none of these tools maintains an inventory of non-human identities, their scopes, or what each one can actually reach. When FulcrumSec used a valid GitHub token to clone repositories, every logging system recorded it as authorized access, because that is exactly what it looked like. The problem was not that detection was slow. The problem was that nothing in the environment treated machine credentials as identities that needed governing in the first place. Where token rotation policies existed at all, they applied only to human-facing service accounts, leaving credentials buried in JavaScript bundles entirely outside their reach.

The practices that close this gap

A few specific practices would have altered how this incident unfolded.

• The first is continuous secrets scanning with enforcement at commit and build time. A credential that never makes it into a repository cannot be harvested from one. Alongside that, organizations need a live inventory of every non-human identity across the environment, including tokens sitting in repositories and CI systems, with scope and expiry attached to each.
  ‍
• The second, unrelated to its intended purpose, is a signal that appears to be mapping the blast radius for each credential before an incident rather than during one. When the original token was identified as compromised, the question that mattered was what it could access and what other credentials lived in the repositories it could reach. Without an advanced map, answering that requires manual investigation across thousands of repositories while the attacker keeps working.
  ‍
• The third is replacing long-lived tokens with credentials that are provisioned just in time, scoped narrowly, and set to expire automatically. A token that expires in hours is worthless to an attacker who cloned the repository days earlier. The fourth is monitoring how non-human identities behave against an established baseline. A GitHub token suddenly reaching hundreds of repositories in a pattern that has nothing to do with its intended purpose is a signal that exists well before the spidering finishes. The only question is whether anything is watching for it.

Mapping the failure to a solution with Unosecur

Each stage of this incident maps to a gap in non-human identity governance that conventional tooling does not address. The entry point was a GitHub token scoped to hundreds of private repositories sitting in client-side code. Unosecur continuously inventories machine identities across cloud, SaaS, and developer environments, including the repository and CI systems where credentials accumulate, and flags any identity that holds far more access than it needs to function. A token with that scope profile would have stood out as a misconfiguration long before it was ever used against the company.

The propagation stage relied on credentials harvested from those repositories to reach production databases and AI infrastructure.

Unosecur maps what every machine identity can reach within its current scope, so that when a credential is compromised, the response scope is already defined rather than reconstructed by hand across thousands of repositories while data continues to leave. The persistence stage saw months of credential harvesting continue after discovery, because the credential surface was too scattered to shut down cleanly. Unosecur monitors how non-human identities deviate from their established baselines and flags the lateral movement this attack relied on. When that anomaly is caught, the attacker's window closes, rather than staying open until the investigation finally catches up.

Underneath all of it sat the same root condition: long-lived, broadly scoped machine identities with no expiry, no inventory, and no behavioral monitoring. Unosecur enforces least-privilege scoping and tracks how old each credential is, surfacing tokens that have outlived their policy before an attacker can find them. If you cannot say which machine identities exist in your environment, what they can reach, and what normal looks like for each one, you are operating with the same blind spots Novo Nordisk had.