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, the malicious versions installed code outside the package directory itself, writing into the local AI assistant and editor configuration files - the same files that auto-execute on every editor launch.

Snyk's parallel analysis and cleanup guide for the Miasma packages documents the same persistence mechanism, names the specific files involved, and gives a recommended cleanup order. The key insight in both reports is that npm uninstall does not remove anything outside the package directory. The editor-level persistence quietly survives the cleanup most developers reach for first.

How the Persistence Mechanism Works

According to the Microsoft and Snyk write-ups, the dropper does two things during install. First, it runs a normal credential exfiltration routine, reading common credential locations (cloud SDK config directories, SSH private keys, npm tokens, and so on) and posting them to an attacker-controlled endpoint. Second, and the part most existing supply chain detectors miss, it writes execution hooks into local editor configuration so the attacker keeps reentry even if the package itself is removed.

// ❌ What the malicious install hook does (simplified, paraphrased from public reports)
//   - reads common credential files from the user home directory
//   - writes a startup hook into ~/.claude/settings.json
//   - writes a build/run task into .vscode/tasks.json
//   - both files re-execute the payload every time the editor opens
//   - removing the npm package does NOT touch either file

Microsoft's report calls out that the dropper checks for known endpoint protection processes (CrowdStrike and SentinelOne are both named in the public write-ups) before continuing, which is why some compromised machines show no obvious sign of activity. Snyk's cleanup checklist lists the specific files to audit and the indicators to look for line-by-line. 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 built into the dropper: if the stolen credentials are rotated before the persistence is removed, the code is designed to overwrite or destroy files in the user's home directory. 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: identify the infected machine, remove the editor-level persistence first, then remove the npm package, then rotate credentials. Reversing that order is what trips 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 a few days after the first one was reported contained. Their analysis of the binding-gyp variant (publicly nicknamed Phantom Gyp) 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.

Tenable's "mini Shai-Hulud" FAQ attributes both waves to the same operator (publicly tracked as TeamPCP), discusses victim scope, and explains why the propagation pattern resembles the older Shai-Hulud worm at a smaller scale. For weekly download counts, affected package lists, and ongoing IOC updates, cross-reference all three reports directly - the public lists are evolving as new poisoned versions are discovered.

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 for hook or startup entries that you did not add yourself. The Microsoft and Snyk reports describe the specific keys the campaign writes.
2. Inspect .vscode/tasks.json in every project for build, runOptions, or run-on-open tasks pointing at scripts you did not create. Drop locations are documented in the Snyk write-up.
3. Cross-check installed dependencies against the IOC lists published by Microsoft and StepSecurity. Both posts are being updated as new poisoned versions are catalogued.
4. Do not rotate credentials yet. Microsoft documents the wipe-on-revoke behaviour - 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 postinstall actually does before running it. 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 - check publish date, weekly download count, and maintainer history 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
// 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. Tools like VibeDoctor (vibedoctor.io) automatically verify every import against the live registry, surface hallucinated or suspicious packages, and flag the dependency patterns AI tools repeatedly get wrong. Free to sign up.

FAQ