Claude Code Settings as an Attack Surface: The June 2026 npm Persistence Campaign

Why This Campaign Is Different From Earlier npm Attacks

For most of the last decade, npm supply chain attacks followed a familiar shape. An attacker compromised or impersonated a package, planted a postinstall script that read environment variables, and disappeared once the bad version was pulled. Detection and cleanup followed a familiar pattern as well: audit your package-lock.json, remove the offending version, rotate any credentials that lived in .env, move on.

The campaign documented in Microsoft Threat Intelligence's June 2026 write-up on the Miasma campaign against @redhat-cloud-services packages changes that shape. According to Microsoft, 32 packages across more than 90 versions ran an npm preinstall hook that launched a 4.29 MB obfuscated dropper, and the packages were published through the project's legitimate GitHub Actions workflow, so they carried valid provenance. StepSecurity's report on the next wave (below) adds the part that changes the cleanup: the malware writes into AI assistant and editor configuration files that run on their own when you open the project.

Snyk's parallel analysis and cleanup guide for the Miasma packages tells you to audit editor and agent config, such as .claude/settings.json and .vscode/tasks.json, and clean any attacker-planted hooks before touching credentials. npm uninstall only removes what npm installed for the package, so hooks written into other files quietly survive the cleanup most developers reach for first.

How the Persistence Mechanism Works

According to the Microsoft and StepSecurity write-ups, the malware does two things. First, it steals credentials: Microsoft lists GitHub and npm tokens, cloud credentials, SSH keys, package-manager and docker configs and Anthropic API keys, uploaded to GitHub repositories the malware creates on the fly. Second, and the part most existing supply chain detectors miss, StepSecurity found it writing backdoor files into project repositories so the attacker keeps reentry even if the package itself is removed.

// ❌ What the malicious install does (simplified, paraphrased from public reports)
//   - reads credentials from the machine and CI environment
//   - drops .claude/setup.mjs and edits .claude/settings.json so it runs on every Claude Code session start
//   - writes a task with runOn: folderOpen into .vscode/tasks.json
//   - also drops .cursor/rules/setup.mdc and .gemini/settings.json
//   - removing the npm package does NOT touch any of these files

Microsoft's report says the malware attempts to neutralize security controls, including an /etc/hosts change aimed at security-product monitoring, and StepSecurity found EDR detection logic in the decoded payload. Snyk's cleanup checklist names the files to audit. If you suspect you ran an affected version, treat the Snyk article as your reference document, not this post.

The Wipe-On-Revoke Trap: Why Order of Operations Matters

One detail in Microsoft's write-up is worth flagging before any cleanup. Microsoft describes a defensive booby-trap: the malware plants a decoy token named IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner, and revoking it can start a wiper that deletes the user's home directory. Tenable describes the same idea in the parent worm, a daemon that polls GitHub and deletes files once it sees its token revoked. The intent appears to be raising the cost of an aggressive response, so victims hesitate before rotating tokens.

This changes the right cleanup order. The Snyk write-up gives the sequence in detail and it boils down to: stop installing the bad versions and reinstall with scripts disabled, clean the attacker-planted hooks, and only then rotate credentials. In Snyk's words, clean the host before you start revoking the tokens it is watching. Rotating first is what risks the wipe.

If you suspect exposure, do not improvise. Use the published cleanup steps in the Snyk article and the indicators of compromise in the Microsoft post as your reference.

Two Waves: Miasma and Phantom Gyp

StepSecurity documented a second wave on 3 June 2026, two days after the first. Their analysis of the binding.gyp variant (which StepSecurity named Phantom Gyp) covers 57 packages and more than 286 malicious versions. The packages declare no install scripts at all: a small binding.gyp file makes npm run node-gyp rebuild on install, and that build runs the payload. The report also describes a wormable propagation mechanic: once a developer machine is compromised, the malware uses any npm publish tokens it finds to push poisoned versions of other packages that developer maintains. Each successful publish becomes a new entry point for the next wave.

Snyk describes the Miasma payload as a lightly reskinned descendant of the Mini Shai-Hulud worm that TeamPCP open-sourced earlier in the year. Tenable's "mini Shai-Hulud" FAQ, published on 21 May 2026 before these waves, covers that worm: TeamPCP published its source code on 12 May 2026, and Tenable's remediation steps already tell you to remove injected tasks in .vscode/tasks.json and Claude Code hooks in ~/.claude/settings.json before rotating credentials. For affected package lists and IOC updates, cross-reference the reports directly - new poisoned versions keep turning up.

How to Check Your Machine

The cleanest single reference is the Snyk article linked above; treat the bullets below as a fast triage that points you at the parts that need attention, not as incident response on their own.

1. Inspect .claude/settings.json in every project, and ~/.claude/settings.json, for hook or startup entries that you did not add yourself, such as a SessionStart hook running .claude/setup.mjs. StepSecurity names the project-level files; Tenable names the user-level file for the parent worm. Check .cursor/rules/setup.mdc and .gemini/settings.json too.
2. Inspect .vscode/tasks.json in every project for tasks with runOn: folderOpen or other tasks pointing at scripts you did not create. StepSecurity documents the drop locations.
3. Cross-check installed dependencies against the package tables and IOC lists published by Microsoft and StepSecurity, and check both posts for updates.
4. Do not rotate credentials yet. Microsoft documents a decoy token whose revocation can trigger a wiper - clean persistence first, then rotate.
5. Audit your npm tokens. StepSecurity's Phantom Gyp analysis shows the worm uses stolen publish tokens to spread, so any token that lived on the infected machine should be considered compromised once persistence is fully removed.

How to Reduce Your Exposure Going Forward

The structural lesson from this campaign is that "install first, scan later" is the wrong default for any project that uses AI-assisted coding tools. AI assistants frequently suggest packages that are new, niche, or fabricated outright, and that habit dovetails neatly with squatted and freshly-published malicious packages. The right default is "verify first, install second."

A few concrete habits help. Install new packages with --ignore-scripts first and review what each one's install scripts actually do before running them. The flag also stops the automatic node-gyp rebuild that a binding.gyp file triggers, which is how Phantom Gyp ran. Pin exact versions in package.json rather than using caret or tilde ranges. Keep your package-lock.json committed and treat lockfile changes as a code review concern. Run npm info <package> on every new dependency a generator suggests to check the publish date, versions and maintainers, and look up weekly downloads on its npmjs.com page, before letting it touch your machine.

# ✅ Verify before you install
npm info @redhat-cloud-services/some-package    # confirm publisher, publish dates, latest version
npm install --ignore-scripts @redhat-cloud-services/some-package
# inspect node_modules/@redhat-cloud-services/some-package/package.json - read the scripts block,
# and look for a binding.gyp file
# only then re-run with scripts enabled, if at all

For projects already built with Bolt, Lovable, Cursor, v0, or Replit, the highest-leverage check is making sure every imported package actually exists in the npm registry, is the package the AI assistant thought it was, and is not freshly-registered with no download history. VibeDoctor's Vibe Check looks up every dependency in your manifests on the live registry and flags names that do not exist, packages created in the last 30 days with fewer than 100 downloads, likely typosquats and deprecated packages. It also flags imports of package names AI tools are known to invent. It does not inspect your editor config files, so the checks above still apply. Free to sign up.

FAQ