TL;DR: Two active supply chain attacks are targeting npm and PyPI packages, with Expel reporting malicious post-install code that steals cloud and SSH credentials from developer and runtime environments. The pattern shows how package trust can collapse into credential theft across the software delivery chain, making clean install discipline and credential governance mandatory.
At a glance
What this is: Expel describes two active package-compromise campaigns targeting npm and PyPI, with malicious code stealing cloud and infrastructure credentials from developer and runtime environments.
Why it matters: This matters because software supply chain compromise now becomes an identity problem as well as a code integrity problem, pulling IAM, PAM and NHI controls into incident response.
Context
Package compromise is a supply chain control failure, not just a malware event. When package managers execute install-time code, the trust boundary shifts from repository review to runtime execution, which is where secrets, cloud tokens and SSH material become reachable. In identity terms, the issue is that build and developer environments often contain high-value credentials with weak separation between humans, services and automated workflows.
The article is about two active campaigns that exploit that trust boundary in npm and PyPI ecosystems. One path uses malicious post-install behaviour to spread through publishing pipelines, while the other abuses a compromised AI model serving framework to harvest cloud credentials. The pattern is typical of modern supply chain compromise, where the package ecosystem becomes a credential collection layer.
Key questions
Q: What breaks when npm or PyPI packages can run install-time code on developer systems?
A: The trust boundary breaks because dependency installation becomes code execution with access to local files, environment variables and secrets. That means package compromise can immediately reach cloud tokens, SSH material and build credentials, especially when developers or CI runners hold reusable authority. The right response is to treat install-time execution as a high-risk operation, not a routine software housekeeping task.
Q: Why do package compromises often lead to credential theft?
A: Package compromises often lead to credential theft because developers and build hosts commonly store access tokens, cloud keys, and SSH material in reachable locations. Once code execution is achieved, attackers enumerate those secrets and reuse them as non-human identities in adjacent systems. That is why identity controls must extend into build and endpoint environments.
A: Look for unexpected package modifications, unauthorized version publishing, unusual access from developer identities, and dependency changes that appear after a seemingly normal install event. A second warning sign is malware that tries to harvest credentials and then reuse them to alter software releases. Those indicators suggest the attacker has moved from infection to propagation.
Q: When should teams prioritize dependency script controls over broader build hardening?
A: Prioritize them immediately when package managers are allowed to execute code in environments that also hold production-adjacent credentials. Script controls matter most where build hosts, developer laptops or CI runners can see secrets that would be dangerous if exposed. If install-time execution is permitted, stronger build hygiene elsewhere will not fully contain the risk.
Technical breakdown
How install-time package code turns dependency trust into credential theft
npm and PyPI both allow packages to execute code during installation or execution, which means the act of installing a dependency can become an attack step. Post-install scripts are especially sensitive because they run before a developer has fully validated what the package does. Once that code runs inside a workstation, CI runner, or build container, it can inspect environment variables, read local files, and reach cloud metadata or configuration artefacts that contain secrets. The problem is not the package registry alone. It is the combination of automatic execution, broad local access, and credential-rich development environments.
Practical implication: treat install-time execution as a privileged event and disable or tightly control package scripts wherever possible.
Why cloud credentials and SSH keys are the highest-value targets
The malicious code in this article is not trying to steal ordinary application data first. It is targeting cloud access keys, SSH keys, and Kubernetes secrets because those artefacts unlock wider environments than the original infected host. Cloud credentials can expose storage, compute, and identity control planes, while SSH keys and Kubernetes secrets can extend access into internal systems and deployment paths. That makes the compromise both an access problem and a privilege problem. In many organisations, one exposed developer machine can provide reach into non-human identities, CI/CD automation, and production infrastructure if credential scope and isolation are weak.
Practical implication: segment developer, CI/CD, and runtime credentials so compromise of one environment does not expose the others.
How supply chain compromise becomes self-propagating in publishing pipelines
The CanisterWorm pattern shows how a package compromise can move beyond a single infected host and into the software distribution process itself. If stolen developer credentials allow an attacker to modify packages and publish poisoned updates, the incident stops being a local infection and becomes a downstream propagation event. That creates a classic trust collapse: the distribution mechanism that should deliver updates becomes the attack vehicle. This is why package provenance, publisher identity, and dependency integrity matter together. Without those controls, a compromised maintainer account or build context can turn one malicious package into many.
Practical implication: harden publishing identities and verify package provenance before allowing releases into shared registries.
Threat narrative
Attacker objective: The attacker wants to convert trusted package execution into credential theft and then use those secrets to widen access across development, cloud and publishing environments.
- Entry occurs when a developer or build environment installs a malicious npm or PyPI package that executes post-install or runtime code.
- Credential access follows as the code harvests cloud access keys, SSH keys, Kubernetes secrets and related environment variables from the host.
- Escalation occurs when stolen developer credentials are reused to modify packages or publish malicious updates into the software delivery pipeline.
- Impact is broader credential compromise across cloud and build environments, with the possibility of downstream package propagation and environment takeover.
Breaches seen in the wild
- xinference PyPI compromise 2026: Three xinference releases on PyPI carried a stealer for cloud, Kubernetes and registry keys, reportedly via a compromised bot account.
- 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 and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Package trust has become a credential governance problem: supply chain security can no longer stop at code integrity checks. When package managers execute installer code, the real control question is which credentials are present at runtime and whether they are isolated from untrusted dependencies. Practitioners should treat dependency execution as an identity event, not only a software delivery event.
Cloud secrets in developer environments create a hidden blast radius: the article shows how exposed AWS, Azure and Google Cloud access keys turn a routine package installation into a control-plane risk. That is a non-human identity failure as much as a software compromise, because machine credentials often sit in the same workstation or container context as untrusted code. Security teams need to view developer endpoints, CI runners and publishing pipelines as shared credential surfaces.
Self-propagation is what makes package compromise operationally dangerous: once stolen developer credentials can publish poisoned updates, the incident becomes a distribution problem with compounding reach. This is the point where package provenance, publisher authentication and release integrity become inseparable. The practitioner takeaway is to reduce the chance that one compromised build context can seed many downstream installations.
Environment isolation is the control gap this article exposes: the malicious code succeeds because trusted tooling and sensitive credentials coexist too closely in the same execution boundary. That failure mode is not unique to npm or PyPI; it is a broader issue in modern CI/CD and developer workflows. Organisations should therefore design for credential compartmentalisation rather than assuming package trust will hold.
Package execution is now part of the threat model for identity systems: credentials stolen from a build host are not just secrets loss, they are an access-control failure that can reach cloud control planes, Kubernetes clusters and internal repos. This makes software supply chain defence a shared concern for IAM, PAM, NHI governance and application security teams. The control objective is to prevent untrusted code from inheriting reusable authority.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Credential blast radius now begins at install time: package ecosystems are no longer just software distribution channels. Once post-install execution is allowed near cloud credentials, the same dependency event can become an identity compromise, a secrets exposure and a downstream supply chain issue at the same time.
Third-party exposure is the hidden dependency risk: 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. That makes developer tooling, partner access and publishing workflows part of the trust perimeter, not exceptions outside it.
Package trust gap: the critical governance failure is assuming that trusted registries equal trusted execution. In practice, the control point is whether credentials can be reached by unreviewed code inside build and runtime environments.
For practitioners
- Disable package script execution by default Turn off post-install and lifecycle scripts in development and build environments unless a package has been explicitly reviewed and required for a specific workflow.
- Rotate exposed cloud and SSH credentials immediately Assume AWS, Azure, Google Cloud, SSH and Kubernetes secrets on affected systems may be compromised and revoke or reissue them before further use.
- Separate publishing credentials from build credentials Keep package publication tokens, cloud access keys and runtime secrets in different stores with different identities so one compromise cannot write back into the supply chain.
- Reinstall from a clean, known-good state Clear local caches, verify package-lock.json and requirements.txt against approved versions, and rebuild affected systems from trusted sources only.
Key takeaways
- Package compromise now functions as an identity attack because malicious dependencies can reach cloud keys, SSH keys and Kubernetes secrets during normal installation and execution.
- The article shows how a single dependency event can expand into publishing-pipeline abuse when stolen developer credentials are reused to ship poisoned updates.
- Containing this class of incident depends on isolating secrets, disabling unnecessary package scripts, and rebuilding from a clean trusted state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on package code stealing cloud and SSH secrets from execution environments. |
| NHI-03 — Vulnerable Third-Party NHI | Compromised npm and PyPI packages behave like untrusted third-party identities in the software supply chain. | |
| NHI-07 — Long-Lived Secrets | Stolen cloud credentials remain useful because they often outlive the install event that exposed them. | |
| Recommendation — Scan package workflows for secret leakage and revoke any exposed credentials immediately. Assess third-party package trust as an identity risk and restrict what external code can reach. Shorten credential lifetimes and rotate any long-lived secrets present on affected systems. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat path moves from secret harvesting to broader access through reused developer credentials. |
| Recommendation — Map the incident to credential access and lateral movement and hunt for reuse of compromised identities. | ||
| CIS Controls v8 | CIS-5 — Account Management | The attack depends on unmanaged developer and publishing accounts retaining excessive reach. |
| Recommendation — Review account ownership, publishing permissions and stale access under CIS-5. | ||
Key terms
- Package Supply-Chain Compromise: A package supply-chain compromise occurs when a trusted software dependency is altered so that installing or importing it runs attacker-controlled code. In identity terms, the dependency inherits ambient trust and can then reach secrets, tokens, or cloud metadata that were never meant to be exposed to the package itself.
- Postinstall Script: A package lifecycle hook that runs automatically after installation. It is useful for legitimate setup tasks, but it also creates an execution path that can be abused to run malicious code as soon as a dependency is installed.
- Cloud Credential Exposure: Cloud credential exposure occurs when access keys, CLI profiles, or other authentication material are accessible to malware or unauthorised users. These secrets can unlock infrastructure, storage, and admin functions quickly. Once exposed, they should be assumed compromised and rotated as part of incident response.
- Publishing Pipeline Abuse: Publishing pipeline abuse happens when an attacker uses legitimate release tooling or account access to push malicious software updates into public or internal registries. The risk is not only initial infection but also downstream propagation through trusted update channels.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a fit for practitioners who need to connect machine identity control to broader security governance.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org