The Miasma Worm Is Targeting AI Developers: What You Need to Audit Now

The Miasma worm campaign has shifted tactics in a way that makes AI developers the primary target. What started as poisoned PyPI packages in May 2026 escalated on June 5, 2026 into an attack that plants credential-harvesting code directly into GitHub repositories - code that fires automatically the moment you open the repo in your AI coding tool. 73 Microsoft repositories were disabled, CI/CD pipelines broke globally, and 57 npm packages with over 600,000 monthly downloads were found infected.

If you work with AI coding agents in your development workflow, this is not theoretical. This is the threat model your tools were not designed to defend against.

Last updated: June 10, 2026

What Miasma Is

Miasma is a self-propagating worm campaign attributed to a threat group known as TeamPCP (though Ox Security researchers note the current npm variant appears to be a copycat using open-sourced TeamPCP code). The malware steals credentials from AWS, Azure, GCP, Kubernetes, GitHub, npm, Docker, and 90+ developer tool configurations, then uses those stolen credentials to spread to additional repositories and re-publish infected packages.

The worm's signature string in infected GitHub repositories is "Miasma - The Spreading Blight." That string first appeared in repos on June 4, 2026, from the same infected account (windy629) researchers had tracked through previous attack waves.

What makes the June 2026 variant distinctive is not just what it steals - it is how it executes. Previous variants relied on npm postinstall hooks, PyPI setup.py hooks, or package import side effects. The June 5 attack skips the package manager entirely. It plants configuration files that trigger automatic code execution when a developer opens a repository in their editor.

Cloning a repo is safe. Opening it in your AI coding tool is not.

Scope: 73 Microsoft Repos, 57 npm Packages, 600K Downloads

The damage from the June 5 incident alone was significant:

• GitHub disabled 73 repositories across four Microsoft GitHub organizations (Azure, microsoft, Azure-Samples, MicrosoftDocs) in a 105-second automated sweep
• Azure/functions-action - the official GitHub Action for deploying Azure Functions - went offline, breaking CI/CD pipelines globally
• Within hours, 20+ developers reported broken pipelines in a Microsoft Learn Q&A thread

The npm wave, first documented by Ox Security on June 4, showed a wider blast radius:

• 57 npm packages infected across the broader campaign
• 647,204 monthly downloads affected
• 118+ GitHub repositories found containing stolen credentials

The @vapi-ai/server-sdk and ai-sdk-ollama packages were among the higher-profile affected npm packages, given their direct use in AI application development.

How It Spreads: CI/CD and AI Tool Hijacking

The June 5 attack used a single malicious commit (5f456b8) pushed to Azure/durabletask via a previously compromised contributor account. The commit claimed to be a code change ("Switched DataConverter to OrchestrationContext") but modified zero source files. It included [skip ci] in the commit message to suppress CI pipeline execution, and the commit timestamp was backdated six years to 2020.

The commit planted five files targeting four different developer tools:

All four vectors point to the same 4.6 MB obfuscated JavaScript payload. The Claude Code and Gemini CLI hooks fire through SessionStart configuration. The Cursor hook is a prompt injection that instructs the AI agent to run the script by framing it as a "project setup requirement." The VS Code task fires without any AI involvement at all.

The earlier npm wave used a different evasion: instead of postinstall scripts (which security tools now inspect closely), it used a pre-configured binding.gyp file that achieves the same execution behavior through the native addon build path.

Which npm Packages to Audit

If any of these packages are in your dependency tree, check whether you installed an affected version. The full list from Ox Security's analysis includes 57 packages. High-priority packages for AI developers include:

