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 turns package installation into a code-execution and secret-theft path, with propagation across dozens of packages and malicious versions.

Why it matters: It matters because CI/CD pipelines, developer workstations, and AI coding tools can all become identity-adjacent attack surfaces when package trust, secrets handling, and runner isolation fail together.

By the numbers:

• A self-spreading npm worm dubbed Miasma compromised 57 npm packages across 286+ malicious versions.

👉 Read Semgrep's analysis of the Miasma npm worm and secret theft chain

Context

The primary issue here is not just malicious code in npm, but the abuse of build and install trust to execute code without the usual lifecycle-script visibility. In practice, package installation becomes a privileged execution path that can reach secrets, runners, and developer tooling before conventional detection catches up. The npm supply chain is the subject, but the governance gap is broader: organisations still treat package trust, credential exposure, and workstation persistence as separate problems.

That separation is increasingly unrealistic because modern development environments concentrate secrets in CI/CD systems, cloud credentials, and AI-assisted coding workflows. Once an attacker can execute during install, the blast radius expands from a single dependency to the identity material that holds the environment together. For identity and access teams, the relevant question is how package provenance, secrets isolation, and ephemeral runner controls intersect.

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 do exposed secrets in CI/CD pipelines create such a large blast radius?

A: CI/CD systems often hold cloud credentials, deployment tokens, and repository access in the same execution context. When malicious code runs there, it can collect secrets from environment variables, files, and process memory, then reuse them across cloud and source control. The more privileged the runner, the larger the downstream impact.

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: How should organisations respond when a supply chain worm reaches cloud credentials and developer tools?

A: Containment should start with credential rotation, runner isolation, and repository forensics across any affected build or test systems. Teams should also inspect workstation and assistant configuration artefacts, because persistence may survive package removal. Finally, treat all package installs from the affected window as untrusted until validated.

Technical breakdown

How binding.gyp turns npm install into code execution

binding.gyp is normally used to describe native build targets, but npm can invoke build-time actions that run during install. In this case, the worm uses command substitution inside the build file so code executes without a conventional preinstall or postinstall script in package.json. That matters because many detection and policy controls key off lifecycle scripts, while build-time execution can still reach the same runtime outcome. The result is a stealthier trust bypass that lives inside an expected package workflow.

Practical implication: inspect build metadata and package provenance, not just package.json lifecycle hooks.

How the worm harvests secrets from developer and CI environments

