Semgrep’s npm worm advisory exposes the scale of dependency risk

At a glance

What this is: This is Semgrep’s advisory on a dependency worm in npm that spread through compromised packages and exposed credentials across development and CI environments.

Why it matters: It matters because IAM, PAM, and NHI teams have to treat package installation as an identity event, with secrets exposure, transitive trust, and rotation all in scope.

By the numbers:

• 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 Semgrep's advisory on the npm dependency worm and exposed credentials

Context

The core problem here is npm dependency trust, not just malware detection. When a maintainer account is compromised, malicious code can enter packages that developers install routinely, and that installation step becomes an identity and secrets exposure event across laptops, CI systems, and internal build tooling.

For IAM and NHI programmes, this is the same old supply chain problem in a more operationally immediate form. Dependencies can carry credentials, tokens, SSH keys, and cloud access into places security teams often assume are safe because they are not internet-facing.

Semgrep’s advisory points to a broader lesson for software supply chains: transitive dependencies and internal environments are part of the blast radius. The fact that the malware executes during package installation means exposure can happen before application runtime controls ever have a chance to matter.

Key questions

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

Q: Why do supply chain worms create a secrets management problem as well as a malware problem?

A: Because the attacker is not only trying to alter code. They are also trying to collect valid credentials that can be reused elsewhere. If leaked secrets are not revoked quickly, the compromise outlives the package incident and turns into durable non-human identity abuse.

Q: How do security teams know whether a package advisory has created real identity exposure?

A: They should check whether affected build or developer environments stored cloud keys, SSH keys, API tokens, or SaaS access at the time of installation. If those identities were present, the advisory is an authentication event, not just a software update, and revocation becomes mandatory.

Q: Who is accountable when a compromised dependency exposes production secrets?

A: Accountability is shared across application, platform, and identity teams because the failure spans dependency control, secret exposure, and workload access governance. Security frameworks expect organisations to reduce attack surface, but the practical answer is to remove reusable secrets from places untrusted code can reach and to log every runtime credential handoff.

Technical breakdown

How npm dependency worms turn installation into an exposure event

A dependency worm does not need to wait for application execution. If a maintainer account or publishing pipeline is compromised, malicious dependency updates can be inserted into packages that downstream projects install automatically. Package managers then resolve transitive dependencies, so a single tainted package can reach many applications without a direct reference. Because installation often happens in developer laptops, CI runners, and internal build systems, the malware can execute in trusted environments and harvest secrets present on disk or in process memory.

Practical implication: treat dependency installation as a controlled execution boundary and scan builds, not just deployed code.

Why transitive dependencies expand the attack surface

Transitive dependencies are libraries that your project uses indirectly through another package. That indirection hides risk because the application owner may not know the compromised component exists until an advisory appears. In ecosystems like npm, popular UI libraries and charting components often sit several layers deep, which makes inventory and exposure analysis harder. Once a worm lands in a widely used maintainer path, many packages can inherit the malicious payload before maintainers or consumers understand the spread.

Practical implication: maintain a complete dependency graph and map indirect packages to owners, scanners, and remediation workflows.

Why secrets rotation matters after package compromise

If a build or developer environment is exposed, the resulting risk is not limited to source code tampering. Malware that captures cloud credentials, SSH keys, GitHub Actions tokens, or SaaS access can enable follow-on access long after the initial compromise. That is why rotation and revocation are part of supply chain response, not separate hygiene. A leaked secret remains a live identity until it is invalidated, which makes stale credentials a compounding control failure rather than a one-time leak.

Practical implication: rotate and revoke affected secrets immediately, then verify which identities could still authenticate.

Threat narrative

Attacker objective: The attacker’s objective was to capture valid credentials and spread malicious dependencies broadly enough to create repeated downstream access opportunities.

1. Entry occurred through compromise of a package maintainer, allowing malicious dependencies to be published into the npm ecosystem and distributed through normal installs.
2. Credential harvest followed when the malware executed during package installation in developer and CI environments, where cloud keys, SSH keys, and SaaS tokens could be present.
3. Impact extended as the compromised dependencies propagated to hundreds of packages, expanding exposure across downstream applications and internal tooling.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Dependency installation is now an identity event: This campaign shows that package installation can expose secrets before an application ever runs. That changes the governance model for software supply chains because developer workstations, CI runners, and internal build systems become credential-bearing environments rather than neutral tooling. Practitioners should treat install-time execution as a governed identity boundary, not a background maintenance task.

