Miasma Proves Trusted Publishing Can Backfire Spectacularly

The software supply chain security community has spent the last few years preaching the gospel of passwordless publishing. We were told that by moving away from long-lived registry tokens and adopting OpenID Connect (OIDC) and Supply-chain Levels for Software Artifacts (SLSA) provenance, we would secure our pipelines.

Then came Miasma.

This self-propagating worm, linked to the Mini Shai-Hulud and Hades malware lineages, has systematically dismantled the assumption that cryptographic signatures equal safety. By compromising developer identities upstream, Miasma does not bypass OIDC and SLSA. Instead, it exploits them to sign and distribute its payloads with legitimate cryptographic seals of approval. It is a highly coordinated campaign targeting npm packages, GitHub Actions workflows, and Go modules, proving that when the identity provider is compromised, our best security standards simply protect the malware.

The Mechanics of a Self-Propagating Worm

The Miasma campaign operates as a classic worm, but with modern cloud-native capabilities. The infection cycle typically begins with a compromised developer account. In the initial wave on June 1, 2026, an attacker compromised a Red Hat employee's GitHub account, using it to push orphan commits, which bypass standard branch-and-review workflows, to repositories under the RedHatInsights organization.

These orphan commits introduced a minimal GitHub Actions workflow that requested an OIDC token with id-token: write permissions. The workflow executed an obfuscated payload that published 32 backdoored packages across more than 90 versions under the @redhat-cloud-services npm scope. Because the publishing occurred within the legitimate CI/CD pipeline, the malicious packages carried authentic SLSA provenance signatures.

Once a downstream developer or CI/CD runner installs one of these poisoned packages, the malware executes and begins harvesting credentials. It targets SSH keys, cloud provider CLI credentials (AWS, Azure, GCP), HashiCorp Vault secrets, Kubernetes tokens, and npm publishing keys. If it finds valid npm OIDC tokens or publishing credentials, it immediately enumerates all repositories and organizations accessible to the compromised account. It then uses those tokens to publish backdoored versions of other packages the victim is authorized to maintain, extending its reach without manual intervention.

Bypassing Static Analysis with Phantom Gyp

As security teams began monitoring package.json lifecycle hooks (such as preinstall or postinstall scripts) for anomalous execution, the authors of Miasma adapted. In a subsequent wave on June 3, 2026, which compromised 57 npm packages including @vapi-ai/server-sdk and ai-sdk-ollama, the attackers introduced a technique called "Phantom Gyp."

Instead of declaring an installation hook in package.json, the malware includes a 157-byte binding.gyp file. The npm package manager automatically runs node-gyp rebuild if it detects this file during installation, assuming the package contains native C/C++ addons. Miasma abuses this native compilation step to trigger arbitrary code execution, completely bypassing static analysis tools that only scan package.json for lifecycle scripts.

Once triggered, the loader dynamically downloads the Bun runtime for the host platform (Linux, macOS, or Windows). Using Bun allows the secondary payload to execute complex JavaScript-based credential theft and evasion routines without relying on the host's Node.js environment or triggering standard runtime security agents.

Evasion, Dead-Drops, and the Scorched-Earth Tripwire

Miasma is highly evasive and actively hostile to security analysts. The malware includes a Russian locale killswitch, checks for the presence of endpoint security software, and detects analysis environments by looking for fake environment variables, Docker containers, and process names.

For command-and-control (C2) and exfiltration, the malware abuses public GitHub infrastructure. It creates public repositories on the fly under attacker-controlled accounts (such as liuende501) and uploads stolen credentials as encrypted JSON files. The malware identifies these dead-drop repositories using specific descriptions. Early waves used "Miasma - The Spreading Blight" or the reversed string "niagA oG eW ereH :duluH-iahS" (a direct taunt reading "Shai-Hulud: Here We Go Again"). Later iterations used the description "Alright Lets See If This Works" and the token relay marker "RevokeAndItGoesKaboom."

To deter security researchers and automated scanners from invalidating its stolen credentials, the malware incorporates a destructive tripwire. If it detects interaction with a planted decoy honeytoken, it triggers a fail-safe command (rm -rf ~/) designed to wipe the victim's home directory and Documents folder.

Expanding to Go and the IDE Attack Surface

The campaign has expanded beyond the npm registry. In late June 2026, researchers identified a compromise of the Verana Blockchain project's Go module (github.com/verana-labs/verana-blockchain@v0.10.1-dev.20).

Because Go modules do not support install-time lifecycle hooks like npm, the malware adapted its delivery mechanism. Instead of relying on build logic, it targets the developer's local environment. A developer who clones the repository and opens it in a trusted IDE or an AI coding assistant may trigger the payload through malicious project configurations. This shifts the attack surface from the package manager to the developer's workspace, exploiting the implicit trust we place in modern, highly integrated development environments.

Developer Angle: Hardening Your Supply Chain

Defending against a self-propagating worm like Miasma requires moving past basic dependency scanning. If a package has valid SLSA provenance and no obvious package.json install hooks, traditional scanners will greenlight it. Developers must implement defense-in-depth across their local machines and CI/CD pipelines.

1. Restrict OIDC Trust Policies

OIDC-based trusted publishing is only secure if the trust policy is tightly scoped. Do not use wildcard branch configurations in your registry's trust settings. Configure your npm or PyPI OIDC integration to only accept publishing requests from specific, protected branches (e.g., main) or specific GitHub Actions environments that require manual approval.

2. Implement Runtime Egress Filtering in CI/CD

Because Miasma must download the Bun runtime and exfiltrate stolen credentials to GitHub, blocking unauthorized outbound network connections from your CI/CD runners is highly effective. You can use tools like StepSecurity Harden-Runner to restrict egress traffic. A sample GitHub Actions configuration to block unauthorized outbound traffic looks like this:

name: Secure Build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Harden Runner
        uses: step-security/harden-runner@v2
        with:
          egress-policy: block
          allowed-endpoints: >
            github.com:443
            registry.npmjs.org:443
      - uses: actions/checkout@v4
      - name: Install Dependencies
        run: npm ci

3. Disable Install Scripts Globally

To neutralize both package.json hooks and "Phantom Gyp" binding.gyp execution, disable script execution during package installation. Run installs with the --ignore-scripts flag:

npm install --ignore-scripts

To make this the default behavior across your development machine, add it to your global configuration:

npm config set ignore-scripts true

If a specific dependency strictly requires native compilation, you can selectively run scripts for that package using npm rebuild <package-name> after auditing its source code.

4. Secure the IDE and AI Workspace

To defend against workspace-execution vectors like those seen in the Verana Go module compromise, disable automatic task execution in your IDE. In VS Code, ensure that Workspace Trust is enabled and that untrusted folders are opened in restricted mode, which prevents automatic configuration loading and extension execution.

Cryptographic signatures and passwordless publishing are valuable tools, but they are not a substitute for runtime isolation. If you do not control what your build runners can execute and where they can talk on the internet, you are one compromised credential away from signing your own malware.