A hallucinated package name was already registered when the engineer went looking

An engineer asked an AI coding assistant for a library, got back a plausible-sounding package name that matched the ecosystem's naming conventions, and discovered that the name had already been registered by someone else and published with almost no download history ^[1][2]. The install command never ran, because a manual review flagged the low download count and the missing history first, according to a dev.to write-up that credits The Register with covering the incident ^[3].

That is the whole story, and its thinness is the point. The write-up notes the episode drew zero Hacker News comments ^[4], which is roughly the attention that "engineer performs code review correctly" usually earns.

The attack behind it, slopsquatting, needs no sophistication. Models hallucinate package names, and research has documented that certain names get suggested repeatedly across different sessions and even different models ^[5][6]. An attacker registers one of those names on PyPI or npm ^[7], publishes something that looks legitimate on the surface with a malicious payload ^[8], and waits for the next developer to ask a similar question and get the same name, which now resolves to real code ^[9]. Then pip install or npm install executes it ^[10]. No zero-day, no compromised maintainer account, no obfuscation ^[11].

Existing dependency tooling is aimed elsewhere. Scanners such as Snyk, Dependabot and npm audit compare what is already in your lockfile against known vulnerability databases ^[12]. A freshly registered, zero-download, attacker-controlled package has no CVEs filed against it ^[13]. The defect is not in the code; it is that the package should not be trusted at all ^[14].

Which leaves the control that actually fired here: a person noticing an unfamiliar name and opening the registry page to look ^[15]. That worked, and it is a bad control, because it depends on a human remembering to do it for every AI-suggested dependency, every time, and it is exactly the step that gets dropped under deadline pressure ^[16]. The gap the dev.to author identifies is real: there is no automated checkpoint between "the model suggests a name" and "the developer runs the install" that asks whether the package exists and whether it looks real ^[17].

The same post sells the fix, which is worth stating plainly ^[23]. It describes Sentinel's SlopScan, which extracts package names out of LLM output and checks them against live PyPI and npm data before the recommendation reaches a developer ^[18], with a /v1/scrub endpoint that acts before the caller does anything with the content ^[19]. Risk levels map to outcomes: DANGEROUS, meaning confirmed malicious or a known typosquat, is blocked; SUSPICIOUS, meaning the package does not exist or has a trust score near zero, is flagged; CAUTION covers packages that exist but are brand new ^[20][21][22].

Two things to watch. First, whether the check moves into the install path as a gate rather than staying a review habit, since the reported incident was caught by choice, not by process ^[3][15]. Second, the CAUTION tier: "exists, but brand new" is also an accurate description of every legitimate package on its first day ^[22], and a tier that fires constantly is a tier that gets clicked through.

The account is single-sourced and light on specifics: the write-up names no package, no registry, no assistant, and no date ^[24]. Treat it as one confirmed sighting of a pattern, not a sample size.