A stolen session cookie sat in underground markets for seven weeks before attackers used it to poison 32 Red Hat packages in the npm software registry, an example of the industrial approach behind modern supply chain attacks.

Background on the Miasma worm and npm supply chain attack

On June 1, the Miasma self-propagating worm compromised 32 official npm packages under the @redhat-cloud-services namespace, delivering a credential-harvesting payload to an estimated 80,000 to 117,000 weekly downloads. Within five days, the campaign escalated through three distinct attack waves and forced GitHub to disable 73 repositories across four Microsoft organizations.

The technical details of the Miasma supply-chain attack are alarming: valid Supply Chain Levels for Software Artifacts (SLSA) provenance attestations on malicious packages; a novel execution technique that bypasses install-script monitoring; and a new persistence mechanism that targets AI coding assistants. But the most important detail is a timestamp.

Dark web monitoring firm Whiteintel detected a Red Hat employee’s GitHub credential and session cookie in infostealer logs on April 13. A second sighting appeared on May 15. The credential sat in underground markets for approximately seven weeks before attackers weaponized it on June 1. That seven-week gap is the signature of an emerging threat model that Tenable’s Research Special Operations (RSO) team calls the Developer Credential Economy, and has been tracking since March 2026.

The Developer Credential Economy is a structured black market for highly privileged developer credentials where open-source supply chain compromises function as credential generation infrastructure, underground markets serve as the distribution layer, and multiple threat actors with distinct motivations weaponize the harvested access downstream. The Miasma campaign is the clearest example of this model to date, and it validates a pattern that has been accelerating across the npm, PyPI, and GitHub ecosystems throughout 2026.

The three-layer economy, explained through Miasma

When it first assessed this pattern in March, Tenable RSO built the analysis around the TeamPCP cascading campaign (Trivy, KICS, LiteLLM, Telnyx, and 66+ npm packages) and the Sapphire Sleet/UNC1069 Axios compromise. The thesis identified a three-layer structure: credential generation, distribution, and weaponization. Three months later, the Miasma campaign validates each layer with striking clarity.

Layer 1: Credential generation

The Developer Credential Economy’s first layer is extraction. Threat actors compromise developer tooling and open-source infrastructure not primarily to distribute malware to end users, but to harvest the credentials those environments contain, such as GitHub tokens, npm publishing tokens, cloud provider credentials, CI/CD secrets, SSH keys, and API keys.

TeamPCP pioneered this at scale beginning in September 2025 with the original Shai-Hulud worm. Its defining innovation was cascading credential extraction: compromise one trusted tool, harvest the credentials it holds, and use those credentials to compromise the next tool in the dependency chain. 

The Trivy vulnerability scanner compromise yielded CI/CD runner secrets. Those secrets enabled the KICS compromise. KICS yielded additional cloud credentials. Each link in the chain generated a broader set of privileged access.

By May, TeamPCP had refined this into the Mini Shai-Hulud variant, which introduced two capabilities that made the generation layer dramatically more efficient: 

1. Wormable propagation: The malware queries the npm registry for every package the compromised identity can publish, and republishes itself across all of them automatically.
    
2. CI/CD pipeline hijack via OpenID Connect (OIDC) token extraction: Rather than stealing static credentials, Mini Shai-Hulud requests short-lived OIDC tokens through GitHub Actions, enabling it to publish packages with valid cryptographic provenance.

In the Miasma supply chain campaign, this generation layer operated through a Red Hat employee’s compromised GitHub account. The worm’s payload swept the infected environment for: 

• GitHub tokens and personal access tokens
• npm publishing tokens
• AWS, GCP, and Azure cloud credentials
• HashiCorp Vault tokens
• Kubernetes service account tokens
• SSH private keys
• Docker registry credentials
• GPG keys
• .env files 

The June variant added dedicated collectors for GCP and Azure cloud identities, going beyond secret extraction to enumerate all cloud access the infected machine holds.

Every machine that ran npm install against a compromised @redhat-cloud-services package version became a credential generation node.

Layer 2: Distribution

The second layer is the marketplace. Stolen credentials flow from the generation layer into underground markets, infostealer log aggregators, and access brokering services, where they become available to any buyer.