A second wave of infected packages using the binding.gyp vector was also confirmed, with additional packages including creditcard.js (3.0.60), dbmux (2.2.4), and several @forjacms/* packages at version 1.8.4.

Run npm ls <package-name> or audit your package-lock.json against this list. If you installed an affected version, rotate all credentials immediately and treat the system as compromised.

Why AI Developers Are the Specific Target

AI developers represent an unusually high-value target profile for credential theft:

Cloud credential density. AI pipelines typically need simultaneous access to AWS (model hosting, S3), Azure (OpenAI endpoints, Azure Functions), GCP (Vertex AI, Cloud Storage), and GitHub. A single compromised machine can yield credentials for all of them.

Agent automation expands the attack surface. Agentic workflows that automatically clone repos, install dependencies, and open projects create a continuous pipeline of exposure. An agent that clones 10 repos per day and opens them in Claude Code is a credential harvester running 10 times daily.

Configuration files as attack vectors. The .claude/settings.json, .cursor/rules/, and .gemini/settings.json conventions that make AI tools powerful also make them targetable. These files are typically trusted implicitly when they appear in a repository. The June 5 attack exploited exactly that trust.

High-value secondary targets. AI developers often work on codebases with significant IP value - fine-tuned models, proprietary prompting infrastructure, internal agent tooling. The credentials are valuable; so are the repos themselves.

Hardening Your AI Workflow

Immediate: Audit for Compromise

If you cloned any of the 73 affected Microsoft repositories between June 2 and June 5 and opened them in VS Code, Claude Code, Cursor, or Gemini CLI, StepSecurity recommends treating the system as compromised and rotating all credentials: GitHub tokens, npm tokens, AWS keys, Azure service principals, GCP service accounts, SSH keys, Kubernetes secrets, and Docker configs.

Check your own repositories for unexpected commits containing .claude/, .gemini/, .cursor/, .vscode/tasks.json, or .github/setup.js files. Check npm and PyPI for unauthorized version publishes. Audit network logs for connections to check.git-service[.]com and t.m-kosche[.]com, which are known Miasma C2 domains.

Dependency Pinning

Mutable version tags are a single point of failure. The Azure/functions-action@v1 outage demonstrated this directly: when the repository was disabled, every CI/CD pipeline referencing that mutable tag broke immediately. A pipeline pinned to a specific commit SHA would have failed loudly and predictably rather than silently depending on whatever tag resolves.

For GitHub Actions: use StepSecurity's Secure Repo or equivalent tooling to pin all actions to commit SHAs. For npm: use exact versions in package.json and commit your lockfile. For PyPI: use exact version pins and consider hash-based verification.

SBOM Practices

A Software Bill of Materials gives you an inventory to diff against known-compromised version lists. Generate SBOMs on every CI build using cyclonedx-npm, syft, or similar tooling. When a new compromise is disclosed, diffing your SBOM against the affected package list takes minutes instead of a manual audit of your dependency tree.

GitHub Actions Permission Scoping

The GITHUB_TOKEN in your CI environment should have the minimum required permissions. Add explicit permissions: blocks to your workflow files:

permissions:
  contents: read
  packages: write  # only if needed

Default permissions in many organizations are far broader than necessary. A compromised action with default permissions can read secrets, write to packages, and push commits.

Restrict Outbound CI/CD Access

Miasma's C2 infrastructure requires outbound network connectivity. Restricting CI/CD runners to known egress endpoints - using StepSecurity's Harden Runner or equivalent - would have blocked the credential exfiltration even if the malicious code had executed.

What This Means for Managed Agents and Automated Pipelines

If you run automated pipelines where an AI agent clones repositories and works on them autonomously - a pattern increasingly common in agentic coding workflows - the attack surface is materially larger than traditional developer workflows.

The specific risk: a managed agent that clones a repository containing malicious .claude/settings.json configuration will trigger the payload on the next session start. That agent likely has broad API credentials to do its job. Those credentials are now in the attacker's hands.

Practical mitigations for automated pipelines:

• Scan cloned repositories for AI tool configuration files (.claude/, .gemini/, .cursor/, .vscode/tasks.json) before opening them in an AI coding session
• Run agent sessions in sandboxed environments with minimal credential scope - only the credentials the agent actually needs for the specific task
• Use short-lived credentials (OIDC tokens, temporary AWS credentials) rather than long-lived API keys in agent environments
• Monitor for unexpected outbound network connections from agent processes

The shift from "execute on package install" to "execute on folder open" is a signal that the supply chain threat model is widening to include developer tooling itself. The session hooks that make AI coding tools powerful are now a documented attack vector. Treating every cloned repository as potentially hostile - before your editor touches it - is not paranoia at this point. It is the correct operational posture.

FAQ

What is the Miasma worm?

Miasma is a self-propagating supply chain attack campaign that steals developer credentials from cloud platforms (AWS, Azure, GCP), GitHub, npm, Docker, and Kubernetes. It spreads by using stolen tokens to publish infected package versions and push malicious commits to repositories it gains access to.

Which developers are at risk from the June 5 Microsoft attack?

Developers who cloned any of the 73 affected Microsoft Azure repositories between June 2 and June 5, 2026 and opened those repositories in VS Code, Claude Code, Cursor, or Gemini CLI. If that applies to you, rotate all credentials on that machine immediately.

Were all versions of @vapi-ai/server-sdk and ai-sdk-ollama affected?

No. Only specific versions were infected. For @vapi-ai/server-sdk, the affected versions are 0.11.1, 0.11.2, 1.2.1, and 1.2.2. For ai-sdk-ollama, versions 0.13.1, 1.1.1, 2.2.1, and 3.8.5 were affected. Check the full list in the Ox Security report and verify which version is in your lockfile.

Does cloning a compromised repo automatically infect my machine?

No. According to StepSecurity's analysis, cloning a repository containing the malicious files is safe. The payload triggers when you open the repository folder in an AI coding tool or IDE that processes the planted configuration files.

How do I pin GitHub Actions to commit SHAs?

Replace the mutable tag reference (e.g., uses: some-action@v2) with the specific commit SHA of that tag (e.g., uses: some-action@abc123def). StepSecurity's Secure Repo tool can automate this across your workflows. After pinning, the action will not silently change even if the upstream tag is modified or the repository is disabled.

Is Azure/functions-action back online?

Microsoft described the disabling as an "internal management issue under investigation" as of June 5, 2026. Microsoft's recommended workaround was to use Azure CLI, Azure DevOps Pipelines, VS Code deployment, Zip Deploy, or Azure Pipelines as alternatives while the repository remained unavailable.

Official Sources

• StepSecurity: Miasma Worm Hits Microsoft Again - Primary forensic analysis of the June 5 incident
• The Hacker News: Miasma Worm Hits 73 Microsoft GitHub Repositories - News coverage of the incident
• Ox Security: 600,000 Monthly Downloads Affected - Full npm package affected list and technical analysis
• StepSecurity: Miasma Worm binding.gyp Campaign - Earlier campaign analysis