Slopsquatting: hallucinated packages are now attack vectors

Coding assistants invent package names. Attackers register those names. The developer runs npm install and the build succeeds, because the package exists now. This is slopsquatting, and the Mastra npm compromise of June 17, 2026 makes clear that the pattern has moved from proof-of-concept to active exploitation by nation-state actors.

The hallucination rates are not edge cases#

Lasso Security research tested 47,803 how-to prompts across four models and found that 24.2% of GPT-4 recommendations, 22.2% of GPT-3.5 recommendations, 64.5% of Gemini recommendations, and 29.1% of Cohere recommendations referenced packages that do not exist on real registries. These are not rare failures from adversarial inputs. They are baseline behavior on ordinary prompts.

The structural problem is repeatability. According to the dossier covering USENIX Security 2025 research, 43% of hallucinated package names appeared consistently across all ten runs of the same prompt, across 576,000 code samples from 16 models. Consistent names are registerable names. An attacker who runs the same prompts a developer runs will find the same hallucinated packages, every time.

What Mastra showed on June 17#

The attack did not require any model to be compromised. Sapphire Sleet, a North Korean state actor Microsoft tracks as primarily targeting the financial sector, took over a single forgotten maintainer account called ehindero and used it to publish poisoned versions of 140-plus packages across the entire @mastra npm scope in an 88-minute window. The payload was not in the packages themselves. It was one level down, inside a dependency called easy-day-js, a typosquatted copy of the legitimate dayjs date library that receives 57 million weekly downloads.

easy-day-js copied dayjs's author name, homepage URL, repository link, license, and version numbering verbatim. The only difference was a postinstall hook in version 1.11.22 that disabled TLS verification, reached out to a raw IP address, and dropped a cross-platform cryptocurrency stealer. The hook ran during npm install. Code never needed to import the package for the payload to execute. According to Snyk's analysis, @mastra/core alone pulls roughly 4 million downloads a month.

The staged delivery made it worse. A clean bait version, easy-day-js@1.11.21, was published first at 07:05 UTC on June 16, containing only legitimate dayjs code. The weaponized version, 1.11.22, followed nineteen hours later. Any tooling that saw the first version and cleared it was not checking again.

Why this is a code review problem, not just an ops problem#

The instinct is to treat supply chain attacks as infrastructure. Rotate tokens, pin versions, run npm install --ignore-scripts. All correct. But the Mastra attack exploited a dependency that a developer would have accepted in a code review because it looked legitimate. That is the signal slopsquatting adds: hallucinated or typo-adjacent names pass human review more often than they should, because the names are plausible and the imports compile.

GitHub Copilot now generates 46% of a developer's code, up from 27% at launch. Copilot, Codex, Claude Code, Cursor, Gemini Code Assist, and Windsurf all hallucinate package names. The volume of AI-assisted code reaching review queues means reviewers are reading more imports than before, faster than before, with less context about each one. Manual inspection cannot scale to that volume.

What automated review catches that humans miss#

Three signals are machine-readable before any code ships. First, package existence: a static check against the actual registry at review time, not at install time, catches invented names before they ever reach a lockfile. Second, name proximity to high-download packages: easy-day-js sits one token away from dayjs. Edit-distance checks against known packages with high weekly downloads flag this class of typosquat without false-positives on genuinely novel packages. Third, postinstall script presence in transitive dependencies: legitimate utility packages rarely need to run arbitrary scripts on install. A dependency that appears in a generated diff, has a postinstall hook, and was published within the last 30 days warrants a hard stop.

Hyrax runs dependency provenance checks as part of its security agent domain. When Hyrax reviews a pull request, it flags non-existent packages, names that are suspiciously close to high-traffic registry entries, and install-time script execution in transitive deps. The 13-step verification process runs before Hyrax submits a PR, so these checks run on the proposed change, not on code already in production. The distinction matters: catching a hallucinated import before the lockfile is committed is faster and cleaner than rotating credentials after a postinstall hook has already fired.

The architectural detail that matters most is covered in how Hyrax reviews code: six agent groups run in parallel across the full repository, not just the diff. A hallucinated import in one file that shadows a legitimate package used elsewhere is a cross-file signal. A single-file linter misses it.

The attacker calculus is already shifting#

The Mastra attack was not opportunistic. Sapphire Sleet chose an agentic framework with a large active install base, used a legitimate-looking package name, staged a clean bait version to defeat naive scanners, and executed the full chain in under 90 minutes. That is a rehearsed operation. The target selection, @mastra, reflects awareness that agentic frameworks attract developer workstations with high-value credentials: cloud provider tokens, API keys, CI/CD service accounts.

The hallucination rate data and the Mastra attack are not separate stories. One explains why the attack surface is large; the other explains what professional exploitation of that surface looks like. Any codebase where generated code introduces new dependencies needs package provenance checks running on every PR, not periodically.

Hyrax is live at hyrax.dev.