The Miasma supply chain-attack timeline makes this layer visible in a way previous campaigns did not. Whiteintel detected the Red Hat employee’s GitHub credential and session cookie in infostealer logs on April 13. That credential was not generated by a targeted supply chain attack against Red Hat; a commodity infostealer harvested it, one of 13.2 million infostealer infections that SpyCloud's 2025 Identity Exposure Report documented as producing an average of 50 credentials per infection. The credential entered the distribution layer as one data point among billions: SpyCloud recaptured 5.3 billion credential pairs, 18.1 million exposed API keys and tokens, and 8.6 billion stolen session cookies from criminal underground monitoring in 2025 alone.

For seven weeks, the credential sat in the distribution layer before someone acted on it. That dwell time is the systemic gap that the Developer Credential Economy exploits. Organizations that do not monitor underground markets for exposed developer credentials are operating on the assumption that the generation-to-weaponization pipeline does not exist, or that it operates too slowly to matter. Miasma demonstrates that even a seven-week window, which is long by underground market standards, is more than sufficient for weaponization.

The distribution layer was further amplified on May 12, when TeamPCP published the complete Mini Shai-Hulud source code on GitHub under an MIT License with the message “Shai-Hulud: Open Sourcing The Carnage.” The release included CI cache-poisoning scripts, the OIDC token extractor, and the credential stealer with its propagation logic. This is the supply chain equivalent of publishing a working exploit framework: the tooling itself became a distribution channel, lowering the barrier to entry for any operator who wants to run a structurally identical campaign.

Layer 3: Weaponization

The third layer is operational use. Actors with distinct motivations acquire credentials from the distribution layer and weaponize them against specific targets.

In March, the RSO team documented at least three distinct actors operating from the same credential pool: TeamPCP harvested at scale: Sapphire Sleet/UNC1069 (DPRK-nexus) operationalized stolen npm tokens for financial gain through the Axios compromise and LAPSUS$ exploited compromised Tailscale VPN credentials from the LiteLLM breach for data theft from Mercor AI. The same credential ecosystem fed all three.

Miasma’s weaponization layer continues to evolve, but the trajectory across its three waves demonstrates the pattern:

• Wave 1 (June 1) used the stolen Red Hat credentials to compromise 32 @redhat-cloud-services packages, generating a fresh round of credentials from every developer environment that installed a compromised version.
   
• Wave 2 (June 3) pivoted to 57 additional packages using a novel technique researchers call “Phantom Gyp,” which abuses a 157-byte binding.gyp file to trigger code execution during npm install, bypassing the preinstall-script monitoring that defenders had deployed after earlier waves.
   
• Wave 3 (June 5) used a previously compromised contributor account, the same one from the May 19 PyPI attack, to push malicious commits to Microsoft’s Azure/durabletask repository, forcing GitHub to disable 73 repositories in a 105-second automated sweep.

Each wave fed the next: Credentials stolen in Wave 1 enabled access for Wave 2 targets, and the same compromised accounts persisted into Wave 3. The worm’s self-propagating behavior ensures that the credential pool grows with each successful infection, creating a compounding cycle where generation and weaponization overlap.

The escalation that should concern every security team

Three aspects of the Miasma campaign represent genuine escalations beyond what the security community had observed in prior supply chain attacks.

1. Provenance attestation is no longer sufficient

Miasma’s Wave 1 packages carried valid SLSA Build Level 3 provenance attestations, the highest tier of software supply chain integrity verification. Red Hat's legitimate CI/CD pipeline built the packages, using Red Hat’s trusted OpenID Connect (OIDC) identity, through GitHub Actions workflows that the attacker injected into the pipeline. The cryptographic certificate was accurate. The package really was built by that pipeline. The pipeline just happened to contain malware at the time.

This is not a bypass of provenance verification. It is a demonstration that provenance verification answers a different question than defenders assume. A signed attestation proves that a specific pipeline built a package. It does not prove the pipeline was clean. Organizations that rely on provenance verification as their primary supply chain control should treat Miasma as a structural limitation, not a one-off failure.

2. AI coding agents are now an attack surface

The Phantom Gyp wave (June 3) and the Azure wave (June 5) introduced a persistence mechanism not previously documented in supply chain campaigns: the malware drops configuration files into project directories for AI coding assistants, including .claude/settings.json for Claude Code, .cursor/rules for Cursor, and configuration files for Gemini CLI and VS Code. These are not trojanized extensions or compromised plugins. They are instruction-layer overrides that silently alter the behavior of the AI assistant the next time a developer opens the project.

