Notifications
Clear all
Topic starter
20/08/2026 5:29 pm
TL;DR: Install-time trust assumptions are now a supply-chain liability, not a convenience, as Corgea’s analysis of the Leo Platform npm incident shows how 23 poisoned package versions used a binding.gyp install trigger, npm dist-tag manipulation, and obfuscated loader code to turn dependency installation into code execution, secret theft, and propagation across developer and CI environments.
NHIMG editorial — based on content published by Corgea: Leo Platform npm supply chain compromise analysis
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
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.
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.
Q: What do teams get wrong about scanning dependencies for malware?
A: They often assume source scanning alone is enough.
Practitioner guidance
- Quarantine affected build hosts and runners Treat installation of any affected Leo version as host compromise.
- Audit for the poisoned package versions Search package manifests and lockfiles for [email protected], [email protected], and the other named malicious versions.
- 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.
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.
👉 Read Corgea's analysis of the Leo Platform npm supply chain compromise →
Leo Platform npm compromise: what it means for CI and secrets?
Explore further
20/08/2026 6:17 pm
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.
A few things that frame the scale:
- 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, according to The State of Secrets Sprawl 2026.
A question worth separating out:
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.
👉 Read our full editorial: Leo Platform npm compromise exposes install-time supply chain abuse
