Preinstall persistence shows where provenance breaks

Microsoft’s report on the Red Hat npm Miasma campaign is a clean warning for security operations teams: provenance can prove where a package came from, but it does not prove the build path was clean.

The attack affected 32 maliciously modified packages across more than 90 versions under the @redhat-cloud-services npm scope, according to Microsoft Threat Intelligence. The compromise came through the upstream RedHatInsights/javascript-clients CI/CD pipeline. That let the attacker publish trojanized packages through the legitimate GitHub Actions OIDC publishing workflow.

The uncomfortable part is not only that packages were poisoned. It is that the poisoned packages carried authentic provenance signatures. The attacker did not need to fake trust from the outside. The attacker abused a trusted path from the inside.

What changed#

The campaign used npm’s preinstall behavior as the first execution point. When a poisoned package was installed, the malicious preinstall hook ran automatically. That matters because install-time execution can fire through both direct and transitive dependency paths, including places where nobody manually runs the package.

Microsoft says the hook executed a heavily obfuscated 4.29 MB JavaScript dropper. The dropper unpacked multiple layers of obfuscation, decrypted payload material with AES-128-GCM, downloaded the Bun JavaScript runtime, and used Bun to launch a second-stage payload.

That process chain is operationally relevant: node to shell to bun to payload. Many teams monitor Node package behavior, npm scripts, and suspicious shell execution. Fewer treat a freshly downloaded alternate JavaScript runtime as part of the same detection story.

The payload targeted credentials from GitHub, npm, AWS, Azure, GCP, HashiCorp Vault, Kubernetes, and local developer systems. On developer machines, Microsoft says it looked for SSH keys, CLI credentials, browser data, and wallet data. In CI/CD environments, it scraped GitHub Actions runner memory for secrets, attempted privilege escalation with passwordless sudo, and tried to republish poisoned packages with forged SLSA provenance.

The campaign marker was “Miasma: The Spreading Blight.” The name is theatrical. The tradecraft is not. This is preinstall persistence used as a supply-chain pivot.

Why preinstall persistence matters#

Preinstall persistence is dangerous because it sits before normal application behavior. The package does not need to be imported by business logic. It only needs to be installed in the wrong place.

That changes the risk model for developers and CI/CD systems. A vulnerable dependency graph is not just a runtime exposure. It can become a credential exposure during install, restore, build, or test.

The strongest lesson is about trust boundaries. Provenance metadata is useful, but it is not a magic seal. If the attacker controls or contaminates the trusted publishing workflow, signed provenance can describe a compromised reality with perfect confidence.

This does not mean provenance is useless. It means provenance must be paired with operational checks: who can publish, which workflows can mint identity, which jobs receive secrets, and whether install scripts can execute in environments that also hold cloud or package-registry credentials.

Microsoft also reports worm-like propagation behavior. The malware attempted to compromise additional maintainer packages and republish poisoned versions. That is the difference between a stolen token incident and a package ecosystem incident. One credential can become a publishing path. One publishing path can become many downstream installs.

What to check#

The practical check starts with exposure. Teams should identify whether they installed affected @redhat-cloud-services packages or versions during the relevant window, then inspect CI/CD systems and developer machines that performed those installs.

For security operations, the higher-value checks are not limited to package names. Review install-time script execution, especially npm preinstall hooks, in pipelines that also had access to GitHub, npm, cloud, Vault, Kubernetes, or SSH credentials.

Check for unusual runtime downloads during package installation. In this case, Microsoft called out Bun being downloaded and used as part of the execution chain. That is a useful detection shape: package manager install, shell execution, runtime download, secondary JavaScript payload.

Review GitHub Actions runner logs and memory-sensitive secret exposure assumptions. Microsoft’s report says the malware scraped runner memory for secrets. That should push teams to treat compromised runners as credential incidents, not just contaminated build hosts.

Rotate exposed tokens where affected installs occurred. Priority should go to package-registry tokens, GitHub tokens, cloud credentials, Vault tokens, Kubernetes credentials, and SSH keys present on the same systems. A clean rebuild is not enough if the attacker already copied credentials.

For publishing workflows, check which repositories use trusted publishing through GitHub Actions OIDC. Confirm that only intended workflows can publish, branch and tag controls are enforced, and release jobs are not reachable from untrusted code paths.

This is also a useful moment to compare internal open source security controls with actual package behavior. A package can be signed, popular, scoped under a familiar namespace, and still carry malicious install logic if the release pipeline is compromised.

What not to overclaim#

The source material does not support treating every Bun download as malicious. Bun was abused here as a runtime to execute the payload and complicate Node-focused monitoring. The suspicious pattern is the context: npm install script, obfuscated dropper, runtime download, and credential-targeting behavior.

It also does not prove that provenance systems have failed as a category. The sharper point is narrower and more useful: provenance can authenticate the path, but it cannot make a compromised path safe.

The same restraint applies to attribution and impact. Microsoft describes the attack chain, affected package scope, credential targets, and mitigation steps with npm. Do not invent victim counts, legal outcomes, or confirmed downstream compromises beyond the evidence.

Operational takeaway#

The Red Hat npm Miasma campaign belongs in the security operations playbook because it attacks the quiet part of software supply chains: installation.

Preinstall persistence gives malware a clean opening before the application runs. CI/CD gives it secrets. Trusted publishing gives it legitimacy. Provenance gives defenders useful context, but only if they remember what it can and cannot prove.

The practical move is not panic. It is to narrow where install scripts can execute, reduce secrets available during dependency installation, harden trusted publishing workflows, and treat suspicious package installs in CI as possible credential compromise events.

That is the real lesson from this campaign: the package was the delivery mechanism, but the target was operational trust.