If a developer opens an infected project in an AI-assisted IDE, the backdoor executes. The attacker’s hidden instructions can then influence AI-generated code, potentially introducing subtle vulnerabilities that are difficult to distinguish from legitimate suggestions. This represents a meaningful expansion of the attack surface from package registries and CI/CD pipelines to the developer’s local environment and AI-assisted workflow. The attack does not require npm install; it triggers when a developer opens a repository.

This is the first observed supply chain campaign systematically targeting the AI-assisted development workflow as a persistence and propagation surface. As AI coding assistants become standard tooling in enterprise development environments, this attack vector is likely to be replicated and refined.

3. Open-sourced tooling has created a copycat ecosystem

Mini Shai-Hulud is no longer limited to TeamPCP. The public release of the full weaponized toolchain on May 12, means any operator can replicate structurally identical campaigns against new target ecosystems. The Miasma payload is derived from the open-sourced code, with cosmetic modifications replacing Dune universe references with Greek mythology themes (“Miasma,” “spartan,” “nemean-hydra”). It’s unclear whether this is TeamPCP operating under a new brand or a separate actor who studied the published code and improved upon it. What is clear is the implication. The barrier to conducting npm supply chain attacks has been significantly and permanently lowered.

The evidence suggests that this proliferation is already occurring. Palo Alto Networks’ Unit 42 documented that copycat activity using the Shai-Hulud toolchain has complicated future attribution, and the Phantom Gyp wave’s evolution (binding.gyp execution, AI agent targeting, modified exfiltration channels) is consistent with either continued TeamPCP operation or a capable operator building on publicly available infrastructure.

Why EDR and reactive detection cannot solve this problem

The narrative around supply chain defense has leaned heavily on execution-layer detection: the idea that endpoint detection and response (EDR) tools will catch the payload when it fires, so organizations are protected. The Miasma campaign exposes why this assumption is structurally flawed.

EDR monitors execution, not exposure. Relying on EDR to stop a supply chain attack is like relying on a smoke detector while storing open canisters of gasoline in your kitchen. EDR cannot see the misconfigured GitHub Action, the over-privileged npm token, or the seven-week-old stolen credential sitting in an underground market. By the time an EDR agent fires on a malicious payload, the credential theft that enables the next wave has already occurred.

The coverage gap is where the theft happens. EDR has zero visibility into the ephemeral CI/CD runners and build environments where Miasma’s credential harvesting actually executes. These environments spin up, run the compromised npm install, exfiltrate secrets, and tear down, all before a human analyst could triage an alert. In the Developer Credential Economy, the theft happens where the agents are not.

Detection evasion is outpacing detection. After the TanStack compromise in May, defenders deployed preinstall-script monitoring as a detection control. The Phantom Gyp wave, arriving just three weeks later, bypassed that control entirely by shifting execution to binding.gyp, a file that most security tooling does not monitor. The Azure wave then abandoned package installation altogether, shifting to repository-level configuration files that trigger on IDE/editor open. Each defensive response creates a new evasion target, and the iteration cycle is measured in days, not months. EDR evasion is an active, industrialized capability, and supply chain attackers are demonstrating the same adaptive behavior.

While EDR has a role, it addresses the symptom (the malware payload at execution) rather than the disease (the unmanaged exposure of developer credentials and CI/CD infrastructure). Neutralizing the systemic risk created by the Developer Credential Economy requires a fundamentally different approach: identifying and eliminating the exposure conditions before an attacker can exploit them.

The ecosystem fights back, but the structural gap remains

The npm ecosystem has not been passive. npm executed a platform-wide token invalidation on May 19, forcing every maintainer to re-authenticate. npm CLI version 11.15.0 introduced staged publishing with human 2FA approval gates, requiring a deliberate human confirmation step before any package version goes live. GitHub disclosed that approximately 3,800 internal repositories had been exfiltrated during the Shai-Hulud campaigns. Isaac Schlueter, npm’s founder, called for mandatory disablement of non-MFA publishing.

While meaningful, these responses are structurally reactive: each one addresses the technique observed in the previous wave while the attacker has already moved to the next. Staged publishing addresses the OIDC token abuse from Wave 1. It does not address Phantom Gyp’s binding.gyp execution from Wave 2. Neither addresses the AI coding agent persistence from Wave 3.

The path forward requires moving from reactive detection to preemptive exposure management: identifying and closing the credential generation points before attackers can weaponize them.

A phased approach to disrupting the credential economy

