Compromised npm publishing tokens expose supply chain release risk

At a glance

What this is: This is a supply chain breach analysis showing how a stolen npm token and GitHub Actions abuse enabled malicious package publication.

Why it matters: It matters because developer credentials, CI/CD automation, and release pipelines now sit inside the identity perimeter that IAM, PAM, and NHI teams must govern.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Jscrambler's report on the npm package compromise and release abuse

Context

The core problem here is not just package tampering, but release-path identity abuse. A trusted developer environment held the credentials needed to publish software, and once those secrets were exposed, the attacker could act faster than the normal control loop could respond. For IAM and NHI practitioners, that is a reminder that build systems, tokens, and developer workstations are part of the identity attack surface, not just supporting infrastructure.

In supply chain incidents, the control failure is often lifecycle governance rather than a single missing alert. The issue is whether publishing credentials are short-lived, bound to narrow trust boundaries, and protected by step-up controls when automation touches public release channels. That makes this case representative of a broader pattern in which NHI governance, PAM discipline, and CI/CD hardening overlap.

Because the article describes a concrete compromise and release abuse path, this is typical of modern software supply chain risk rather than an isolated anomaly. The same pattern appears whenever long-lived credentials live on developer endpoints and can be reused outside the intended workflow.

Key questions

Q: What breaks when package publishing depends on long-lived credentials?

A: Long-lived publishing credentials turn a release pipeline into standing privilege. If an attacker steals the token once, they can publish malicious versions until someone notices and revokes it. That breaks the assumption that source control compromise is contained to code changes, because the attack can jump directly into software distribution. The safer model is short-lived, identity-bound publishing with explicit approval for release actions.

Q: Why do developer workstations create such a high release-risk environment?

A: Developer workstations often hold cached credentials, SSH keys, and automation secrets in one place, so a single compromise can expose multiple trust paths. That is especially dangerous when the same machine can reach GitHub, npm, and CI/CD systems. The result is credential concentration, where one endpoint becomes a launch point for supply chain abuse rather than just a productivity device.

Q: How do you know if package security controls are actually working?

A: Look for fewer unexpected publishes reaching build systems, lower rates of install-time outbound connections, and measurable reductions in secret exposure during pipeline execution. Strong controls should also produce clear denial events when packages attempt to fetch credentials, contact external endpoints, or install from unauthorised sources.

Q: Who is accountable when malicious code enters through a package registry?

A: Accountability usually spans the package maintainer, the registry controls, and the consuming organisation’s build governance. The maintainer identity is the publishing control point, but the consumer still owns script restrictions, lockfile enforcement, and credential protection on build systems. The right question is who owned each control layer, not who noticed the attack first.

Technical breakdown

How GitHub Actions can become a credential exfiltration path

GitHub Actions workflows run with repository-scoped permissions, but those permissions are only as safe as the secrets they can reach. If a workflow can access publish tokens, SSH keys, or other privileged material, an attacker who gains repo write access or tampers with automation can extract those credentials without needing direct access to the package registry. The workflow becomes a bridge between source control and release authority. In this case, the attacker used the workflow to obtain the npm token and then published malicious versions externally. Practical implication: separate build automation from release authority and restrict which workflows can touch publish-grade secrets.

Practical implication: remove publish-grade secrets from workflows that do not strictly need them and require explicit approval for release actions.

Why long-lived npm tokens create standing release privilege

A package publish token is effectively standing privilege for software distribution. Unlike a short-lived session credential, it can be replayed until revoked, and it often bypasses the stronger identity checks that protect interactive logins. That makes it especially dangerous when stored on a developer machine, cached in tooling, or injected into automation with broad scope. Once stolen, the token allows an attacker to publish directly to the registry without altering the repository itself. Practical implication: replace reusable publish tokens with short-lived, identity-bound publishing methods and enforce rotation on any token that remains in use.

Practical implication: treat package publishing tokens as privileged secrets and eliminate any that are not bound to short-lived, identity-based workflows.

How package manager cooldowns reduce malicious version exposure

Minimum release age controls add a time buffer between publication and installation. They do not prevent compromise, but they make freshly published malicious versions less useful because they cannot be consumed immediately by automated builds or rapid adopters. In incidents like this, attackers rely on speed, hoping the malicious version reaches victims before the compromise is noticed. Cooldown settings in npm and pnpm interrupt that race by forcing a delay before dependency resolution can select the new package. Practical implication: apply minimum release age to public dependencies that can tolerate delayed adoption, especially where release integrity matters more than immediate version uptake.

Practical implication: use a cooldown period for public package adoption so newly published versions are not installed automatically in the first minutes of exposure.

Threat narrative

Attacker objective: The attacker wanted to weaponize trusted software distribution so that malicious package versions would execute in downstream developer environments.

1. Entry occurred when the attacker compromised a developer machine and obtained GitHub SSH material plus npm publication credentials.
2. Escalation followed when a GitHub Actions workflow exposed the npm publish token, giving the attacker durable release access beyond the original workstation compromise.
3. Impact came when malicious package versions were published directly to npm and could execute during installation or CLI use before removal.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing release privilege is now a supply chain control failure, not just a DevOps hygiene issue. When a publish token survives on a developer machine or in automation, it creates a durable path from endpoint compromise to software distribution abuse. That is a governance problem for IAM, PAM, and NHI teams because the credential is acting as a non-human identity with release authority. The practical conclusion is that publishing rights need lifecycle control, scope limitation, and revocation discipline.

