Miasma and IronWorm: Self-Replicating Worms Targeting AI Credentials

Key Takeaways

• During the week of June 1–5, 2026, two self-replicating supply chain worms—Miasma and IronWorm—emerged from the npm ecosystem explicitly targeting developer AI coding tool credentials, marking the first documented coordinated campaign to treat AI tool configurations as primary attack surfaces [1][5].
• Miasma compromised 57 npm packages across 286 or more malicious versions and subsequently spread into 73 Microsoft GitHub repositories, planting backdoor files in Claude Code, Cursor, Gemini CLI, and VS Code configurations that execute when those tools open affected projects [1][6].
• IronWorm, a Rust-built implant distributed through 37 npm packages [4] (sources vary by disclosure-window snapshot: JFrog’s primary research documented 43 [3], Bleeping Computer reported 36 [7]), carries an eBPF kernel rootkit that hides its activity from standard monitoring tools and communicates over Tor, while systematically harvesting API keys for Anthropic, OpenAI, Google Gemini, Cohere, Mistral, Groq, Perplexity, and xAI [3][4].
• Both worms propagate autonomously using stolen credentials—npm publish tokens, GitHub write access, and CI/CD OIDC tokens—to infect additional repositories and packages without further attacker interaction, blurring the established line between infostealer and worm.
• Organizations using AI coding assistants connected to cloud credentials must treat their AI tool configuration directories (.claude/, .cursor/, .gemini/) as trust boundaries subject to the same access controls as production secrets stores.

Background

The rapid adoption of AI coding assistants—tools such as Anthropic’s Claude Code, Cursor, Google Gemini CLI, and GitHub Copilot—has created a new category of high-value credential on developer workstations: AI provider API keys. These keys carry significant financial and operational risk, since unauthorized access can generate substantial inference costs, expose proprietary prompts and context, and in agentic deployments grant access to connected systems and data. Yet AI API keys often reside in shell profiles, .env files, and tool configuration directories that, in many development environments, receive less scrutiny than equivalent cloud provider credentials. By mid-2026, AI API keys have joined the set of credential types that threat actors actively target alongside AWS access keys, npm publish tokens, and GitHub Personal Access Tokens.

The npm ecosystem’s open publishing model and its central role in CI/CD pipelines make it a persistent attack surface for supply chain compromise. The pattern of injecting malicious preinstall hooks into npm packages—a documented attack technique in the npm ecosystem—has evolved considerably. Attackers now combine credential theft with autonomous propagation, creating worms rather than merely trojans. This shift is consequential for defenders: a trojanized package might be discovered and removed within hours, but a worm that has already replicated across dozens of repositories requires a broader incident response that can span weeks, particularly when propagation paths include CI/CD systems that automatically republish affected packages.

Against this backdrop, two distinct threat actors—or a loosely coordinated cluster operating across the same timeframe—launched the Miasma and IronWorm campaigns in the first week of June 2026. Their simultaneous emergence, targeting overlapping victim populations and credential categories with shared references to the earlier Shai-Hulud worm lineage, suggests a threat landscape that has matured to the point where AI coding tool configurations are now standard targets in the credential-harvesting toolkit [3][5].

Security Analysis

Miasma: From npm Worm to AI IDE Backdoor

The Miasma campaign’s first confirmed wave began on June 1, 2026, compromising 32 packages under the @redhat-cloud-services npm scope within 72 seconds [5]. A substantially larger second wave launched on June 3, ultimately compromising 57 npm packages across 286 or more malicious versions [5]. Packages with significant download volumes were among those affected: @vapi-ai/server-sdk, with more than 408,000 monthly downloads at the time of compromise, and ai-sdk-ollama, with approximately 120,000 monthly downloads, were both targeted [1].

The worm’s propagation mechanism employs a technique researchers at StepSecurity have termed “Phantom Gyp.” A 157-byte binding.gyp file uses command substitution syntax—specifically <!(node index.js > /dev/null 2>&1 && echo stub.c)—to trigger code execution during npm install without appearing in the package.json scripts section that most security scanners examine [1]. This technique allows the payload to execute before dependency resolution completes, before many runtime security controls activate, and without appearing in the install script audit most developers and CI pipelines treat as the primary indicator of malicious packages. The payload is defended by four layers of obfuscation: ROT-N Caesar cipher decoding, AES-128-GCM decryption, the Bun JavaScript runtime (downloaded at execution time to operate outside Node.js process monitoring), and obfuscator.io encoding across a 668 KB main payload with a 2,306-entry encrypted string table [1].

