Novo Nordisk, the roughly $400 billion pharmaceutical company behind Ozempic and Wegovy, disclosed a security incident in June 2026 involving unauthorized access to internal systems and data tied to clinical trials. Around the same time, a group calling itself FulcrumSec claimed responsibility for a separate intrusion, saying it had exfiltrated a large volume of data and attempted to extort the company before exploring other ways to monetize what it had taken.
What makes this case worth a closer look isn’t the size of the company or the size of the ransom demand. It’s the alleged entry point: according to the attackers’ own claims and subsequent reporting, initial access was gained through credentials — including a high-privileged token — that had been left exposed in client-side JavaScript on a public-facing subdomain. From there, the group says it pivoted into source repositories, harvested additional API tokens, database credentials, and service account passwords, and used them to move laterally across hundreds of internal systems.
The pattern behind the headline
Strip away the brand name and the dollar figures, and the underlying story is a familiar one. The attackers didn’t break through a hardened perimeter with a novel exploit. By their own account, they logged in — using credentials that should never have been retrievable from a public-facing asset in the first place. A secret committed into a JavaScript bundle, a personal access token with far more scope than the task required, and a lack of rotation or monitoring on machine identities turned a single oversight into what attackers describe as access to hundreds of systems.
This is consistent with what security researchers covering the incident have pointed to as the likely root cause: a gap in automated secrets detection within the software development lifecycle. The kind of static analysis and pre-commit scanning that should catch plaintext credentials before they ever reach a production bundle.
Why this still matters when AI dominates the conversation
Most of the current conversation in security leadership circles is about AI-powered attacks, model risk, and emerging adversarial techniques. Those are real and growing concerns. But cases like this are a reminder that the controls which matter most are often the least novel ones: secrets management, attack surface visibility, secure coding practices, and access control. An organization can be investing heavily in next-generation detection and still be exposed by a credential sitting in plain sight in a JavaScript file.
For security leaders, the practical takeaways are not complicated, even if they are not always easy to execute consistently across a large engineering organization:
Maintain a real inventory of non-human identities. Service accounts, API keys, and access tokens tend to multiply faster than anyone tracks them, and an inventory you don’t trust is not an inventory.
Eliminate long-lived secrets wherever the workload allows it. Short-lived, automatically rotated credentials shrink the window in which a leaked secret is still useful to an attacker.
Scope aggressively. A personal access token with access to hundreds of repositories is a single point of failure dressed up as a convenience.
Monitor machine identities the way you monitor human ones. Baseline normal behavior for service accounts and alert on deviation, the same discipline already applied to user accounts in most mature programs.
None of this requires a new platform or a new acronym. It requires the unglamorous, ongoing work of getting the fundamentals right — which is precisely the work that security program assessments are designed to surface before an incident does it for you.