What the Coverage Is Getting Wrong: The Novo Nordisk Breach Started in a JavaScript File, Not GitHub
Inhaltsübersicht
FulcrumSec claimed a $25 million ransom from Novo Nordisk after spending 2.5 months inside their network. Headlines blamed GitHub. They are looking at the wrong entry point.
The real initial access came from two web pages, live, public-facing, and apparently forgotten by everyone except the attacker.
What the coverage is getting wrong
Most outlets reporting on this breach trace the initial access to a GitHub access token discovered in March. That token did exist. FulcrumSec did use it. But it was not where the story starts.
According to our analysis of the modus operandi, the attackers found two secrets exposed in the frontend code of two development subdomains of novonordisk.com:
- An Azure DevOps token embedded in a minified JavaScript bundle on
dev.nnedl.pub.aws.novonordisk.com - A GitHub Personal Access Token (PAT) in client-side code on
datahub-sand.novonordisk.com
Both assets were sandbox or development environments never intended to be publicly accessible. Both had drifted outside any active monitoring perimeter. Any browser visiting those pages would download the JavaScript bundle containing those credentials in plain text.
The GitHub repository phase everyone is reporting came second. The web application exposure came first.
How FulcrumSec turned two tokens into 1.3TB
From those two initial credentials, the attack chain unfolded in stages.
The GitHub PAT gave FulcrumSec access to private repositories. Inside those repositories, they found what security teams call secrets sprawl: dozens of hard-coded production credentials left in source code across teams and projects. API tokens, database credentials, service account keys. Each one opened another door.
Combined with an alg:none vulnerability on a COSMOS clinical API in a development environment — a well-documented JWT authentication bypass that allows tokens to be accepted without signature verification — the attackers propagated laterally across GitHub, Azure DevOps, AWS, HuggingFace, and Okta.
The claimed persistence window was approximately 2.5 months. GitHub flagged unusual activity after roughly 2 weeks. Azure after roughly 3. HuggingFace and Okta were reportedly never detected before the breach was disclosed.
Novo Nordisk disclosed the incident on June 11, describing unauthorized access to “a limited number of internal IT systems.” FulcrumSec claimed responsibility two days later and has since posted samples of the alleged 1.3TB on their dark web leak site, including login screenshots, clinical trial information, and AI model details.
The claimed scope covers 4,748 code repositories, the CDD Vault drug discovery database, 33 proprietary AI models, undisclosed R&D programs, manufacturing processes, PII on 163,234 employees, and approximately 11,500 patients.
This is FulcrumSec’s signature
The group surfaced in September 2025 and has already built a documented track record. Before we get into what happened at Novo Nordisk, here is what they have gotten up to.
2025
- September 2025: FulcrumSec is first observed on the threat landscape, targeting enterprise cloud environments across technology, professional services, and financial sectors. No ransomware, no encryption. Pure exfiltrate-and-extort.
- November 2025: US media company Blavity is listed as an early victim.
- January 2026: US healthcare company Lena Health is hit, despite FulcrumSec’s own stated commitment to never target healthcare organizations.
- February 2026: youX (formerly DRIVE IQ), an Australian FinTech platform, loses approximately 300GB of data covering 444,000 borrowers and nearly 800 broker organizations. Entry point: unrotated credentials dating back to 2021
- February 2026: LexisNexis is breached via an unpatched React frontend application on AWS. Excessive container permissions hand FulcrumSec access to Redshift databases and plaintext credentials stored in AWS Secrets Manager.
- April 2026: FulcrumSec dumps 21 mid-tier victims in a single bulk posting on their leak site, padding their public record while quietly working a much larger target.
- June 2026: Novo Nordisk. The biggest target they have ever claimed. $25 million ransom demand. 1.3TB allegedly exfiltrated. Novo Nordisk refuses to pay.
Why your repository scanner would have missed this
Most organizations today have some form of code scanning. Tools that watch public repositories for accidentally committed secrets. Pre-commit hooks. Pipeline checks that flag credentials before a push. These controls matter. What is worth highlight is that none of them would have caught this.
The secrets were not leaked into a public repository. They were served by web applications, embedded in the JavaScript that any browser downloads when visiting those pages. The assets hosting them were development subdomains, the kind that accumulate quietly over years of product cycles, assigned to a sprint, left resolving, left out of the next security review.
No repository scanner monitors what a web application serves at runtime! No periodic penetration test reliably surfaces a two-year-old subdomain that no one remembers owning. The exposure surface here was the external attack surface: forgotten assets, live and reachable, delivering credentials to anyone who looked at the page source.
This is precisely the gap that Angriffsflächenmanagement is designed to address: continuous visibility into what your internet-facing assets are, what they expose, and what they are actively delivering to visitors.
The pharmaceutical sector IS a high-value target for exactly this reason
Novo Nordisk is not an outlier as pharmaceutical companies consistently rank among the most targeted sectors in external attack surface breaches, for reasons that make technical sense.
Large pharma organizations run complex, distributed development environments. They of course have research divisions, clinical trial platforms, manufacturing systems, and commercial operations, often on separate infrastructure, often accumulated through acquisitions. The attack surface is wide, the internal perimeter is porous by design, and the value of what sits inside — drug IP, clinical data, AI models trained on proprietary research — creates obvious incentives for threat actors willing to be patient.
FulcrumSec spent 2.5 months inside Novo Nordisk’s environment. The dwell time was not a failure of detection tools alone, but it certainly reflects an environment where a threat actor could move laterally, find new credentials, and continue operating even after partial detection.
Below are the six findings from our analysis of the modus operandi, what failed in each case, and what security teams should act on.
Lessons learned: What this breach actually teaches
This is where the Novo Nordisk case becomes genuinely instructive, beyond the headline numbers.
| Lesson | What went wrong | What to fix |
|---|---|---|
| Forgotten assets are live attack surface | Two development subdomains stopped being actively maintained but kept resolving. Their JavaScript kept loading. Their embedded secrets kept working. | Continuous subdomain enumeration and content monitoring. “Out of scope for your team” does not mean out of scope for an attacker. |
| Minified JavaScript is not obfuscated | Minification removes whitespace and shortens variable names. It does not encrypt values. Any token in frontend code is readable by anyone who views the page source. | Secret scanning must run against compiled output, not just source files. Add it to the build pipeline. |
| One exposed token becomes dozens | The GitHub PAT opened private repositories. Inside those repos were dozens of additional hard-coded production credentials across teams and projects. | Secrets management is not a one-time audit. It requires continuous detection of new credentials committed to code. |
| alg:none on a dev API in 2026 | A JWT bypass documented since 2015 was present on a development API connected to production data. Security reviews were not applied consistently to non-production environments. | Treat any development environment with access to real data as production from a security controls perspective. |
| Connected platforms go unmonitored | HuggingFace and Okta were reportedly never detected before public disclosure. Absence of an alert is not evidence that nothing happened. | Extend monitoring to identity providers and AI model hosting environments. Every platform an attacker can reach is a detection surface. |
| Token rotation is not the lesson | Any token reachable on the public internet, in any asset your organization has ever owned, is a potential entry point. Rotating after a breach is reactive. | Maintain a continuous, outside-in view of your attack surface, including what your assets expose and whether that exposure is intentional. |
The questions worth asking now
If you are a security leader reading this, the productive questions are not about GitHub policies or token rotation. They are:
Which subdomains are we currently serving to the public internet that were not built for public access? Are any of them development, sandbox, or staging environments? What does the JavaScript served by those pages contain? When did anyone last audit their content?
CybelAngel’s external attack surface monitoring continuously maps exposed assets, including the content they deliver. We scan from the outside, the way an attacker would, so that forgotten subdomains serving live credentials appear in your console before they appear on a dark web leak site.
Über den Autor
