The self-spreading npm worm tracked as Miasma — the one that compromised 32 packages in the @redhat-cloud-services namespace on 1 June — returned on 3 June with a delivery change that bypasses the install-script checks many teams had just leaned on. StepSecurity tracked the new wave as "Phantom Gyp"; Semgrep published a 4 June analysis showing that the malware no longer relies on preinstall or postinstall lifecycle scripts. Instead it ships a roughly 157-byte binding.gyp file whose command-substitution syntax causes code to execute during npm install via node-gyp, without the package declaring an install script. Researcher counts are still point-in-time, but Semgrep and StepSecurity both put this wave at 57 packages across 286+ malicious versions.

The vector: execution without a declared script

The point of the change is evasion. After the wave-1 Red Hat compromise, the standard advice — and the default in much supply-chain tooling — was to monitor or disable npm lifecycle scripts, since that is how install-time worms normally fire. binding.gyp is a legitimate build-configuration file for native Node modules, processed by node-gyp during installation. By smuggling a command substitution into it, the attacker gets arbitrary code execution at install time through a path that is not a lifecycle script and that many install-script checks do not inspect. As StepSecurity's Sai Likhith put it, the technique bypasses "most install-script security checks entirely."

The payload behaviour is otherwise familiar. Semgrep reports it downloads the Bun JavaScript runtime to run a heavily obfuscated credential harvester that sweeps AWS, GCP and Azure credentials, GitHub Actions secrets — including direct extraction from runner process memory via /proc/*/mem — and 1Password, gopass and pass credential stores. Semgrep says the worm can forge provenance attestations so reinfected packages appear legitimate, and exfiltrates stolen data to attacker-controlled GitHub repositories. Microsoft's analysis of the broader campaign, reported by The Hacker News, describes the same pattern: scraping GitHub Actions runner memory for secrets and republishing poisoned packages with forged SLSA provenance to keep the worm moving downstream.

What changed: AI-assistant persistence

The capability that stands out in this wave is its targeting of AI coding tools. Semgrep found that the worm injects persistent backdoor files into project AI-assistant configuration directories, including paths under .claude/, .cursor/, .gemini/, .vscode/ and .github/. That changes the cleanup problem: a dependency rollback may remove the poisoned package version, but it may not remove configuration files left inside the repository. If those files are later loaded by an AI-enabled editor or coding assistant, they can reintroduce malicious instructions or influence AI-assisted coding output through the poisoned project configuration. Endor Labs, cited by The Hacker News, said the malware injects "persistent backdoor files" that run when a developer opens the project in an AI-assisted IDE.

Researchers also documented a more resilient command channel. According to StepSecurity and OX Security (via The Hacker News), the worm searches public GitHub commits for a keyword to retrieve fresh payloads, letting the operator update the malware after infection. OX's researchers characterised this as an adaptive command-and-control that "piggybacks on a trusted, widely whitelisted platform" — GitHub traffic that most network defences are not configured to treat as suspicious. Tallies for the campaign are still moving as analysis continues: Sonatype reported a higher component count by 5 June, while Semgrep and StepSecurity put the package figure at 57.

Red Hat's root cause: a compromised account, investigation ongoing

On the original 1 June incident, Red Hat has narrowed the likely cause. Its advisory RHSB-2026-006, updated 3 June, states that preliminary analysis indicates a compromised GitHub account was used to push unauthorised commits to repositories in the RedHatInsights GitHub organisation. Red Hat says the affected packages are frontend libraries used in the Hybrid Cloud Console, that no console release was published during the compromise window, and that its publication process strips installation-time scripts before deployment — and that, based on current findings, no customer action is required. The company notes the investigation is ongoing, so that root-cause finding is preliminary rather than final.

Separately, researchers flagged a distinct campaign running the same week. JFrog, reported by The Hacker News, detailed a Rust-based stealer it codenamed IronWorm, spread through a compromised npm account and using an eBPF kernel rootkit and a Tor channel; its commits were authored under the name "claude" to mimic Anthropic's AI assistant, and it targets credential files for several AI coding tools alongside cloud and container secrets. Attribution across these npm attacks remains unclear: Miasma is assessed as a derivative of the public Shai-Hulud worm code, which means more than one actor could be running variants.

What to do now

For teams that ran npm install against any affected version, the remediation is the same playbook as wave 1, plus AI-tool hygiene. Rotate every credential reachable from the affected machine or pipeline — cloud keys, GitHub tokens, npm tokens, SSH keys — and treat CI/CD secrets as exposed. Disable install scripts and native rebuild paths by default where your build allows it, then allowlist the packages that genuinely need native builds, and pin dependencies with integrity hashes. Critically, because monitoring lifecycle scripts alone does not catch this vector, inspect for the worm's artifacts directly: a root-level binding.gyp paired with a large obfuscated index.js, a downloaded Bun binary under /tmp, and backdoor files in the AI-assistant directories listed above. Check those AI-config paths explicitly — a dependency rollback that ignores them can leave the persistence in place.

Key Takeaways

  • The Miasma npm worm returned on 3 June, two days after the Red Hat compromise, using a malicious ~157-byte binding.gyp file ("Phantom Gyp") to execute code during npm install without any lifecycle script — bypassing the preinstall/postinstall monitoring teams had just leaned on.

  • The wave hit 57 packages across 286+ malicious versions; the payload harvests cloud, CI/CD and password-manager credentials and forges provenance to self-propagate.

  • New and notable: it plants persistent backdoors in AI coding-assistant config directories (.claude/, .cursor/, .gemini/, .vscode/, .github/) that re-trigger when a developer opens the project in an AI-assisted IDE.

  • Red Hat's advisory (RHSB-2026-006) attributes the 1 June incident, preliminarily, to a compromised GitHub account; the investigation is ongoing and Red Hat says no customer action is required.

  • Remediation: rotate all reachable credentials, disable install scripts and native rebuilds by default, pin with integrity hashes, and inspect for the worm's artifacts directly — including the AI-assistant backdoor files, which a normal dependency rollback can miss.