Novo Nordisk Breach: How a Leaked GitHub Token Exposed the Exact Ozempic Formula
Published by Pentesty · Data Breach · Pharma · Source Code Leak
A group calling itself FulcrumSec says it stole roughly 1.3 TB of data from Novo Nordisk, the Danish pharmaceutical company behind Ozempic and Wegovy. After the company reportedly refused to pay a US$ 25 million ransom, the group started publishing a 264 GB sample of the haul. The leaked material allegedly includes source code, clinical trial records, employee and patient data, and the formula for Ozempic itself. The reported way in was a single GitHub token that gave the attackers two months of access to internal repositories before anyone noticed.
What makes this incident worth reading carefully is how ordinary the failure was. There is no zero-day, no nation-state operation, no novel technique. Just a credential that should not have been usable from outside, and no one watching the door.
What FulcrumSec Claims to Have
According to statements the group made to DataBreaches.Net and reporting from g1, the haul includes:
- Source code and proprietary technical documentation for launched and unreleased medications.
- The exact formula of Ozempic, plus material on other drugs in the pipeline.
- Clinical trial records covering roughly 11,500 patients.
- Personal data of thousands of employees, doctors, and patients.
- Details about processing facilities and internal AI models used by the company.
The group says it pulled more than 700,000 files (about 1.3 TB), and so far released around 264 GB. It also said it will hold back employee and patient files for now, which is the usual leverage point in pay-or-leak extortion. We covered that pattern in detail in our breakdown of the ShinyHunters extortion methodology.
Novo Nordisk confirmed on June 11 that it suffered a cybersecurity incident involving unauthorized access to a limited number of internal systems and to personal data of some clinical-trial patients. The company told Reuters it is “in contact with the competent authorities” and that its main platforms are running normally.
How They Got In: One GitHub Token, Two Months of Access
According to FulcrumSec, the access started in March with a GitHub personal access token that allowed them to clone internal repositories. From there they stayed inside the environment for roughly two months before exfiltrating most of the data.
The group also went out of its way to mock the company, claiming that critical systems were protected by passwords like “novo123”. Whether that exact string is accurate or not, the larger picture is hard to argue with. When one developer credential opens the door to source code, internal AI models and customer data, most of the rest of a security program stops mattering.
The shape of this attack has been showing up all year. A leaked token with too much scope, no alerting on unusual repository access, and weeks of dwell time before anyone notices. The same dynamics appear in our cloud misconfiguration analysis for 2026 and in the wave of AI-powered attacks that now automate the search for these footholds.
Why a Drug Formula Leak Is Different
When customer data leaks from a delivery app or a learning platform, the damage is real, but most of it plays out downstream as phishing, account takeover and fraud. A pharmaceutical IP package is a different kind of problem.
- Intellectual property does not get rotated. A password can be changed in an afternoon. A formula, once public, stays public.
- Counterfeit risk grows. Detailed formulation and process documentation makes it easier for illegal manufacturers to produce injectables that millions of patients depend on.
- Trial subjects sit in a fragile position. Clinical trial data often links a name to a specific medical condition. That combination is useful for blackmail, insurance discrimination and targeted phishing. The downstream risk is similar to what we wrote about in the iFood leak analysis, except with health context attached.
- Internal AI models become a second attack surface. Model weights, training data and prompts in the wrong hands give competitors and threat actors a starting point that took the original team years to build.
What Engineering Teams Should Take from This
The fixes that would have prevented this incident are well known. They keep getting skipped because they are boring and because nothing breaks when you skip them, until something breaks badly.
Treat source-code credentials as crown jewels
Personal access tokens, deploy keys and CI tokens are bearer credentials with read access to your intellectual property. Short expirations, narrow scopes, IP allowlists and SSO-backed enterprise accounts should be the default. Rotate often, and revoke on offboarding the same day.
Kill weak and shared passwords at the source
“novo123” is easy to laugh at, but the underlying pattern (admin accounts on internal systems with guessable or shared passwords) shows up in nearly every breach we read. Enforce a password manager across the organization, block common patterns at policy level, and require phishing-resistant MFA on anything that touches code, cloud or data. This is OWASP A07: Identification and Authentication Failures in plain language.
Alert on bulk clone behavior, not just on logins
A token that quietly clones hundreds of repositories over weeks is one of the most obvious signals you can collect, but only if someone is listening. Build alerting around abnormal repo access patterns, unusual API token usage and large outbound data flows. Two months of dwell time is rarely the attacker being clever. It is usually the defender not having the dashboard.
Scan your own repos like an attacker would
Secret scanning, dependency scanning and SCA are not optional for any team shipping code. If your internal repositories contain hard-coded credentials, API keys or production database strings, one stolen token is enough to take the entire kingdom. That is exactly what happened here.
Assume breach and rehearse the response
Companies that handle these incidents best are not the ones that avoid them. They are the ones that have practiced. From Rockstar's ransom refusal to the BTG Pactual case, the pattern is the same: a clear legal posture, fast disclosure and an incident response playbook written before the deadline shows up.
Should Novo Nordisk Have Paid?
Reporting suggests Novo Nordisk did not pay the US$ 25 million demand, which is what triggered the public leak. From the outside, that looks like the right call. Payment never guarantees deletion, it funds the next attack, and once a drug formula and clinical data exist in criminal hands, there is no scenario where the company “buys back” the secret. The same logic played out in public when Rockstar refused to pay ShinyHunters and the predicted leak happened anyway. Refusing extortion is painful. Paying it tends to be worse.
The real failure was upstream, in the conditions that turned one GitHub token into a master key. A clean response is not the same thing as a clean security posture. We made the same argument in Why Your Pentest Report Is Lying to You: a compliance check does not catch the kind of attack path that played out here.
What Patients and Trial Subjects Should Do
Even if the attackers say they will not publish patient and employee files, the safe assumption is that the data is already in adversarial hands. If you have ever taken part in a Novo Nordisk clinical trial or you are a current patient, treat any unsolicited contact about it as suspicious.
- Expect targeted phishing referencing your treatment, your doctor or your trial. Do not click links or share information over phone, SMS or email.
- Verify any “official” communicationthrough channels you already trust, such as your physician's office, the trial coordinator, or the company's contact page typed into the browser by hand.
- Watch financial accounts and pharmacy benefits. Sensitive health data can feed insurance fraud and prescription scams.
- Use unique passwords and MFA on any portal you use for health or insurance. Credential reuse is what turns one leak into many, as we covered in the Udemy breach analysis.
How pentesty.co Helps Companies Avoid This
The Novo Nordisk case will be cited for years as the story of one leaked token, two months of dwell time and a billion-dollar molecule landing on the open internet. The harder truth is that similar conditions exist inside a lot of engineering organizations right now. They simply have not been tested.
pentesty.co helps teams find the path an attacker would actually take before one does. Through continuous, AI-driven penetration testing, the platform can:
- Map your external attack surface and find leaked credentials, exposed tokens and forgotten development assets.
- Simulate how an attacker would pivot from a single foothold (a personal access token, a weak admin password) into production data and source code.
- Rank issues by business impact so your team works on what closes real attack paths instead of grinding through an unranked CVE list.
A full scan against a web application or API runs in under 10 minutes, with an audit-ready PDF at the end. No consultant queue, no waiting weeks for a deck. Our offensive security services are built around the same attacker-first mindset.
You do not get to choose whether someone tests your security. You only choose whether it is a paid pentester or an extortion crew with your source code. Pentesty.co is designed to make the first option fast enough that the second never has to be the default.
Related on Pentesty
Inside ShinyHunters: the extortion playbook →
The same pay-or-leak model FulcrumSec used against Novo Nordisk, mapped end to end across five phases.
Rockstar Games refused to pay. Here's what happened next →
The clearest public argument for why paying extortion almost never works, and the same calculation Novo Nordisk faced.
iFood “mega leak” alert →
Different industry, identical pattern: pay-or-leak extortion against a brand the public trusts with personal data.
Cloud security misconfigurations in 2026 →
Why over-permissive tokens and unmonitored access paths still drive most modern breaches.
OWASP Top 10: the developer's guide →
Weak passwords and leaked tokens map directly to OWASP A07, with concrete examples of the safer version.
Why your pentest report is lying to you →
A passed audit doesn't catch a leaked GitHub token. Real attack-path testing does.
TL;DR
Find the leaked token before someone else does. Request early access to Pentesty.