What distinguishes Miasma from prior npm infostealers is its deliberate targeting of AI coding tool configuration directories. The worm injects persistent backdoor files at multiple paths covering the most widely used AI-assisted development environments, including .claude/setup.mjs and .claude/settings.json for Claude Code, .cursor/rules/setup.mdc for Cursor, .gemini/settings.json for Gemini CLI, and .vscode/tasks.json for VS Code [1][2]. These files exploit the auto-execution capabilities of each tool—Claude Code’s SessionStart hooks, Cursor’s alwaysApply: true project rules, and VS Code’s folder-open task triggers—ensuring the backdoor executes whenever a developer opens an infected repository, regardless of whether they directly ran the compromised npm package [2]. A developer who installs a compromised package does not merely expose their current credentials; they create a persistent execution capability in their AI development environment that will activate in future sessions across any repository opened in those tools.

The credential harvesting scope spans the major cloud providers: AWS access keys, session tokens, and Instance Metadata Service queries; GCP service account keys and OAuth tokens; Azure managed identity credentials; HashiCorp Vault tokens; and GitHub Actions OIDC tokens and secrets [1]. A notably direct technique reads runner process memory to extract GitHub Actions secrets that would ordinarily be masked in logs, bypassing GitHub Actions’ secret-redaction mechanism entirely [1]. The worm also harvests npm and RubyGems authentication tokens and integrates with 1Password, gopass, and pass password manager interfaces. Exfiltrated data routes to GitHub dead-drop repositories under the account liuende501, which hosted 236 programmatically created repositories at the time of disclosure, with repository descriptions identifying themselves as “Miasma — The Spreading Blight” [1].

The campaign’s most visible impact materialized on June 5, 2026, when Miasma spread into 73 repositories across four Microsoft GitHub organizations: Azure, Azure-Samples, Microsoft, and MicrosoftDocs [6]. The initial foothold came through previously compromised contributor credentials, after which the worm committed itself autonomously into any repository the compromised contributor could access. GitHub disabled the affected repositories within 105 seconds of detection, but the incident demonstrated the worm’s capacity to traverse organizational trust boundaries and compromise high-profile, widely depended-upon open-source infrastructure [6].

IronWorm: eBPF Rootkit, Tor C2, and Systematic AI Key Harvesting

IronWorm, discovered by JFrog Security Research on June 4, 2026, represents a technically distinct but thematically convergent threat [3]. Where Miasma is JavaScript-based and targets AI tool configuration injection, IronWorm is a 976 KB Rust-compiled Linux ELF binary with capabilities that suggest a more operationally sophisticated threat actor [4]. The implant was distributed through 37 npm packages published from a compromised account named “asteroiddao” [4]—though disclosure-window snapshots vary, with JFrog’s primary research reporting 43 packages [3] and Bleeping Computer reporting 36 [7]. The affected packages—including weavedb-sdk, weavedb-client, arnext, aonote, cwao, roidjs, and zkjson variants—accumulated over 32,000 combined monthly downloads at the time of disclosure [3][4].

IronWorm’s technical engineering is notable across several dimensions. The binary uses a modified UPX stub with overwritten magic bytes specifically to defeat signature-based unpackers [3]. Internally, every string is encrypted with a unique per-call-site key, meaning that disassembly of any single function reveals no plaintext indicators of purpose or infrastructure. At runtime, the implant loads an eBPF kernel-level rootkit that hides its own processes and network connections by rewriting /proc entries in place, removing its footprint from ps, top, ls, and any tool that queries the same kernel interface [4]. The rootkit also sends SIGKILL to any process that attempts to attach via ptrace, actively defeating debugger-based analysis [3]. The combination of an eBPF rootkit and Tor-based C2 is consistent with threat actors operating at a higher capability tier than typical opportunistic package poisoners, though attribution to a specific actor type requires additional intelligence.

Command and control operates over Tor. IronWorm downloads the Tor expert bundle at runtime, writes its own torrc configuration, and beacons to an operator-controlled hidden service, providing encrypted communications that are resistant to network-level interception and jurisdictionally complex to take down [3]. The Tor-based C2, combined with eBPF process hiding, reflects an operational security posture designed to extend dwell time well beyond the initial compromise window.