The payload targets cloud credentials, GitHub Actions secrets, and local password-store material, then exfiltrates them to attacker-controlled repositories. Its use of /proc/*/mem to extract secrets from runner memory is especially important because it shows the attacker is not limited to files at rest. Once secrets are in memory or environment variables, process-level access can still expose them. This is a secrets-management failure as much as a malware issue, because the attack depends on privileged credentials being present during build and test activity.

Practical implication: reduce secret residency in runners and scope credentials to the shortest possible task window.

Why AI coding-assistant backdoors change the persistence model

The worm also modifies AI coding-assistant configuration files such as Claude, Cursor, Gemini, and VSCode-related settings. That creates a persistence layer inside the developer workflow, where future code suggestions can be influenced even after the initial malicious package is removed. This is not just data theft. It is an attempt to corrupt the software creation process itself by turning trusted assistant contexts into a delivery channel for poisoned output. For security teams, AI tooling is now part of the software supply chain.

Practical implication: include AI assistant configuration files in workstation and pipeline integrity checks.

Threat narrative

Attacker objective: The attacker aims to turn trusted package installs into a scalable channel for stealing credentials, maintaining persistence, and poisoning software delivery workflows.

1. Entry occurs through npm package installation, where a malicious binding.gyp file triggers arbitrary code execution without a standard lifecycle-script indicator.
2. Credential access follows as the payload harvests cloud keys, GitHub Actions secrets, and password-store material from runners and developer environments, including process memory.
3. Impact is achieved through exfiltration to attacker-controlled repositories, propagation across reinfected packages, and persistence in AI coding-assistant configuration files.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Software supply chain compromise is now an identity problem as much as a code problem. Miasma does not need to break encryption or exploit a zero-day in the classic sense. It abuses the trust relationship between package install processes and the credentials available to those processes. That means build systems, developer laptops, and CI runners have become identity-bearing environments that must be governed like privileged infrastructure. Practitioners should treat package provenance and secret exposure as one control plane, not two.

The real failure mode is secret residency during execution. The worm works because credentials are available at the moment malicious code runs, whether in environment variables, files, or process memory. That is the standing exposure window that turns routine installs into lateral movement opportunities. The specific governance concept here is execution-time secret residency, and it deserves the same scrutiny as standing privilege in human IAM. Teams should minimise the time secrets exist in runnable contexts.

AI coding tools are becoming part of the attack surface, not just a productivity layer. By planting backdoors in assistant configuration files, the worm tries to influence future code generation after the initial compromise. That creates governance debt across human and machine workflows because the software creation process itself can be corrupted. For identity teams, this is where NHI governance, workstation hardening, and software supply chain controls meet. The practitioner conclusion is simple: treat AI assistant state as managed configuration with integrity controls.

Package trust needs provenance plus runtime containment. Forged attestation and obfuscated build-time execution show that source verification alone is insufficient when installation can still execute arbitrary code. The control gap is not just signature validation, but the lack of containment around what an install can access once execution begins. This is where least-privilege pipeline design, secret scoping, and workload isolation become operational requirements, not optional hardening. Practitioners should assume package install is a privileged operation until proven otherwise.

From our research:

• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The attack pattern reinforces why runtime secret exposure and AI workflow compromise need unified governance rather than separate reviews.

What this signals

Execution-time secret residency is the governance gap this worm exposes. Once secrets are present in build, test, or assistant contexts, the attacker does not need a traditional credential dump to cause damage. Teams should reduce the number of places where secrets can exist during code execution and align that work with OWASP Non-Human Identity Top 10 guidance on secret sprawl and exposed credentials.

The signal for practitioners is that pipeline compromise and NHI governance are converging. Cloud keys, GitHub Actions secrets, and developer-tool state now behave like managed identities, so identity controls must extend into build systems, runners, and AI-assisted development environments. That should drive tighter scoping, stronger provenance checks, and workload-bound secret issuance in line with NIST SP 800-53 Rev 5 Security and Privacy Controls.

This also shifts detection priorities. Teams need visibility into package installation behaviour, repository exfiltration patterns, and endpoint artefacts left by coding assistants, because compromise may be iterative rather than one-shot. For organisations running broad software supply chain programmes, the relevant next step is linking developer workstation telemetry with secret rotation and NHI Lifecycle Management Guide processes.

For practitioners

• Lock down install-time execution paths Block or review build-file actions such as binding.gyp and other native build hooks in dependency pipelines, especially where package provenance is weak or unverified. Add explicit allowlists for packages that require compilation and isolate those builds from production credentials.
• Remove long-lived credentials from runners Use short-lived, task-scoped credentials for CI/CD and avoid placing cloud keys, GitHub Actions secrets, or password-store material on systems that execute third-party installs. Separate build identities from deployment identities and revoke any pipeline credential that could have been exposed.
• Scan developer AI tooling for persistence artefacts Check .claude, Cursor, Gemini, and VSCode configuration files for unauthorised changes, injected setup scripts, and rules that can influence generated code. Treat those files as integrity-sensitive assets and include them in endpoint and fleet-wide detection rules.
• Investigate package and repository exfiltration paths Search for repository contents under results/results-{timestamp}.json and review GitHub commit activity for the keyword thebeautifulmarchoftime. Use those indicators to identify which projects, runners, and accounts were touched before rotating credentials.

Key takeaways

• Miasma shows that npm install can be converted into a credential-theft and persistence channel without relying on obvious lifecycle scripts.
• The most exposed assets are cloud keys, CI/CD secrets, and AI coding-tool configuration, which turns software delivery into an identity-governance problem.
• Teams should respond by shrinking secret residency, hardening package provenance checks, and treating AI assistant state as security-sensitive configuration.

Key terms

• Execution-Time Secret Residency: The period during which credentials exist in memory, environment variables, files, or process context while code is running. It matters because malware does not need to steal a stored secret if it can read one at the moment the system uses it.
• Package Install Trust Boundary: The point at which a dependency is allowed to run code during installation or build. In supply chain attacks, this boundary is often weaker than teams assume, because build metadata and native compilation hooks can execute before ordinary review or monitoring controls trigger.
• AI Assistant Persistence: A compromise pattern where malicious configuration changes in coding assistants survive the original infection and influence future outputs. The risk is not just stolen data, but continued manipulation of development decisions and generated code after initial cleanup.

What's in the full analysis

Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:

• Package-by-package exposure mapping for the affected npm ecosystem and the versions that were touched
• Indicators of compromise for CI/CD, developer workstations, and repository exfiltration paths
• File and system artefacts linked to AI assistant persistence across Claude, Cursor, Gemini, and VSCode
• Recommended investigative steps for identifying compromised pipelines and rotating credentials after exposure

👉 Semgrep's full post covers the affected packages, indicators of compromise, and persistence artefacts in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It gives security practitioners a shared language for controlling credentials across pipelines, services, and AI-enabled development.