2026-07-22 · 5 min read

Slopsquatting: the supply chain attack your code review should catch

Earlier this year security researcher Charlie Eriksen found an npm package named react-codeshift referenced across 237 repositories. The package had never existed. An AI assistant invented the name, other AIs kept repeating it, and forks spread it like seed. The researcher registered the name himself before someone less friendly could. That race, between whoever notices the hallucination and whoever weaponizes it, now has a name: slopsquatting.

What's been happening

The mechanics are almost embarrassingly simple. Language models autocomplete package names from patterns, not from the registry. Ask for a React codemod helper and you may get an import that blends jscodeshift and react-codemod into something that feels more right than either. The name is fabricated, but it's fabricated consistently: research on the topic keeps finding that models repeat the same invented names across sessions and users. A repeatable hallucination is a predictable install, and a predictable install is an attack surface. Whoever publishes that name first owns every machine that resolves it.

This stopped being theoretical a while ago. Besides react-codeshift, there's the documented case of unused-imports, a malicious npm package sitting on a name models habitually produce instead of the legitimate eslint-plugin-unused-imports, and it was still collecting hundreds of downloads a week after being flagged (CSA has a good research note on the pattern). This month the topic escalated again: researchers described chaining a hallucinated resource with prompt injection so that an AI coding agent fetching it can be hijacked outright, and the attack surface got mainstream business-press attention. The window between "the model made it up" and "someone owns it" is closing fast.

Diagram of a slopsquatting attack in three steps: an AI model hallucinates a package name, an attacker registers that name on the registry, and the install pulls attacker-controlled code into CI and production.

Where the defenses actually sit

Registry scanning helps. Lockfile discipline helps. Tooling that cross-checks dependencies against known-good lists helps. But look at where the bad line actually enters your codebase: through a pull request. Somebody, increasingly an AI agent, opens a diff that adds a dependency and an import, and somebody approves it. Between the hallucination and your CI secrets there is exactly one human checkpoint.

Companies have started acting like they understand this. After its string of AI-assisted incidents this spring, Amazon's response was notably low-tech: mandatory review by two people for changes to critical systems. Not a smarter scanner. More human review. Meanwhile Salt Security's June survey found 38% of organizations still rely primarily on manual review to catch problems in AI-generated code. Whether that number scares you or reassures you, it means the same thing: the reviewer's eye is load-bearing infrastructure now.

Would you have caught it?

Here's roughly what the react-codeshift case looks like as a PR. An agent was asked to add a class-to-hooks migration script. Read it like you'd review it at work:

ai-agent wants to merge · package.json, tools/migrate.js +6

12 "react": "^18.3.0",

13+ "react-codeshift": "^2.4.1",

14 "react-dom": "^18.3.0",

1+ import { transform, hooksPreset } from 'react-codeshift';

3+ export function migrateFile(source) {

4+ return transform(source, hooksPreset);

5+ }

What a trained eye flags here

The dependency itself. react-codeshift reads like it must exist: jscodeshift is real, react-codemod is real, and this name feels like their obvious child. That's exactly the signature of a hallucinated package: plausible by association, absent from the registry. A version pin like ^2.4.1 proves nothing; the model invents version numbers with the same confidence. The check costs thirty seconds: open the registry page, look at the publisher, the download history, the repo link. A package that appeared last week with one version and no repository behind a name your assistant "remembered" is a request-changes, whatever the rest of the diff looks like.

The uncomfortable part: in a real review queue this line doesn't glow. It sits in the quiet part of the diff, the dependency block nobody reads, between two packages that are completely legitimate. Every bug an AI writes wears that same calm face. The instinct that catches it, pausing on every load-bearing name you don't personally recognize, is not a tool you can install. It's a reflex.

Reflexes come from reps

You can build that reflex the same way you'd build any reviewing muscle: reps with feedback. Hallucinated APIs and dependencies are one of the core categories on DiffDojo, precisely because they're the failure mode where reading well is the whole game. You review a realistic AI-written PR, call out what's broken, give a verdict, and get graded against a canonical review, including the days when everything is fine and the discipline is to approve. Today's PR is free, no signup.

Whatever you use, the takeaway from the last few months of slopsquatting news is worth taping to the monitor: if a dependency is new and you don't personally know it exists, check before you approve. Thirty seconds against a supply chain incident is the best trade in this industry.

Think you'd have flagged react-codeshift? There's a fresh AI-written PR waiting, and its bug is a different one.

Review today's PR, free