Tooling

In June 2026 the Danish pharmaceutical giant Novo Nordisk confirmed a major data breach. According to reporting from HIPAA Journal, FiercePharma and Silicon UK, an extortion group called FulcrumSec claimed it stole 1.3 TB of data and demanded a 25 million dollar ransom, which Novo Nordisk refused to pay. For developers, the most important detail is not the ransom - it is how the attackers reportedly got in.

According to the group's own claims, reported by Silicon UK and others, the initial access came from secrets left in client-side JavaScript. That is a mistake any web team can make, and it is a clear, avoidable one. Here is what happened, why it matters, and how to keep it from happening to your own code.

What Novo Nordisk disclosed

Novo Nordisk disclosed the incident on 11 June 2026 and published an incident update on its own site. Shortly after, according to BankInfoSecurity, FulcrumSec added the company to its dark-web leak site with sample data from the claimed 1.3 TB haul. When the company refused to pay the reported 25 million dollar ransom, the group began leaking the stolen data.

The stolen material reportedly includes clinical-trial information, intellectual property, and AI models used for drug discovery, according to Yahoo Finance and FiercePharma. FulcrumSec, a cyber-extortion group active since at least September 2025, said it was also pursuing private sales of the stolen research. Novo Nordisk has not confirmed the attackers' technical claims in detail, so treat the entry-point specifics as the group's account.

How the attackers reportedly got in

According to FulcrumSec's account, reported by Silicon UK, the group gained access in March 2026 through secrets left in client-side JavaScript on two separate Novo Nordisk subdomains. In plain terms: sensitive credentials were shipped to the browser inside the website's own JavaScript, where anyone could read them.

• Keep every secret server-side (env vars or a secrets manager)
• Never ship a credential in client-side JavaScript
• Scope each token to the minimum access it needs
• Rotate credentials regularly - and at once if exposed
• Add automated secret scanning to your CI pipeline

The group said those secrets included Azure Container Registry credentials and a GitHub personal access token that reportedly had access to hundreds of repositories. A single leaked token with broad scope can turn one careless line of code into a company-wide breach. That is the whole danger of a hardcoded secret: it does exactly what it was built to do, for whoever finds it.

Why secrets in client code are so dangerous

Client-side JavaScript is, by definition, public. Every visitor's browser downloads it, and anyone can open developer tools or the raw bundle and read it. There is no such thing as a hidden value in front-end code - minifying or obfuscating it only slows a reader down, it does not hide anything. If a secret ships to the browser, treat it as already leaked.

The same risk applies to tokens committed to a Git repository, baked into a container image, or printed in a build log. Automated scanners crawl public sites and code hosts around the clock looking for exactly these strings. A token that grants broad access - like a personal access token with hundreds of repositories in scope - is the worst case, because one leak exposes everything it can reach.

How to keep secrets out of your client code

The fix is a discipline, not a single tool. Keep every secret server-side, in environment variables or a dedicated secrets manager, and never let one reach the browser bundle. Scope each token to the minimum it needs, rotate credentials regularly, and rotate them at once if they may have been exposed. Add automated secret scanning to your pipeline so a committed key is caught before it ships.

Front-end code that needs to call a protected service should go through your own server or a serverless function that holds the secret, not carry the secret itself. If you find a leaked credential, the order is simple: revoke it first, then investigate. A revoked token is harmless no matter who copied it.

The honest takeaway

The Novo Nordisk breach is a reminder that the most damaging failures are often the most basic. The attackers' claims are still the attackers' account, and Novo Nordisk has not detailed the entry point itself. But the lesson stands on its own: a secret in client-side code is a public secret. Keep credentials on the server, scope and rotate them, and scan for them before they ship.