Internal applications are not exempt from supply chain blast radius: Semgrep’s warning about internal tooling reflects a common blind spot. Security teams often focus on public-facing services, but transitive packages and installation-time malware ignore that distinction. The practical conclusion is that internal software estates need the same dependency exposure analysis as customer-facing applications, especially where build systems hold cloud or SaaS credentials.

Secrets management fails when revocation is not coupled to exposure detection: The article’s remediation advice to rotate credentials is necessary because leaked secrets remain usable until they are invalidated. This is a standing credential persistence problem, not merely a detection problem. For NHI governance, the lesson is that discovery without revocation leaves the identity active and exploitable.

Identity blast radius is determined by where credentials live, not where code runs: A dependency worm becomes materially worse when secrets are cached in local developer environments, CI runners, and automation tokens. That creates multiple concurrent identity surfaces from one compromise. Teams need to map where credentials are stored, which systems can present them, and how quickly those identities can be killed once a package advisory lands.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 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.
• That exposure pattern aligns with the 52 NHI breaches Report, which shows how credential sprawl turns single incidents into repeated identity abuse.

What this signals

Dependency worms are pushing supply chain security deeper into identity governance. Once package installation can expose credentials in developer laptops and CI runners, teams need to model those environments as non-human identity surfaces with explicit ownership, revocation paths, and auditability.

Identity blast radius: the practical unit of risk is not the package alone but every authentication path reachable from the build environment. That is why teams need to pair advisory response with secret inventory, environment hardening, and faster invalidation of exposed tokens.

The broader shift is toward treating software build systems as privileged infrastructure. Teams that keep secrets inside those environments without tight scoping and revocation discipline will keep converting dependency incidents into access incidents.

For practitioners

• Inventory transitive dependency exposure Build a complete dependency graph for npm packages, including indirect libraries used by internal and CI workloads. Tie that inventory to package owners so an advisory can be turned into an owned remediation task instead of a broadcast alert.
• Rotate credentials after package advisories Treat malicious package exposure as a trigger to revoke cloud keys, SSH keys, GitHub Actions tokens, and SaaS credentials found on developer and build systems. Validate that replacement credentials are issued only after the affected environments are cleaned.
• Quarantine build environments with secret-bearing access Separate package installation jobs from environments that hold high-value secrets, and reduce the number of credentials available to those runners. If a build node is compromised, the attacker should not inherit broad authentication paths.
• Scan internal tooling on every advisory cycle Do not exclude internal applications from dependency review because they are not public-facing. Re-run scans across developer machines, CI systems, and internal dashboards whenever a malicious package advisory expands.

Key takeaways

• This campaign shows that a compromised package maintainer can turn npm installation into a secrets exposure event across developer and CI environments.
• The evidence pattern is clear: transitive dependencies, exposed credentials, and broad downstream spread create a larger identity blast radius than many teams assume.
• The limiting control is rapid revocation and environment isolation, because detection alone leaves leaked secrets usable long after the advisory is published.

Key terms

• Credential Worm: A credential worm is malware that steals usable secrets from one system and then uses those secrets to spread into others. In supply chain environments, it often combines package install execution, publish rights, and automated republishing to create repeated compromise.
• Transitive Dependency: A transitive dependency is a package your project uses indirectly through another package. These dependencies often escape normal review because they are not declared at the top level, yet they can still execute code, introduce vulnerabilities, or expand the blast radius of a supply chain compromise.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Semgrep's full advisory covers the operational detail this post intentionally leaves for the source:

• Package-by-package advisories for affected npm dependencies and versions
• Updated scan guidance for spotting the malicious dependencies in active projects
• Remediation notes on credential rotation for cloud, SSH, and SaaS access
• Indicators for checking whether internal build and developer systems were exposed

👉 Semgrep's full advisory covers affected packages, scan guidance, and remediation steps for exposed credentials.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.