npm supply chain attacks: how the Miasma campaign infiltrates CI/CD pipelines and cloud credentials

On 5 August 2026, Microsoft presents at Black Hat USA in Las Vegas the most detailed picture yet of an attack category that is hitting IT teams with increasing frequency: supply chain attacks via npm. Attackers are no longer breaking into your systems directly. They are sitting one step earlier: inside the software packages and development tools that your developers rely on every day.

The Miasma campaign from early June 2026 is the most prominent recent example. In a single night, 32 npm packages belonging to the @redhat-cloud-services organisation were compromised. Every developer who subsequently installed any of those packages had unknowingly introduced a credential-stealing worm into their build environment. What makes this campaign particularly notable is that the attackers do not stop at one victim. The malware has its own propagation mechanism: it spreads itself further using stolen permissions.

How an npm supply chain attack works

The attack vector is technically elegant and difficult to stop. npm, the package manager for JavaScript and Node.js, supports so-called lifecycle scripts: small shell commands that are automatically executed at certain moments, such as when a package is installed. A preinstall script runs even before the actual package content becomes available.

In the Miasma campaign, the preinstall script contained a heavily obfuscated payload of 4.2 megabytes. The moment a developer or CI/CD system installed the compromised package, the payload started automatically. The script scanned the environment systematically for valuable files: GitHub tokens, npm authentication tokens, credentials for Azure, AWS, and Google Cloud, Kubernetes configuration files, Docker credentials, and locally stored SSH keys.

All discovered credentials were exfiltrated to attacker-controlled infrastructure. Then the worm behaviour began: the payload used the stolen npm tokens to republish itself into other packages that the compromised account had permission to modify. In this way the infection reached dozens of additional packages in a short time, without the actual package owners noticing anything.

Why CI/CD pipelines are the primary target

Build environments and CI/CD pipelines are more attractive than an individual developer laptop. The reason is straightforward: a CI/CD system centralises all credentials. A pipeline that builds applications and deploys them to Azure has access to service principals, deployment tokens, database passwords, and production keys. Whoever compromises that pipeline obtains access to far more than the code itself in a single move.

In addition, build agents typically run with broad permissions and operate in a trusted network segment. Security tooling that monitors production servers closely rarely applies the same scrutiny to what happens inside a build pipeline. This asymmetry makes the build environment the back door that attackers are now deliberately targeting.

A common assumption is that an organisation that does not itself install a malicious package is safe. That assumption is incorrect. Modern applications can have hundreds of transitive dependencies: packages that do not appear directly in your package.json but are pulled in indirectly because another package needs them. The attacker only needs to compromise one popular package. Through the transitive dependency chain, the payload then reaches the developers and CI/CD systems of organisations that never deliberately chose the infected package.

AI agents as a new attack surface

A theme Microsoft explicitly addresses at Black Hat 2026 is the growing risk for organisations deploying AI agents in their development processes. Agents that generate code, browse repositories, or run autonomous npm installations operate with broad privileges in a trusted environment. If such an agent is hit via an infected package, the impact can be greater than with a human developer: the agent may have direct access to cloud APIs, databases, or internal services without the additional manual checks a human would still apply.

This is not a hypothetical risk. The attackers behind Miasma used stolen tokens to automatically publish new malicious versions of packages. An AI agent with write access to an npm organisation is a direct amplifier for this kind of attack.

How to protect your environment

Five measures every IT or DevOps team can implement in the short term. First: switch from long-lived tokens to OIDC-based authentication in CI/CD pipelines. With OIDC tokens for trusted publishing, each build run receives a short-lived temporary token. If such a token is stolen, it expires almost immediately and provides the attacker no lasting access.

Second: configure npm to not run lifecycle scripts by default in your CI/CD system. Do this by adding the flag --ignore-scripts to npm install commands in your pipeline. This prevents preinstall and postinstall scripts from executing automatically. For most applications this changes nothing about the build output; the attack surface shrinks dramatically.

Third: pin your package versions explicitly in package.json and use a lockfile that is validated at every build. Attackers publish compromised versions as a new version number. Anyone who lets patch versions update automatically may pull in the infected version without realising. Manual version upgrades with a code review require more discipline but largely close this risk.

Fourth: use a private package registry as a proxy. Tools such as Azure Artifacts or JFrog Artifactory sit between your CI/CD system and the public npm registry. You can vet packages before they reach the build environment and maintain control over which versions are allowed. This is especially valuable for production environments.

Fifth: perform periodic audits of the permissions granted to CI/CD systems and service accounts. The fewer permissions a build agent holds, the more limited the damage if that system is compromised. Remove production deployment rights from build agents that are also used for testing. Separate test pipelines from deployment pipelines.

What the broader trend signals

The Miasma campaign and the typosquatting wave that immediately preceded it fit a clear pattern. Attackers are optimising their effort: one successfully compromised package with tens of thousands of downloads yields more victims than hundreds of individual phishing attempts. The term Microsoft uses at Black Hat is telling: attackers are no longer targeting CVEs but trust paths. They exploit the trust that developers and systems place in established packages from well-known organisations.

This makes software supply chain security an IT responsibility that extends beyond developers themselves. It involves managing secrets and credentials, the privileges granted to automated systems, and monitoring what happens inside build environments. Microsoft Defender for Cloud provides support for detecting suspicious activity in CI/CD environments, including signals on unexpected network connections from build agents and anomalies in package registry publishing behaviour. Want to know how to better secure your development environment and Azure tenant against supply chain risks? Contact Zarioh for a conversation about your specific situation.