AI coding agent supply chain attacks are no longer hypothetical: on February 28, 2026, a commit co-authored by Claude Opus added a North Korean bait package to an open-source trading bot. The package itself was clean. Its dependency stole .env files, wallet keys and API secrets, and added the attacker’s SSH key to the machine.
That is one of three campaigns this year that changed how I think about letting an agent run npm install. One wrote itself into Claude Code’s own settings file. Another ran a malicious install script for fourteen months without a single advisory, and The Hacker News covered it on October 7.
This post covers how these attacks reach your agent, and the specific settings in Claude Code, npm and pnpm that close each path.
What Are AI Coding Agent Supply Chain Attacks?
An AI coding agent supply chain attack targets the package choices and config files of an agent, rather than the human developer. The agent picks a dependency, runs the install and moves on, often without a person reading the package page.
Three campaigns and one technique define the risk right now:
| Campaign | How it reaches the agent | Scale reported |
|---|---|---|
| PromptMink (Famous Chollima) | Bait packages with docs written to win an LLM’s package choice | 60+ packages, 300+ versions |
| Slopsquatting | Registering names that models hallucinate | 205,474 unique fake names in one study |
| Mini Shai-Hulud (TeamPCP) | Compromised packages that plant hooks in .claude/settings.json | 170+ packages, 518M+ downloads |
| MALFEX | A postinstall script in a package with no advisory | 40,767 downloads |
(Sources: Cloud Security Alliance research notes, May 2026; Spracklen et al., USENIX Security 2025; CloudSEK and The Hacker News, Sep–Oct 2026.)
MALFEX is not an agent-specific attack. I include it because an agent that installs packages automatically is exactly the kind of user it was built to catch.
The common thread is that an agent trusts what a package says about itself more than a cautious human would.
How PromptMink Turned Package Docs Into a Lure
ReversingLabs named the PromptMink technique “LLM Optimization abuse”. According to the Cloud Security Alliance’s PromptMink note, the attackers published packages with detailed documentation, usage examples, API references and badges designed to score well when an AI agent evaluates candidates.
The structure had two layers. @solana-launchpad/sdk contained no malicious code and worked as advertised. It depended on @validate-sdk/v2, which scanned the project for .env and .json files and exfiltrated what it found. Later versions zipped and exfiltrated whole source directories.
The detail that bothered me most is the commit trail. The CSA note says the openpaw-graveyard project added the bait SDK in a commit co-authored by Claude Opus, which means an agent chose the dependency, either at a developer’s request or on its own in CI. CSO Online’s coverage adds that in January 2026, an AI agent on Moltbook posted that it used the same package. That post may have been planted by the attackers to build credibility.
The payloads also got harder to spot over time. The CSA note tracks a shift from obfuscated JavaScript to an 85 MB Node.js single executable in February, then a 5 KB precompiled Rust add-on in March.
Human reviewers check publisher history, download counts and how long a package has existed. An agent weighs docs quality and type coverage. PromptMink was built for the second kind of reviewer, and the bait package passed.
Slopsquatting: When Hallucinated Packages Become Real
Slopsquatting needs no social engineering at all. The attacker waits for a model to invent a package name, then registers it.
The scale of the opening is measured. The USENIX Security 2025 paper by Spracklen and colleagues generated 576,000 code samples from 16 code models and found 205,474 unique package names that did not exist.
- Open-source models 21.7%
- Commercial models 5.2%
Source: Spracklen et al., We Have a Package for You! (USENIX Security 2025)
That paper tested 2024-era models. Today’s frontier models are better, but 5% of a long dependency list is still a lot of guesses.
The 2026 case that turned this into a real incident started with agent skills. CSO Online reports that framework migration skills created in October 2025 called a hallucinated package, react-codeshift, through npx. The name spread to 237 GitHub repositories and generated real download attempts.
Aikido Security researcher Charlie Eriksen registered the name first, so nothing malicious ran. If an attacker had found it before him, every one of those repositories would have run attacker code the next time a skill fired.
This is the risk I think gets underrated in agent skills and shared prompts. A hallucinated name in a skill does not fail once. It fails every time anyone copies that skill.
Slopsquatting turns a model’s mistake into a shared, repeatable install command, and skills copy that mistake across hundreds of repositories.
Mini Shai-Hulud Wrote Itself Into Claude Code’s Settings
The third campaign went after the agent’s own configuration. The Cloud Security Alliance’s Mini Shai-Hulud research note says the TeamPCP worm, disclosed May 12, 2026, compromised more than 170 npm and PyPI packages with over 518 million cumulative downloads. TanStack, Mistral AI, UiPath and Guardrails AI packages were among them.
Its persistence trick is the part every Claude Code user should know. The worm added a SessionStart hook to .claude/settings.json that ran node .vscode/setup.mjs at the start of every Claude Code session. It added a matching folderOpen task to .vscode/tasks.json for VS Code.
The CSA calls this the first documented supply chain attack to use AI coding agent config files for persistence. Both survive removing the bad package and rotating credentials. The note also warns that a “dead-man’s switch” ran rm -rf ~/ if a victim revoked the attacker’s npm token, so the persistence had to be cleaned up before any credential rotation.
There is a second reason this works: .claude/ and .vscode/ are often in .gitignore, so a modified hook never appears in a pull request diff. I covered a related class of config abuse in the GitSpawn and Plugin4Shell breakdown, where a repository’s git config ran code before any approval prompt.
Any file that runs code when your agent starts is part of your supply chain, and Mini Shai-Hulud proved attackers know it.
How to Defend AI Coding Agents From Supply Chain Attacks
No single setting stops all four campaigns. Here is what each control covers.
| Control | PromptMink | Slopsquatting | Mini Shai-Hulud | MALFEX |
|---|---|---|---|---|
| Ask before installs | Yes | Yes | Partial | Yes |
| 24-hour release-age gate | Partial | Partial | Yes | No |
| Disable install scripts | Partial | Partial | Partial | Yes |
| Review agent config files | No | No | Yes | No |
(Source: my mapping of each control against the campaign mechanics described by CSA, CSO Online and CloudSEK.)
1. Make Claude Code ask before every install
Claude Code’s permission rules are evaluated deny first, then ask, then allow, and a matching ask rule prompts even when a broader allow rule also matches. Put package installs in ask:
{
"permissions": {
"ask": [
"Bash(npm install *)",
"Bash(npm i *)",
"Bash(pnpm add *)",
"Bash(yarn add *)",
"Bash(npx *)",
"Bash(pip install *)"
]
}
}The docs say deny and ask rules apply when any subcommand matches, including inside && chains and subshells. They also say plainly that a Bash rule is not a security boundary around a program, because the same program can be invoked in a different form. Treat this as a speed bump that puts a human in front of the package name, not as a wall.
2. Add a release-age gate
The pnpm docs say minimumReleaseAge has defaulted to 1,440 minutes, or 24 hours, since pnpm 11. Before that it was 0. pnpm 11 also defaults blockExoticSubdeps to true, so transitive dependencies cannot pull from git repos or tarball URLs.
On npm, the npm config docs list min-release-age, measured in days, with no default. Add min-release-age=1 to your project .npmrc. Watch the units: pnpm counts minutes and npm counts days.
A day’s delay catches worms like Mini Shai-Hulud, which publish infected releases fast and get pulled within hours. It does nothing against MALFEX, whose function-flag package had been malicious since July 18, 2025, per CloudSEK’s write-up.
3. Turn off install scripts by default
MALFEX lived in a postinstall hook. The Hacker News reports that function-flag alone had 37,419 downloads, and CloudSEK says no advisory covered it. A scanner that relies on advisories would have flagged nothing.
npm’s ignore-scripts=true stops lifecycle scripts from running. It will break packages that genuinely need a build step, so pnpm’s allowBuilds and strictDepBuilds settings are the better route if you can switch: allowlist the handful of dependencies that need scripts and block the rest.
4. Watch the files that run on agent startup
Check .claude/settings.json, .mcp.json, .vscode/tasks.json and .cursor/ for hooks and servers you did not add. The PromptMink note also describes a later component, McpInject, that registered a malicious MCP server in AI coding tool configs. If you rely on MCP, my guide to the MCP servers worth configuring covers how project-scoped servers live in .mcp.json, which makes that file worth a code owner.
Claude Code mods add another layer here. As I noted in the Claude Code mods guide, mods run with your permissions and are not sandboxed, so a planted mod has the same reach as a planted hook.
5. Keep cheap subagents on the same rules
If you move Explore and other subagents to a cheaper model, as I suggested in today’s Claude Haiku 5.5 analysis, those subagents follow the same permission rules. Do not give a fast, cheap subagent broader install rights than your main session.
The defence that covers the most ground is the boring one: a human reads every new package name before it installs, and CI flags every new transitive dependency.
What This Means for Teams Shipping With Agents
The CSA’s PromptMink recommendations say to use one package vetting workflow whether a human or an AI added the dependency. I agree, and I would go further: assume the agent is the weaker reviewer. It is fast and tireless, and it is also the reviewer these campaigns were designed to fool.
For vibe coders shipping without a security team, the gap is bigger. The vibe coding in production analysis found AI-co-authored pull requests already carry about 1.7x more issues, and that is before counting what comes in through dependencies. The vibe coding security risks post covers the app-level failures. Supply chain failures sit underneath those, and you cannot see them in your own code at all.
My minimum setup for any repo where an agent can run shell commands is short. Put installs in the ask list, use a 24-hour release-age gate, allowlist build scripts, and give .claude/ and .mcp.json a code owner. None of it takes more than an hour, and each item maps to a campaign that already happened this year.
AI coding agents did not create supply chain attacks, but they made the install step faster and less watched, and 2026’s attackers have adapted to that.
