Npm and PyPI supply chain attacks are stealing cloud credentials

At a glance

What this is: This is an analysis of active npm and PyPI supply chain compromises that use malicious package code to steal cloud, SSH, and Kubernetes credentials.

Why it matters: It matters because package trust is now an identity and secrets problem, affecting how IAM, PAM, and NHI teams govern developer credentials, workload secrets, and third-party software execution.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Expel's analysis of the npm and PyPI supply chain compromises

Context

Package compromise becomes an identity problem the moment malicious code runs in a trusted build or developer environment. In this case, the security failure is not just in the package registry, but in the assumption that installed dependencies are safe to execute and safe to inherit environment credentials from.

Expel describes two active supply chain incidents affecting npm and PyPI packages, both aimed at stealing credentials from systems that load compromised versions. That places cloud access keys, SSH material, and Kubernetes secrets in the blast radius of routine software installation, which is a familiar failure pattern rather than an isolated anomaly.

For IAM and NHI teams, the key issue is lifecycle control over credentials that are present during package install, build, and runtime execution. The starting position is common in modern engineering teams, which is exactly why this threat pattern keeps recurring.

Key questions

Q: How do security teams know if package-based secret theft is happening?

A: Look for unusual DNS activity, recent dependency installs, and new access attempts from accounts that should not be active on the affected endpoint. Correlate those signals with secret rotation events and suspicious file access in user profiles and build runners. If the malware cleaned up after itself, telemetry correlation is often the only reliable clue.

Q: Why do compromised packages create such a large identity risk?

A: Because they often run inside environments that already contain reusable secrets, tokens, and service accounts. Once malicious code executes, it can steal non-human credentials at the moment they are most accessible, then reuse them exactly as legitimate automation would.

Q: What do teams get wrong about secrets in build automation?

A: Teams often assume build secrets are safe because the job is temporary, but the credential usually outlives the run. Once a token is stolen, it behaves like any other NHI with its own lifecycle, scope, and blast radius, so inventory, revocation, and rotation matter more than workflow speed.

Q: How can organisations reduce blast radius after a package compromise?

A: Separate credentials by function, make them short-lived, and avoid reusing the same secret across build, test, publish, and runtime workflows. If one package is compromised, the attack should not be able to move from a local install into cloud access or software publishing.

Technical breakdown

How malicious package installs become credential harvesters

Modern package managers often execute installer hooks such as post-install scripts. That gives a compromised dependency immediate code execution in the developer or CI environment, with access to environment variables, local files, and cloud metadata paths. In this incident pattern, the package is not the final payload. It is the delivery mechanism that lets attackers run code in a trusted context and read whatever secrets are already present. The risk rises when build systems reuse the same credentials for publishing, deployment, and automation.

Practical implication: disable unnecessary install-time execution and treat package installation as a privileged runtime event, not a passive file copy.

Why cloud and workload secrets are exposed so quickly

Cloud access keys, SSH keys, and Kubernetes secrets are attractive because they often exist in plaintext or easily retrievable configuration surfaces during build and runtime. Once malicious code executes, it can scrape environment variables, mounted files, credential caches, and orchestration metadata before defenders notice. That makes the exposure window short and the detection problem hard, especially when credentials are shared across engineering tooling. In practice, the attack succeeds because secrets are reachable at the moment untrusted code is executed.

Practical implication: separate build-time credentials from deployment-time and runtime secrets, and restrict what any package install can read.

Supply chain compromise and NHI governance

Supply chain attacks increasingly intersect with non-human identity governance because the stolen material is usually not a human password but service credentials, API keys, tokens, and automation accounts. Those identities often have standing privilege, broad reuse, and weak offboarding discipline. Once stolen, they can be used exactly as intended by legitimate automation, which makes attribution and containment difficult. The governance gap is not only software trust. It is also the failure to treat developer and workload secrets as governed identities with lifecycle controls.

Practical implication: inventory every secret-bearing non-human identity used in software delivery and apply lifecycle controls to each one.

Threat narrative

Attacker objective: The attacker wants durable access to developer and cloud environments by converting package trust into reusable credential theft and downstream supply chain abuse.

1. Entry occurs when a developer or CI/CD pipeline installs a compromised npm or PyPI package that contains malicious post-install code.
2. Credential access follows immediately as the code harvests cloud keys, SSH keys, Kubernetes secrets, and other environment-resident secrets from the host.
3. Impact occurs when stolen credentials are reused to access cloud resources, modify software, or publish malicious updates from trusted accounts.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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

