Miasma npm worm shows how package install becomes a secret-theft channel

At a glance

What this is: Miasma is a self-spreading npm worm that turned package installation into an execution and secret-theft channel, affecting 57 packages across 286+ malicious versions.

Why it matters: It matters because modern build pipelines can be compromised through install-time behaviour, and the blast radius now includes cloud secrets, runner memory, and AI assistant configs.

Context

npm package installation is not just a dependency management step. In this case, install-time code execution became the entry point for credential theft, persistence, and propagation, which means software supply chain trust failed before the application ever ran.

The identity angle is real even though this is a supply chain story. Cloud credentials, CI runner secrets, and AI assistant configuration files are all identity-bearing assets, and once they are harvested they can be reused across environments with very little friction.

This is typical of modern supply chain abuse rather than an edge case. Attackers increasingly treat install hooks, runner state, and developer tooling as one connected trust surface.

Key questions

Q: What breaks when npm package installs are allowed to execute code before inspection?

A: The control point disappears. If install-time code can run before review, malware can harvest secrets, alter workflows, and propagate before defenders see a stable artifact. That makes preinstall hooks an execution surface, not a packaging detail. Teams should assume installation is a potential compromise event and enforce policy before code reaches that stage.

Q: Why does secret theft from CI runners create such a wide blast radius?

A: CI runners often sit at the intersection of source code, deployment privileges, and cloud access. When attacker code can read runner memory or environment state, it can recover tokens that unlock multiple environments, not just one repository. That is why secrets exposed in pipeline runtime create immediate cross-system risk, especially when the same identity is reused across jobs.

Q: What do teams get wrong about securing AI coding assistants?

A: Teams often focus on code output and ignore the agent boundary, where file reads, tool outputs, and external content shape the next action. That misses the real control point. The right question is whether untrusted input can influence privileged behaviour before the code is even written or committed.

Q: Should organisations trust package provenance if the install behaviour is still suspicious?

A: No. Provenance can reduce uncertainty, but it does not neutralise malicious runtime behaviour when a package still executes code during install or reaches for secrets. Teams should treat provenance as one signal among several and require behavioural checks, dependency policy enforcement, and secret access monitoring before approval.

Technical breakdown

How binding.gyp turns npm install into code execution

binding.gyp is normally a native build configuration file, but here it was used to trigger command substitution during npm install. That matters because npm users often trust install-time compilation paths differently from lifecycle scripts in package.json, even though both can execute arbitrary code. The malware kept the triggering file tiny while hiding a much larger obfuscated payload in index.js, which let it blend into package structure and avoid obvious script flags. The result is execution without a declared lifecycle hook, so conventional package review that focuses only on package.json misses the real trigger path.

Practical implication: Treat native build triggers as executable content and inspect package artefacts beyond package.json before allowing them into CI.

How the worm steals secrets from runners and developer tools

Once executed, the payload searches for cloud credentials, GitHub Actions secrets, and local secret stores such as 1Password, gopass, and pass. The most worrying detail is direct extraction from runner process memory via /proc/*/mem, which means secrets can be harvested even when they are not written to disk. The malware also exfiltrates stolen data to attacker-controlled GitHub repositories, giving the operator a simple collection and staging channel. This is a classic secrets-harvest pattern, but the mix of cloud, CI, and local stores shows how broad the credential surface has become in developer environments.

Practical implication: Assume secrets are exposed at runtime, not just at rest, and constrain runner permissions plus memory-access visibility.

Why AI coding-assistant backdoors increase persistence

The worm does more than steal credentials. It drops configuration changes into Claude, Cursor, VSCode, and Gemini-related files so the backdoor can shape future AI-generated code and persist inside developer workflows. That is a form of workflow poisoning, not just malware persistence, because it alters the tooling that developers consult repeatedly. The propagation step also forges provenance attestations so reinfected packages look legitimate, which makes trust signals less reliable after the first compromise. The attacker is not only trying to maintain access, but to make the next development cycle carry the compromise forward.

Practical implication: Review AI assistant configuration files as part of endpoint and workstation hardening, not as harmless developer preferences.

Threat narrative

Attacker objective: The attacker wants to turn package distribution, CI/CD trust, and developer tooling into a repeatable channel for credential theft and reinfection.

1. Entry occurs during npm install when the malicious package uses binding.gyp to trigger command-substitution execution without a declared lifecycle script.
2. Credential access follows as the payload harvests cloud secrets, GitHub Actions secrets, and password-store material, including memory-based extraction from runner processes.
3. Persistence and propagation continue through AI assistant configuration backdoors and forged provenance attestations that help reinfected packages look legitimate.
4. Impact is the theft and reuse of developer and pipeline credentials, plus wider supply chain contamination across downstream package consumers.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

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

Install-time trust has become an identity problem, not just a software safety problem. When a package install can execute code, it can also reach cloud credentials, runner tokens, and developer secret stores. That means the security boundary is no longer the repository alone, but the full chain from package ingestion to ephemeral runtime identity. Practitioners should treat install-time execution as an identity-bearing event.

Secret theft now targets the runtime, not only the vault. The use of /proc/*/mem shows why secrets management cannot stop at encryption at rest or central vaulting. If workloads and pipelines can expose credentials in memory, then attacker value comes from runtime visibility and privilege scope. The governance gap is standing access inside build and developer environments.

