Notifications
Clear all
Topic starter
20/08/2026 5:48 pm
TL;DR: The Phantom Gyp Miasma wave and the Hades follow-on show that package trust checks are failing at the registry-tarball layer, according to Corgea’s weekly briefing, while CVE-2026-10796 in nvm <= 0.40.4 turns hostile mirrors into shell command execution on workstations and CI runners. The practical lesson is that build-tool provenance, mirror trust, and package install boundaries now need tighter governance than source-repo review alone.
NHIMG editorial — based on content published by Corgea: weekly briefing on Phantom Gyp Miasma, Hades, and CVE-2026-10796
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams handle package install-time execution in CI environments?
A: Treat package installation as a potential execution event, not a benign download.
Q: Why do build tools and mirrors create identity risk as well as supply-chain risk?
A: Because they often run with tokens, service credentials, and deployment authority that attackers can abuse once code execution is achieved.
Q: What do organisations get wrong about package provenance checks?
A: They often assume that source review or publisher verification is enough, even when the package manager executes additional artefacts at install time.
Practitioner guidance
- Inventory package install execution paths Map where npm, PyPI, and nvm installs can trigger code execution, including lifecycle hooks, startup hooks, and mirror-based resolution.
- Restrict and attest custom mirrors Allow only approved mirrors for developer tooling, require integrity checks for mirrored artefacts, and block ad hoc mirror changes without change control.
- Classify build runners as non-human identities Assign owners, access scopes, and revocation paths to CI runners and other automation accounts, then remove standing privilege where package execution can reach secrets or deployment systems.
What's in the full report
Corgea's full weekly briefing covers the operational detail this post intentionally leaves for the source:
- Package-by-package remediation guidance for the Phantom Gyp Miasma wave, including the affected npm families and why install-time execution matters.
- Technical reverse-engineering notes on the Hades PyPI follow-on, including the .pth startup hooks, split staging, and cross-platform payload path.
- The CVE-2026-10796 nvm exploit mechanics, including the mirror trust failure and the command-injection sink.
- The full list of related incidents and prior supply-chain cases used to frame the weekly threat pattern.
👉 Read Corgea's weekly briefing on Phantom Gyp, Hades, and CVE-2026-10796 →
Supply-chain execution risk in npm and PyPI: what changed now?
Explore further
20/08/2026 6:28 pm
Package trust has become an identity problem, not only a software problem. When installers, mirrors, and registry artefacts are allowed to execute code, the real governance question is which identity is being granted runtime authority. That is why NHI and workload identity controls matter here: CI runners, build agents, and developer endpoints frequently operate with durable secrets and broad access. Practitioners should treat package install paths as privileged execution surfaces, not passive software intake.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and another 47% only partial visibility, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: How should teams respond when a developer tooling flaw can turn a mirror into shell execution?
A: Suspend untrusted mirrors, rotate any credentials exposed on affected runners, and review whether the same tool chain is used in CI, workstation provisioning, or build automation. Then remove shell evaluation from resolution paths and reclassify the tool as a privileged execution dependency, not a convenience utility.
👉 Read our full editorial: CVE-2026-10796 and package compromise risk outpace trust checks
