It started with an access token.
Not the kind buried in a config file behind ten layers of CI/CD gates, but something that, by all accounts, should have stayed inside the developer’s machine. A GitHub token—easily generated, casually shared in logs or screenshots, and often left enabled long after the developer who created it moved on to the next sprint. This token gave attackers the first foothold in what’s now being described as one of the most brazen hack-and-leak operations in recent memory: a 1.3TB trove of source code, clinical trial data, AI models, and proprietary drug programs snatched from Novo Nordisk’s repositories.
The company confirmed a security incident last week, admitting that unauthorized access led to the copying of some non-public data. What it hasn’t confirmed—and what threat actor FulcrumSec is still claiming—is the full scope. According to the group, they’ve had eyes on Novo Nordisk’s internal systems for over two months. During that window, they say, they cloned repositories, harvested credentials, and built a map of the pharma giant’s digital infrastructure. When negotiations failed—and reports suggest Fulcrum was asking for $25 million—the data dump began.
Novo Nordisk, for its part, called the breach a “limited number of systems,” but the threat actor’s data inventory tells a different story. Leaked screenshots, shared in underground forums before being taken down, showed directory structures unmistakably belonging to the pharmaceutical behemoth: internal CI pipelines named after internal projects, test datasets tagged with European patient IDs (pseudonymized but still highly sensitive), and internal training sets that clearly included proprietary algorithms.
This wasn’t just a case of an exposed repo. This was the bridge from developer tooling to business-critical infrastructure, and it happened because someone left a token on.
How the Breach Unfolded: From Token to Threat
FulcrumSec’s entry vector was textbook credential theft, but with a twist that makes it especially dangerous for companies still treating developer identities as low-risk. The actor didn’t break into the CI server; they broke into the developer’s workflow. GitHub tokens are designed to let developers automate repetitive tasks—deploy a service, push a tag, trigger a test run—but they also act as identity tokens. Once you have one, you’re no longer just an outsider; you’re a “trusted” machine identity inside the system.
SecurityWeek reported that the actor exploited a misconfigured GitHub app that allowed overly broad permissions. In most cases, this kind of token would be scoped to a single repository or a narrow set of endpoints. In this instance, the app had been granted organization-wide access with read and write permissions across dozens of repositories, including internal ones that weren’t supposed to be publicly discoverable.
Once inside, FulcrumSec moved laterally with ease. GitHub tokens alone gave them access to repository metadata, but not much else—so they began mining commit histories and pull request descriptions for clues. Many teams still use Slack or internal chat to share sensitive context, but developers often copy that context into commit messages or PR descriptions for auditability. One such commit included a reference to “internal AI training pipeline,” which led the actor to an API endpoint they hadn’t seen before. From there, a few educated guesses and a bit of HTTP fuzzing got them into a service that was supposed to be behind an internal VPN.
The lesson isn’t “don’t use tokens.” It’s that tokens are identities—and once you treat them as such, the real story emerges: this breach wasn’t about code. It was about trust.
The Data That’s Gone—and What It Means for Patient Safety
The threat actor claimed 1.3 terabytes of stolen data, and the breakdown is deeply troubling for anyone relying on Novo Nordisk’s products. Here’s what we know so far, based on the fragments that made it into the open before being taken down:
-
Source code and production material: This includes both public repositories (which were copied, but no new code was injected) and internal tooling—custom scripts, deployment automation, and infrastructure-as-code definitions. One leaked screenshot showed what appeared to be CI/CD pipeline configurations for a manufacturing line, raising concerns about the integrity of production processes.
-
Clinical trial data (pseudonymized): The actor claimed access to trial metadata, including patient enrollment criteria and interim analysis summaries. While these records were pseudonymized, the combination of trial metadata with internal notes and statistical models could allow re-identification in some cases—a violation of GDPR’s data minimization principles.
-
Internal AI models: Novo Nordisk has been aggressively investing in machine learning for drug discovery, and internal documents suggest FulcrumSec gained access to trained models for its Dicerna RNAi pipeline. These aren’t just code; they include training datasets, hyperparameters, and validation metrics. If sold to a competitor, the value could run into hundreds of millions.
-
Proprietary drug programs: The leak included internal project boards, meeting notes, and roadmap documents for ongoing initiatives. In one case, a slide deck titled “Project X – Phase III Readiness” appeared in the dump, detailing timelines and efficacy targets for a yet-unapproved therapy.
-
Employee, doctor, and patient details: The actor claims to have harvested contact information for thousands of employees and healthcare providers. This isn’t just reputational risk; identity theft based on employee credentials could lead to convincing phishing attacks targeting Novo Nordisk’s sales force, who often have access to sensitive prescribing data.
Novo Nordisk has assured regulators and patients that no personally identifiable information (PII) was accessed, but the distinction between “pseudonymized trial data” and PII is increasingly thin when combined with other datasets. The European Data Protection Board has opened a preliminary inquiry, and share prices dropped 6% in after-hours trading—proof that investors aren’t buying the “limited impact” narrative just yet.
The Developer-First Mindset That Missed the Mark
This breach offers a masterclass in what happens when organizations treat developer tools as “safe.” For years, security teams built guardrails around production systems—firewalls, IAM roles, encryption at rest—but largely trusted developer identities because they’re internal. That’s the wrong assumption.
GitHub tokens are especially dangerous in this regard. They’re lightweight, easy to generate, and often distributed without the same controls you’d apply to a service account. Many teams still use personal access tokens (PATs) instead of fine-grained tokens with explicit scopes, and even when they do, those tokens often persist long after the developer who created them has left the team or changed responsibilities.
A few weeks before this breach, an internal audit at Novo Nordisk flagged a handful of tokens with no expiry set. But because these tokens were tied to active developers, they weren’t flagged as high-risk. The actor exploited exactly that gap: tokens with overly broad permissions, long expiration windows, and no audit trail of their usage beyond GitHub’s standard logs (which only record who created the token, not when it was used for what purpose).
The fix here isn’t “revoke all tokens.” It’s layered. First, enforce fine-grained permissions: GitHub now supports scoped tokens down to the repository or organization level. Second, rotate tokens on a schedule—not daily, but with clear expiration and automatic renewal for legitimate services. Third, add context-aware logging: not just “token XYZ was used,” but “token XYZ accessed repository ABC for purpose DEF at time T, based on pattern matching of the API endpoint and payloads.”
One small company in Scandinavia recently rolled out this exact stack—scoped tokens, scheduled rotation, and contextual logging—and found three dormant tokens that hadn’t been used in over a year. The actor who breached Novo Nordisk was active inside the system for two months; a similar stack might have caught them after the first access attempt.
Why FulcrumSec—and Others—Won’t Go Away
FulcrumSec isn’t some lone actor with a laptop and a vendetta. They’re part of a broader threat landscape that’s shifting rapidly: from “exfiltrate and sell” to “exfiltrate, hold hostage, and demand ransom.” The hack-and-leak model has already been popularized by groups like Lapsus$ and the more recent Cl0p sprees, but FulcrumSec brings something new to the table: technical precision.
Where other groups rely on bulk credential stuffing or SQL injection, FulcrumSec’s playbook includes:
- Credential chain mapping: Instead of just taking one token, they build a map of related credentials, pivoting from GitHub to internal APIs and cloud services.
- Data triage: They don’t just grab everything; they prioritize high-value targets—AI models, clinical data, customer lists—and compress those first to minimize exposure time.
- Negotiation scripting: Leaked chat logs suggest FulcrumSec has a standardized negotiation process, including pre-drafted ransom notes and escalation paths if the target refuses to pay.
This level of operational discipline means that even organizations with mature security programs aren’t safe if developer tooling is treated as low-risk. The actor didn’t need zero-day exploits or supply chain compromises; they needed GitHub tokens, access logs, and patience.
Novo Nordisk’s response—patching the misconfigured app, rotating GitHub tokens, and tightening access controls—is table stakes. The real test will be what happens next: will they implement continuous token auditing? Will they start treating developer identities like service accounts, with revocable access and audit trails? Or will this be another “incident closed” case file, with the same mistakes repeated elsewhere?
For now, every developer at every tech-forward company is looking over their shoulder. That access token they created last month, maybe with a six-month expiry and broad permissions… did they remember to rotate it? Did the system log its last use? Who else could have gotten their hands on it?
These aren’t rhetorical questions. They’re the new normal, and Novo Nordisk just proved it.
So What Do You Do Now?
If you’re running a development organization, here’s the short checklist—no fluff, just things that matter:
-
Audit your tokens: Use GitHub’s API to list all organization-scoped PATs and App installations. Look for tokens with no expiry, or those assigned to inactive developers.
-
Enforce fine-grained permissions: Replace organization-wide tokens with repository-specific or organization-wide scoped tokens that explicitly list what they’re allowed to touch.
-
Rotate on a cadence: Every token should have an expiration date, and the system should auto-rotate it before expiry (with a fallback to manual rotation for legacy integrations).
-
Add contextual logging: Beyond “token XYZ used,” log the API endpoint, request body hash (to detect high-value activity), and whether it matched known patterns from your CI pipelines.
-
Test for token leaks: Run periodic scans of your issue tracker, PR descriptions, and commit history for any accidental disclosures. Tools like GitLeaks and TruffleHog are good starting points, but don’t rely on them alone—set up a simple regex rule that flags any 40-character hex strings in plain-text files.
This breach wasn’t caused by a lack of security awareness. It was caused by assuming that developers don’t need the same level of oversight as service accounts. The cost of fixing that assumption—and dealing with a 1.3TB leak—has already come due.