The credential targeting is unusually comprehensive in its coverage of the AI provider landscape. IronWorm sweeps 86 environment variables and more than 20 credential file paths [4], with explicit targeting of the full current cohort of AI provider API key variable names: ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, COHERE_API_KEY, MISTRAL_API_KEY, GROQ_API_KEY, PERPLEXITY_API_KEY, and XAI_API_KEY [3]. The breadth of this list—covering not merely dominant providers but a broad cross-section of commercially available AI API providers—suggests that AI credentials have joined the set of credential types that this threat actor systematically targets, alongside cloud infrastructure keys and cryptocurrency wallets. Additional targeting encompasses cloud credentials across AWS, GCP, and Azure; Kubernetes secrets across namespaces and Vault backends; Docker and npm authentication tokens; SSH private keys; and Exodus cryptocurrency wallet seed phrases and passwords [3].

IronWorm’s propagation mechanism exploits npm’s Trusted Publishing OIDC token exchange. When executed on a CI runner with active federation, the implant exchanges the runner’s identity token for a short-lived, package-scoped publish credential without requiring any stored secret [3]. Any CI pipeline running an infected package becomes a publish vector, automatically propagating compromised versions to other packages owned by the victim without leaving credentials in environment variables or secrets stores. A separate propagation path commits backdated malicious code to GitHub repositories under a spoofed automation identity—critically, using the commit author name “claude” in an apparent attempt to cause analysts to attribute the commits to legitimate Anthropic AI coding activity [4][8].

The Emerging AI Credential Attack Surface

Considered together, Miasma and IronWorm define a new category of supply chain threat that explicitly models the developer AI tool ecosystem as an attack surface warranting specialized targeting. Several characteristics distinguish this class of attack from prior npm supply chain incidents. First, AI tool configuration directories have become first-class execution surfaces: they contain API keys, hold session state, and in many tools can be configured to execute arbitrary shell commands via hooks, rules, and tasks—a capability that Miasma exploits directly. Second, the worm architecture means that a single compromised developer can seed infection across dozens of repositories within the attacker’s first operational hour, before any detection signal has matured. Third, IronWorm’s explicit enumeration of AI provider environment variable names demonstrates that threat actors have cataloged these credential types and treat them as targets alongside established high-value credentials such as cloud provider keys.

The coordinated timing of these two campaigns—both active during the same week, both referencing the Shai-Hulud worm lineage, both targeting AI coding tool credentials, and both exploiting npm’s propagation trust model—suggests either a common threat actor or a shared operational playbook circulating in adversary communities [3][5]. Either interpretation suggests that AI coding tool credential targeting may become a recurring feature of supply chain campaigns—a development organizations should incorporate into their threat models.

Recommendations

Immediate Actions

Security teams should treat any binding.gyp, preinstall, or postinstall script executed by npm packages installed during the week of June 1–7, 2026 as a potential indicator of compromise and audit the corresponding packages against known Miasma indicators published by StepSecurity [1]. Developers who cloned affected npm packages during that window should rotate all credentials accessible from their development environments—not merely cloud credentials, but npm publish tokens, GitHub Personal Access Tokens, and AI provider API keys for every service. On Linux CI runners, any system that installed packages from the “asteroiddao” npm account during the June 4 window should be treated as potentially compromised at the kernel level; the IronWorm eBPF rootkit requires detection capabilities that extend beyond userspace process monitoring [4].

Incident responders should query repositories for unexpected files at the known Miasma injection paths: .claude/setup.mjs, .cursor/rules/setup.mdc, .gemini/settings.json with unexpected content, and .vscode/tasks.json with shell execution steps referencing external scripts. The presence of any of these files added by an unexpected commit—particularly one authored by “claude” or another automation-sounding identity—should be treated as a confirmed indicator requiring forensic investigation.

Short-Term Mitigations

Package integrity controls should be enforced as a baseline. Locking dependency versions with lockfiles verified against a trusted hash, enabling npm audit in CI pipelines, and evaluating tooling that validates package provenance attestations against Sigstore can raise the cost of future tampered-package campaigns. The Miasma campaign demonstrated that attackers can obtain valid Sigstore attestations for malicious packages using compromised publisher credentials [1], meaning attestation verification alone is not sufficient when the upstream signing identity may itself be compromised. Attestation verification remains a worthwhile layer in a defense-in-depth posture, but it cannot be the sole control.

AI tool configuration directories should be added to code review scope with the same scrutiny applied to GitHub Actions workflow files. The SessionStart hooks in Claude Code, alwaysApply rules in Cursor, and folder-open tasks in VS Code all represent executable trust that most existing code review workflows do not examine. Organizations should establish baselines for which AI tool configuration files are expected in each repository and configure alerting on unexpected additions. Treating .claude/, .cursor/, and .gemini/ directories as privileged paths in pull request policy is a practical starting point.