The Developer Credential Economy operates on a simple principle: credentials that defenders do not know are exposed cannot be rotated, and therefore, remain vulnerable. A phased CTEM approach disrupts the attack chain at each layer.

Phase 1: Harden the generation layer

The first priority is eliminating the conditions that allow credential theft to occur. Organizations must audit lockfiles and kill lifecycle hooks (--ignore-scripts) immediately to eliminate the postinstall and preinstall vectors. But Miasma’s Phantom Gyp wave demonstrates that lifecycle hooks are no longer the only execution surface: add binding.gyp monitoring to package intake controls and audit all cloned repositories for AI coding agent persistence files (.claude/settings.json, .cursor/rules, .gemini/ configuration files).

Security tooling itself must be treated as critical infrastructure. The events of 2026 have proven this repeatedly: Trivy, Checkmarx KICS, and the Nx Console VS Code extension all functioned as high-value entry points precisely because developers trust them. Subject security tools to the same integrity verification and isolation controls applied to production systems.

Phase 2: Neutralize harvested secrets in real time

The seven-week credential dwell time in Miasma’s attack timeline is the exploitation window that the Developer Credential Economy depends on. Closing that window requires moving beyond periodic rotation to continuous visibility into where credentials are exposed, including in underground markets, CI/CD runners, and ephemeral build stages where EDR has no footprint.

Implement continuous dark web credential monitoring for developer accounts (GitHub, npm, PyPI, Docker Hub) with automated rotation on detection. Enforce mandatory MFA with reduced personal access token lifetimes. The Tenable Cloud and AI Security Risk Report 2026 found that 65% of cloud environments contain “ghost” credentials, dormant service accounts, and unrotated keys that provide ready-made pivot points for attackers. Every ghost credential is a free pass for an actor operating in the distribution layer. Use Tenable One to map the full attack surface, including the CI/CD pipelines and cloud-native build stages that execution-layer detection cannot reach.

Phase 3: Enforce human-gated publishing and break the automation chain

The worm’s self-propagation depends on fully automated publishing: steal a token, enumerate publishable packages, republish with malware, repeat. Inserting a mandatory human confirmation step breaks that automation chain.

The npm staged-publishing feature (npm CLI 11.15.0) represents a concrete implementation of this gate, requiring a human 2FA approval before any package version goes live. Organizations should: 

• Adopt staged publishing or equivalent human-gated workflows immediately
• Review GitHub Actions OIDC token scoping to ensure id-token: Write is limited to release workflows on protected branches only
• Implement minimumReleaseAge controls to quarantine new package versions before consumption
• Establish detection rules for Miasma indicators: GitHub repositories with the description “Miasma: The Spreading Blight;” the GCP user-agent string google-api-nodejs-client/7.0.0; and the dead-drop GitHub account liuende501
• Monitor for anomalous npm publish events and unauthorized GitHub repository creation in organizational accounts.

These are not optional hardening measures. They are direct responses to capabilities that have been demonstrated in the wild and that are now available as open-source tooling for any operator to deploy.

Where this goes from here

The Developer Credential Economy represents a significant maturation of cyber crime, moving beyond opportunistic attacks to establish a sophisticated, scalable, and highly specialized marketplace. The events of March through June have validated this assessment with striking clarity: TeamPCP’s open-sourcing of the Shai-Hulud worm; the proliferation of copycat variants like Miasma; the cross-ecosystem spread from npm to PyPI to GitHub Actions to VS Code extensions; and the introduction of AI coding agent targeting as a new persistence surface.

This evolution turns our own development tools against us to harvest the access needed for large-scale compromise. 

The path forward is a fundamental shift toward exposure intelligence that identifies and closes the credential generation points before attackers can weaponize them. The organizations that will weather this shift are those that treat developer environments as control-plane infrastructure, not workstations, and manage them with the continuous visibility and proactive hardening that a CTEM framework provides. 

Miasma’s seven-week credential trail is not a worst case. It is a baseline, and the next wave is already being assembled from the same open-sourced tooling.

Learn more

• Mini Shai-Hulud: Frequently asked questions about the TeamPCP supply chain campaign
• The developer credential economy: Why exposure data is the new front line in the supply chain war
• Crushing the Axios supply chain threat with Tenable Hexa AI: Use cases for agentic AI
• Frequently asked questions about the Axios npm supply chain attack by North Korea-nexus threat actor UNC1069
• Download pumping: New npm deception technique for supply chain attacks

Join Tenable’s Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One, the exposure management platform for the modern attack surface.