AI coding-assistant configuration is becoming a persistence layer. Dropping files into Claude, Cursor, VSCode, and Gemini workflows shows that AI tooling can carry attacker state forward into future code generation. That creates a new form of workflow poisoning where compromised tooling changes what developers see and write next. Security teams should govern AI assistant configuration with the same seriousness as source control and CI settings.

Forged provenance only works because trust decisions are still too local. If reinfected packages can appear legitimate by reusing attestations, then provenance checking is necessary but not sufficient unless it is paired with behavioural validation at install and publish time. The broader lesson is that supply chain governance must correlate artefact identity, execution behaviour, and credential access in one control model.

Supply chain compromise and NHI abuse are converging in developer pipelines. The article is not just about malware in npm, it is about the abuse of non-human identities embedded in cloud, CI, and automation workflows. That makes OWASP-NHI and supply chain governance relevant together, because the same compromise path now crosses package integrity and credential governance. Practitioners should align identity controls to build and dependency trust, not treat them as separate domains.

What this signals

Install-time behaviour is now a governance boundary. Security teams need to stop treating package installation as a passive supply step and start treating it as a credential exposure event. That shift matters because the attacker value here came from runtime execution, not from a vulnerable application feature.

Workflow poisoning is the new persistence layer for developer environments. Once malware can touch AI assistant configs, source control hooks, and CI state, the compromise can outlive the original package. Practitioners should fold AI tooling state into endpoint governance and software supply chain reviews.

Provenance checks need behavioural companions. A signed or attested package can still be dangerous if it executes unexpected code while accessing secrets. The practical response is to pair provenance validation with install-time policy, runner hardening, and secret-scoped execution limits.

For practitioners

• Inspect install-time execution paths Block or review packages that execute code through binding.gyp, native build steps, or other install-time artefacts before they reach production pipelines.
• Reduce runner credential exposure Strip CI runners of standing cloud credentials and avoid passing long-lived tokens into jobs that can read process memory or write arbitrary files.
• Harden AI assistant configuration files Include Claude, Cursor, VSCode, and Gemini configuration paths in endpoint baselines so unexpected setup scripts or rules files are detected and quarantined.
• Verify provenance against behaviour Do not treat attestation alone as trust proof. Correlate provenance with install-time behaviour, repository changes, and secret-access patterns before approving a package family.

Key takeaways

• Miasma shows that package installation can be an execution path for secret theft, persistence, and reinfection, not just a dependency management step.
• The compromise reached cloud credentials, CI secrets, and local password stores, which means the operational blast radius extends far beyond npm itself.
• Defenders need to govern install-time behaviour, runtime secret exposure, and AI assistant configuration as one connected supply chain control problem.

Key terms

• Build-Time Code Execution: Build-time code execution occurs when a package install or build process runs commands before the software is fully installed. This is risky because dependency fetches, lifecycle scripts, and helper tools can execute with developer or root privileges. It turns ordinary package management into a potential host compromise path.
• Runner Memory Secret Extraction: The theft of tokens or credentials directly from a CI runner's process memory instead of from files or environment variables alone. This technique defeats controls that only protect secrets at rest and shows why build agents need runtime hardening, privilege minimisation, and tighter isolation.
• Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
• Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.

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. Explore the course if your programme needs a clearer model for governing machine identities, secrets management, and AI-driven workflows.