The Novo Nordisk data breach has been linked to stolen GitHub access tokens used by attackers to access company resources. The incident, reported on 11 September 2026, puts the security of developer credentials at the centre of the investigation.
Public reporting provides limited detail about the information exposed or the identities of those affected. However, the confirmed use of stolen tokens shows that this was not simply an attempted intrusion or a theoretical software weakness. Attackers reportedly possessed credentials capable of granting access to resources connected with Novo Nordisk.
Novo Nordisk data breach involved stolen access tokens
Novo Nordisk disclosed that attackers used stolen GitHub access tokens to obtain access to resources. Access tokens are digital credentials that allow people, applications and automated systems to interact with GitHub without entering an account password for every action.
The available report does not identify how the tokens were initially stolen. It also does not say whether they belonged to individual developers, service accounts, third-party contractors or automated development systems. These distinctions matter because each type of token can have different permissions, expiry settings and access to repositories.
No specific GitHub product, software version or vulnerability has been identified as the cause of the Novo Nordisk data breach. On the information available, the incident concerns compromised credentials rather than a flaw affecting a named version of GitHub Enterprise Server, GitHub Enterprise Cloud or another GitHub product.
The report does not state that GitHub itself was breached. Stolen access tokens can be obtained through several routes outside the platform, including exposed configuration files, compromised developer devices, malicious software, phishing, insecure build logs or secrets accidentally committed to source code. The precise route used in this incident has not been made public.
What attackers can do with a GitHub token
A token’s impact depends on the permissions assigned to it. A narrowly scoped credential might provide read-only access to one repository, while a more powerful token could permit changes to code, workflows, packages or organisation settings.
GitHub tokens may also be used by continuous integration and continuous delivery systems. These systems build, test and deploy software automatically. If a stolen credential reaches repositories or workflows containing additional secrets, an attacker may be able to move from the developer platform into connected resources.
Potential actions available through a compromised token can include:
- Reading private source code and repository documentation.
- Downloading files, release packages or internal development artefacts.
- Viewing issues, comments or project information stored in GitHub.
- Changing code or workflow files if the token has write permission.
- Searching accessible repositories for other credentials and sensitive configuration data.
- Using trusted automation to reach connected development or deployment services.
These are general capabilities associated with GitHub credentials, not confirmed actions in the Novo Nordisk data breach. The public report does not specify exactly what the attackers viewed, downloaded or changed after gaining access.
Who and what may be affected
The reporting says attackers accessed resources, but it does not identify the affected repositories, systems or data categories. It remains unclear whether the exposed material included source code, operational documents, employee information, customer information, research data or credentials for other services.
No confirmed number of affected individuals or records has been provided in the source material. The report also does not identify particular business units, subsidiaries, partners or geographical regions as being affected by the Novo Nordisk data breach.
There is similarly no public list of affected products or versions. Organisations should not interpret the incident as evidence that a particular Novo Nordisk product is vulnerable, or that users of a specified GitHub version face a newly discovered software flaw. The known issue is the unauthorised use of valid access tokens.
Because tokens normally appear legitimate to the service receiving them, their use can be harder to distinguish from authorised activity than an exploit generating obvious errors. GitHub will process requests permitted by a token until that token expires, is revoked or is blocked by another control.
Novo Nordisk data breach timeline and status
The incident was publicly reported on 11 September 2026. The available material does not provide dates for the initial theft of the tokens, the first unauthorised access, Novo Nordisk’s discovery of the activity or the containment of the affected credentials.
That absence prevents a reliable calculation of how long the attackers may have retained access. It also means there is no confirmed sequence showing whether the tokens were stolen in one event or gathered over time from multiple sources.
The exploitation status is nevertheless clear in one important respect: the tokens were reportedly used by attackers. This distinguishes the Novo Nordisk data breach from an advisory describing credentials that might potentially be exposed. Public information does not establish whether the unauthorised access is continuing, whether all relevant tokens have been revoked or whether additional credentials were obtained.
No named threat group has been attributed to the incident in the supplied report. There is also no confirmed description of attacker motives, such as espionage, financial theft, extortion or supply chain compromise. Any attribution or claim about motive would therefore be premature.
Why stolen GitHub tokens matter
The Novo Nordisk data breach illustrates how developer platforms can act as gateways to valuable corporate material. Private repositories may contain proprietary code, technical documentation and configuration details, while automated workflows can hold credentials for cloud platforms, registries and deployment environments.
A stolen token can also bypass some protections associated with password-based sign-in. Multi-factor authentication helps protect interactive account access, but an already issued token may continue to work according to its permissions and lifetime. For this reason, organisations must treat tokens as sensitive credentials rather than ordinary configuration strings.
Actions directly relevant to this incident
Organisations using GitHub or comparable developer platforms should first determine whether their tokens could be exposed through the same broad class of risk. The immediate priority is visibility over active credentials, their owners, permissions and recent use.
- Revoke tokens that are unused, unexplained or associated with departed users and retired services.
- Replace long-lived, broadly scoped credentials with short-lived tokens limited to required repositories and actions.
- Review GitHub audit records for unusual repository access, downloads, workflow changes and token activity.
- Search repositories, build logs and deployment files for exposed secrets, then rotate any credentials discovered.
- Check whether compromised GitHub access could lead to cloud platforms, package registries or production deployment systems.
Reviews should look beyond the initial token. If attackers accessed files containing other secrets, revoking only the known GitHub credential may not fully contain the incident. Connected credentials should be investigated according to what the token could reach.
Originally reported by BankInfoSecurity.
