Leo Platform npm compromise exposes install-time supply chain abuse

At a glance

What this is: This is an analysis of the Leo Platform npm compromise, where poisoned package versions used install-time execution to steal secrets and spread through developer and CI environments.

Why it matters: It matters because IAM, PAM, and NHI teams have to treat package installation as an access event, especially when CI runners, publish rights, tokens, and cloud credentials are 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 Corgea's analysis of the Leo Platform npm supply chain compromise

Context

The Leo Platform npm incident shows how quickly package compromise becomes an identity and access problem when installation itself can execute attacker-controlled code. In this case, the risk is not just a malicious dependency, but the combination of install-time execution, exposed CI credentials, and publish rights that can turn one poisoned artifact into broader environment compromise.

For practitioners, the key governance gap is that software supply chain controls often stop at source review or signature checks while ignoring what package managers actually execute during install. That is a real weakness for NHI governance because CI runners, build agents, tokens, certificates, and cloud credentials behave like non-human identities with privileges that can be stolen, reused, and repurposed.

This pattern is not atypical. It matches the broader shift in supply chain attacks where the registry artifact, not the repository alone, is the security boundary.

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 CI runners make npm supply chain attacks worse?

A: CI runners usually carry broad non-human privileges, including source-control tokens, cloud credentials, and package publishing access. When a malicious package runs during install, those secrets are already in memory or on disk. That converts a single poisoned dependency into a route to repository tampering, release abuse, and downstream propagation.

Q: What do teams get wrong about scanning dependencies for malware?

A: They often assume source scanning alone is enough. In practice, malicious code may look benign until it runs, especially when it hides in a package that alters browser requests or network behaviour at execution time. Behavioural analysis and runtime monitoring are needed to catch that class of abuse.

Q: Who is accountable when machine credentials are stolen through a build pipeline?

A: The accountable team is usually the one that owns package governance, CI security, and secret lifecycle controls together. Frameworks such as NIST SP 800-53 and OWASP Non-Human Identity Top 10 make clear that privileged machine identities need lifecycle management, auditability, and revocation procedures, not just access approval.

Technical breakdown

Why binding.gyp turns package install into execution

In npm, a binding.gyp file can cause node-gyp to run during installation even when a package looks like a normal JavaScript library. That matters because the attacker does not need a visible preinstall or postinstall script in package.json. If the install path includes shell expansion or build-step side effects, dependency installation becomes an execution channel. In the Leo case, the malicious package used that mechanism to launch index.js during install, which is why review of source files alone missed the real payload path.

Practical implication: treat any unexpected binding.gyp file in a JavaScript-only package as an execution trigger and block it in dependency policy.

Why dist-tag manipulation changes the trust model

npm dist-tags control which version install commands resolve to by default. When an attacker repoints latest to a poisoned release, teams that trust unpinned installs inherit the attacker’s choice even if a clean version still exists in the registry. This is a governance problem, not just a versioning issue, because the package manager is effectively making an access decision on behalf of the build system. The Leo incident shows how a clean release line can coexist with a malicious default path.

Practical implication: require explicit version pinning and verify dist-tag changes as part of supply chain monitoring.

How secret theft becomes NHI propagation

The stolen material in incidents like this is usually not only application data. It includes GITHUB_TOKEN values, npm publish rights, OIDC credentials, cloud keys, SSH material, and password-manager secrets. Those credentials are non-human identities with lifecycle, privilege, and offboarding requirements. Once stolen, they can be used to modify workflows, republish packages, and extend the compromise across repositories and CI systems. That is what turns a single install event into an identity governance failure.

Practical implication: rotate and revoke non-human credentials as a host-compromise response, not as routine hygiene.

Threat narrative

Attacker objective: The attacker’s objective was to convert package installation into a reusable supply-chain foothold that yields secrets, publish rights, and propagation into downstream repositories and CI systems.

1. Entry occurred when developers or CI runners installed poisoned Leo Platform npm versions that executed attacker-controlled code during the package install step.
2. Credential harvesting followed as the payload searched for GitHub tokens, cloud credentials, npm publish rights, SSH material, and assistant-state secrets on the host and runner.
3. Escalation and propagation came from abusing stolen publish rights and workflow write access to repoint trust paths, modify repositories, and spread the compromise through additional packages and automation.
4. Impact was supply-chain-wide compromise of developer and CI environments, with secret theft, workflow tampering, and the potential for continued package poisoning.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

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

NHI Mgmt Group analysis

Install-time code execution is now the control boundary for npm supply chain risk. The Leo incident shows that source review alone is insufficient when a package can execute during install through build metadata. That shifts the governance question from whether a dependency looks safe to whether the registry artifact can execute outside the application runtime. Practitioners should treat install paths as execution surfaces and govern them accordingly.

This is an NHI governance incident as much as a software supply chain incident. The compromised environment exposed GITHUB_TOKEN, OIDC credentials, cloud credentials, SSH material, and password-manager secrets, all of which are non-human identities in practice. Once those credentials are harvested, the attacker can impersonate trusted automation, republish packages, and reuse access across systems. The control failure is lifecycle governance for machine credentials, especially in CI.