GitHub Actions and similar workflows are identity-bearing execution layers, not neutral automation. If a workflow can access secrets that authorise package publication, then compromise of the workflow is compromise of the release trust model. This is where NHI governance intersects with software supply chain security: the workflow, the token, and the developer account all contribute to the effective identity perimeter. Practitioners should treat release automation as privileged infrastructure.

Minimum release age is a useful delay control, but it addresses exposure timing, not root compromise. Cooldowns reduce the chance that a malicious version is installed immediately, yet they do nothing if publish credentials remain stealable or replayable. The named concept here is release-window compression: attackers exploit the short interval between publication and detection. Teams should narrow that window with stronger release authentication and slower dependency acceptance.

OIDC-based publishing reduces secret persistence, which is the real weakness in many package pipelines. Long-lived tokens on developer endpoints are attractive because they can be stolen once and reused repeatedly. Identity-bound, short-lived credentials shift the risk from secret theft to session control, which is a better fit for modern release governance. Practitioners should re-evaluate any pipeline that still relies on reusable registry tokens.

Developer endpoints have become credential concentration points because AI-assisted coding and automation increase secret density. That changes the threat model for both human identity and NHI governance. The more tokens, cached sessions, and cached credentials a workstation holds, the more an endpoint compromise can cascade into release abuse. Security teams should treat developer devices as privileged identity assets and reduce the secret inventory they can reach.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Use Ultimate Guide to NHIs , Key Challenges and Risks to map this exposure to lifecycle controls, rotation, and offboarding.

What this signals

Release-window compression is becoming a practical governance problem for software teams that still rely on reusable registry tokens. The shorter the time between secret exposure, publication, and installation, the less value traditional detection has unless it is paired with revocation and release gating.

For identity teams, the important shift is that package publishing now behaves like any other privileged access path. That means the same discipline used for PAM and NHI governance applies to developer tokens, CI/CD identities, and workflow permissions, especially where release infrastructure touches public registries.

The combination of developer endpoint compromise and automation abuse suggests a new baseline for control design. Teams should expect more attacks that do not modify source code at all but instead hijack the credentialed release path, which is exactly why identity lifecycle controls need to extend into build and publishing systems.

For practitioners

• Harden package publishing with short-lived identity-bound credentials Replace reusable npm publish tokens with OIDC-backed or otherwise short-lived publishing credentials, and remove any secret that can be replayed from a workstation or automation job.
• Separate workflow execution from release authority Restrict GitHub Actions jobs so they cannot access publish-grade secrets unless a human approves the release path, and keep source control write access distinct from registry publish rights.
• Apply minimum release age to public dependencies Enable npm min-release-age or pnpm minimumReleaseAge so freshly published packages cannot be installed immediately during the highest-risk exposure window.
• Inventory and rotate all developer-held secrets Remove unnecessary keys and tokens from developer machines, then rotate every credential that could have been exposed in the compromised environment, including SSH keys and registry tokens.
• Add dual approval for critical release operations Require two independent approvals for package publication and other sensitive release events so a single compromised identity cannot unilaterally publish malicious software.

Key takeaways

• The breach shows that a stolen publishing token can convert a developer endpoint compromise into malicious software distribution.
• The article’s own timeline shows the attack moved from first exposure to registry publication in minutes, which is fast enough to outrun manual response.
• Short-lived publishing credentials, dual approval, and dependency cooldowns are the controls most likely to reduce this failure mode.

Key terms

• Release-window compression: The shrinking time between credential exposure, malicious publication, and defensive detection. It matters because attackers now try to weaponize software distribution before teams can react, so delay controls, revocation speed, and release approvals become part of the security boundary.
• Standing release privilege: A persistent credential or permission that allows software to be published without fresh approval or re-authentication. In practice, it creates a reusable path from compromise to public distribution, which is why publishing rights should be short-lived and tightly scoped.
• Identity-bound publishing: A release model where the act of publishing is tied to a verified, short-lived identity assertion rather than a reusable token stored on a device. This reduces the value of secret theft and makes release authority easier to audit, revoke, and control.
• Credential concentration: The accumulation of many valuable secrets on one endpoint, account, or workflow. When developer devices or CI/CD jobs hold multiple tokens and keys, a single compromise can cascade into source control, registry, and cloud access, making endpoint hardening an identity issue.

What's in the full analysis

Jscrambler's full report covers the operational detail this post intentionally leaves for the source:

• The exact package versions, helper-package dependencies, and publication timeline tied to the malicious npm releases.
• The specific response sequence, including revocation, deprecation, and the clean release process used to contain the incident.
• The planned control changes around dual approval, OIDC publishing, and container hardening that were only summarised here.
• The package-manager settings and release workflow adjustments that reduce exposure to newly published malicious dependencies.

👉 Jscrambler's full report covers the incident timeline, affected versions, and the controls it changed afterward.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity discipline to real operational risk.