AI provider API keys should be stored in secrets management systems—not in shell profiles or .env files—and should be scoped to the minimum required permissions with short expiry windows. Long-lived, broadly scoped API keys shared across a developer’s entire local environment are inconsistent with the threat model these campaigns demonstrate.

Strategic Considerations

The npm Trusted Publishing OIDC mechanism, while beneficial for eliminating long-lived publish tokens from CI environments, has introduced a propagation vector that IronWorm exploits directly: an infected CI runner can republish packages without requiring any stored credential [3]. Package repository operators and the open-source community should evaluate whether OIDC-based publishing should incorporate additional safeguards—such as secondary approval for publish actions or rate limits on new version publication—to constrain the blast radius when a runner is compromised.

Organizations deploying AI coding assistants in enterprise contexts should evaluate whether the auto-execution capabilities of those tools—hooks, rules, and tasks—should be restricted to organization-approved configurations delivered through managed policy rather than repository-level files controlled by individual contributors. This architectural change treats AI tool configuration as privileged code subject to the same change management controls already applied to CI/CD workflow files.

The security community should develop detection content specifically for AI tool configuration injection. Current SIEM rules and endpoint detection logic do not systematically alert on unexpected additions to AI coding tool configuration directories. Building this detection capability requires both tooling updates and a shift in threat modeling that recognizes AI coding tool configurations as a distinct and now-targeted attack surface.

CSA Resource Alignment

The threat posed by Miasma and IronWorm maps directly to multiple CSA frameworks and working group outputs. CSA’s MAESTRO framework for agentic AI threat modeling provides a structured lens for understanding how AI coding assistants—which operate as agents with execution hooks, credential access, and the capacity to take automated actions—become attack vectors through supply chain compromise. The specific technique exploited by Miasma, injecting malicious SessionStart hooks and alwaysApply rules into AI tool configurations, is a concrete instantiation of trust boundary violations in agentic workflows that MAESTRO’s threat model addresses.

CSA’s AI Controls Matrix (AICM) addresses supply chain security controls for AI systems, including controls around tooling provenance, dependency integrity, and the management of credentials used by AI services. The AICM’s shared responsibility model is directly relevant here: securing AI API keys is a distributed responsibility spanning model providers (who should enforce short expiry and permission scoping), application providers (who should integrate with secrets management rather than flat credential files), and AI customers (who should apply the same credential hygiene to AI provider keys that they apply to cloud infrastructure credentials). Neither Miasma nor IronWorm required a vulnerability in the AI providers themselves; both exploited gaps in how those providers’ credentials are managed at the developer and CI layer.

CSA’s Software Transparency: Securing the Digital Supply Chain publication addresses the SBOM practices, CI/CD pipeline security controls, and open-source risk management disciplines that are directly implicated in the npm-based propagation mechanics of both campaigns. Its guidance on dependency verification and pipeline integrity is actionable against the preinstall hook attack patterns both worms rely upon. CSA’s Zero Trust guidance is also relevant: the lateral movement enabled by Miasma and IronWorm—exploiting stolen GitHub write access and npm publish tokens to replicate across organizational boundaries—illustrates the risk of implicit trust in developer credential ecosystems that have not been segmented by least-privilege principles or subject to continuous verification.

References

[1] StepSecurity. “Miasma npm Supply Chain Attack: Self-Spreading Worm via Phantom Gyp.” StepSecurity Blog, June 2026.

[2] SafeDep. “Miasma Worm Targets AI Coding Agent Configurations.” SafeDep.io, June 2026.

[3] JFrog Security Research. “IronWorm: Shai-Hulud’s Rustier Cousin.” JFrog Research, June 2026.

[4] Phoenix Security. “IronWorm (No CVE): Rust-Built npm Worm Ships an eBPF Rootkit, Tor C2, and a Self-Propagating Supply Chain Implant Across 37 Packages.” Phoenix Security, June 2026.

[5] The Hacker News. “IronWorm and New Miasma Worm Variant Hit npm in Supply Chain Attacks.” The Hacker News, June 5, 2026.

[6] Rescana. “Miasma Worm Supply Chain Attack: 73 Microsoft GitHub Repositories Compromised via AI Coding Tools.” Rescana, June 2026.

[7] Bleeping Computer. “New IronWorm Malware Hits 36 Packages in npm Supply-Chain Attack.” Bleeping Computer, June 4, 2026.

[8] Dark Reading. “Rust-Written IronWorm Hits NPM Supply Chain.” Dark Reading, June 2026.