Dist-tag trust is a hidden attack surface in package management. A default install that follows latest is a delegated access decision, not a neutral convenience. When attackers can move a malicious version into the default resolution path, they can steer entire build estates without touching code repositories. The practitioner conclusion is simple: version pinning and dist-tag monitoring belong in the security baseline, not optional hardening.

Secret theft without revocation is what makes a one-time compromise persistent. The broader lesson from this incident is that exposed credentials remain useful long after detection unless they are revoked, rotated, and scoped. That is especially true for CI runners and developer workstations, where secrets often combine publish rights with cloud and source-control access. Teams that cannot rapidly invalidate machine credentials will keep turning isolated incidents into repeat compromise.

Supply chain telemetry now needs identity context. Package anomalies, install-time execution, and token abuse are easier to interpret when they are mapped to the identities that can publish, deploy, and modify workflows. That is where OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls converge with operational reality. The field should treat dependency compromise as a privilege problem, not just an integrity problem.

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.
• 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.
• Forward signal: The Guide to the Secret Sprawl Challenge explains why secret discovery must be paired with lifecycle enforcement, especially when CI and developer tooling share access paths.

What this signals

Secret sprawl has become a build-time exposure problem, not just a code-review problem. When package installs can run code and CI runners carry publish rights, the practical boundary shifts to the places where secrets are already present. The next governance step is to connect dependency controls with lifecycle controls for machine credentials, using OWASP Non-Human Identity Top 10 as a baseline and NIST SP 800-63 Digital Identity Guidelines where human auth is involved.

Install-time execution should now be treated as an identity event. That is the named concept this incident sharpens. A package that can run during install is not only a software artefact, it is a temporary trust delegation into a privileged build context. Teams that do not classify install-time execution as access need stronger inventory, approval, and revocation workflows for CI and developer credentials.

The operational signal is clear: secret rotation after a package incident must be paired with workflow review and artifact provenance checks. If a compromised runner can republish packages or modify pipeline files, the compromise can persist even after the original malicious version is removed.

For practitioners

• Quarantine affected build hosts and runners Treat installation of any affected Leo version as host compromise. Isolate CI runners and developer workstations before rotating secrets, and preserve lockfiles, npm cache entries, runner logs, and package tarballs for forensics.
• Audit for the poisoned package versions Search package manifests and lockfiles for [email protected], [email protected], and the other named malicious versions. Expand scope to cached tarballs and installed trees, then remove any dependency paths that resolved through latest rather than an explicit pin.
• Rotate every machine credential reachable from the host Revoke and replace GitHub, npm, cloud, SSH, password-manager, and API-provider credentials that the affected host could access. Prioritise publish rights and workflow secrets because those enable propagation into repositories and future package releases.
• Inspect post-install persistence locations Review .claude/settings.json, .claude/setup.mjs, .cursor/, .vscode/tasks.json, and .github/copilot-instructions.md for persistence planted after dependency installation. Those locations matter because the campaign targets developer-tool startup hooks as alternate execution paths.
• Block unexpected install-time execution paths Flag packages that include binding.gyp in otherwise JavaScript-only releases, and prevent node-gyp rebuild from running unless the package is explicitly approved. Pair that with restricted registry egress and package provenance checks for CI.

Key takeaways

• The Leo Platform npm compromise shows that install-time execution is enough to turn a dependency into an access-path compromise.
• The evidence points to a supply-chain event that exposed CI credentials, publish rights, and other non-human identities at scale.
• The control that matters most is not just dependency review, but rapid revocation, artifact inspection, and hard limits on install-time execution.

Key terms

• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Dist-tag: A dist-tag is a registry label such as latest that tells package managers which version to install by default. Attackers who repoint a dist-tag can steer unpinned installs toward malicious releases even when a clean version still exists in the registry.
• Machine Issued Credential Lifecycle: The set of controls that govern creation, review, rotation, and revocation of credentials issued to non-human actors. It matters because initial issuance is only one point in the life of access, and unmanaged persistence is where many identity failures begin.
• Package Artifact Boundary: The package artifact boundary is the idea that the tarball, not just the repository, is the security object that matters. Malware often appears only after packaging, through altered loader files, build metadata, or hidden scripts that are invisible in a source-only review.

What's in the full analysis

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

• Package-by-package version inventory and the full list of affected Leo ecosystem releases.
• The registry metadata and tarball indicators used to distinguish the poisoned releases from clean package versions.
• Detailed detection searches for binding.gyp, install-time execution, and campaign strings in runner and developer-tool logs.
• Response steps for GitHub Actions, npm caches, and adjacent developer tooling such as Claude and Cursor state files.

👉 Corgea's full post covers the affected package list, install-time trigger details, and response guidance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity lifecycle controls to real-world supply chain and CI risk.