NHI Mgmt Group analysis

Package trust is now an identity boundary. The practical mistake is treating dependency installation as a software-only concern when it is also a secrets-exposure event. Malicious install hooks can inherit whatever non-human identities are present in the build environment, including cloud keys and publishing credentials. That means software supply chain governance and NHI governance now overlap directly, especially where developer automation has standing privilege. Practitioners should treat package execution as a governed access decision, not a harmless install step.

Standing secrets create the real blast radius. These incidents work because credentials are available at the wrong moment and remain valid long enough to be reused. If a package can read a key during installation, the attacker does not need persistence in the original environment to keep the impact alive. That is a lifecycle failure, not only a malware problem, and it maps cleanly to the OWASP Non-Human Identity Top 10 and secrets handling disciplines.

Credential sprawl is the named failure mode here. The issue is not just secret theft, but the number of places where secrets exist and the ease with which they can be copied into build, runtime, and publishing workflows. When the same credentials support multiple systems, a single compromised package becomes an access multiplier. The field needs to stop assuming that package registries and secret stores are separate control planes.

AI-serving infrastructure widens the attack surface for non-human identities. The xinference compromise shows that model-serving software can be an identity collector as easily as a traditional CI component. As AI pipelines increasingly depend on service accounts, cloud tokens, and orchestration secrets, the control problem shifts from static software trust to runtime identity containment. Practitioners should align AI deployment controls with NHI lifecycle governance, not general application security alone.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Forward look: See Top 10 NHI Issues for the governance patterns that make secret exposure persistent across engineering workflows.

What this signals

This pattern should push teams to treat dependency execution as part of identity governance, not just software supply chain hygiene. Once package installs can read live credentials, the control objective becomes reducing the number of secrets available to untrusted code and shortening their usable lifetime.

Credential-in-build risk: the presence of production-capable secrets inside installation and CI paths is now a measurable governance issue, not a hypothetical one. Teams should map where package tooling can reach service accounts, cloud keys, and registry tokens, then align those flows with OWASP Non-Human Identity Top 10 guidance.

The next maturity step is to make secrets compartmentalisation visible in engineering policy, because secret sprawl and package sprawl compound each other quickly. That means stricter separation between publishing, deployment, and runtime identities, plus more disciplined review of what any third-party package can execute or inherit.

For practitioners

• Disable install-time script execution Set package managers to block post-install hooks by default, then allow execution only for explicitly approved dependencies that have been reviewed and pinned. This reduces the chance that a compromised package can run arbitrary code during installation.
• Rotate exposed cloud and publishing credentials Assume any key present on a system that loaded a compromised package may be exposed. Rotate AWS, Azure, GCP, SSH, and registry credentials first, then review where those secrets were stored and how widely they were reused.
• Rebuild from a clean dependency state Clear local caches, remove untrusted artifacts, reinstall from known-safe versions, and verify lockfiles and requirements files for unauthorized changes. This matters because reusing the same workspace can reintroduce the malicious package or preserve stolen material.
• Separate build and runtime secrets Use short-lived, task-scoped credentials for CI/CD and keep publishing permissions distinct from deployment permissions. The goal is to prevent a package install from inheriting broad access that can be reused outside the original session.

Key takeaways

• Supply chain compromises are now credential theft events as much as code integrity events.
• The biggest control gap is not package installation itself but the presence of reusable secrets in environments that execute untrusted code.
• Teams should shrink blast radius by blocking install hooks, separating credentials by function, and rotating anything exposed to a compromised package.

Key terms

• Software Supply Chain Compromise: A software supply chain compromise is an attack that inserts malicious code into trusted build, package, or deployment paths. The goal is often not immediate application failure, but secret theft, persistence, or unauthorized changes that travel downstream through automated systems.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full analysis

Expel's full blog covers the operational detail this post intentionally leaves for the source:

• The specific malicious package behaviour observed in the npm and PyPI campaigns, including the post-install mechanics and credential harvesting paths
• Indicator of compromise details and file artefacts that security teams can use to confirm exposure in developer environments
• Step-by-step response actions for clearing caches, rebuilding environments, and validating whether package-lock or requirements files were altered
• Source references to the underlying JFrog and Socket research for teams that need to trace the compromise chain more deeply

👉 Expel's full post covers the attack chain, credential theft paths, and response steps for affected environments.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with the software delivery and access paths this article exposes.