Slopsquatting uses AI‑hallucinated names to threaten open‑source projects
Slopsquatting is the name for a new software supply chain attack built directly on LLM package hallucinations. The source frames it as a category shift from typosquatting: instead of betting on developer typos, attackers register the non-existent package names that AI coding assistants confidently invent, then upload malware under those names. The risk is structural rather than incidental, and it lives in the gap between what models sound sure about and what actually exists in a package registry.
The hallucination problem is the mechanism, not the new part. A study cited in the source places code-generation hallucination rates between 50% and 82% across model and prompting combinations, with the best-performing system, GPT-4o, still producing hallucinations 23% of the time even after prompt-based mitigation. Slopsquatting becomes dangerous because the hallucinations are not random noise. Models tend to repeat the same plausible-sounding package names across sessions, which means an attacker who registers one well-chosen hallucinated name can potentially hit a wide population of developers rather than one unlucky typo.
The numbers on model exposure are where the post carries its sharpest editorial weight. The source describes a study covering 30 systems, 576,000 code samples, and 2.23 million packages, with a 19.7% overall hallucination rate. Proprietary models performed roughly four times better than open-source ones on this metric: GPT-4.0 Turbo sat at 3.59%, while DeepSeek 1B, the best-performing open-source model the study measured, hit 13.63%. The source reads that gap as evidence that organizations running open-source code models are about four times more exposed to slopsquatting than those on proprietary stacks. That is a defensible reading of the study, but it has limits the source does not address: the comparison is across a fixed set of models at a fixed point in time, and the threat model assumes attackers are reading the same study and prioritizing open-source hallucinations first.
Two assumptions deserve scrutiny. First, the source's central claim, that hallucinated names are not flagged by existing registry protections the way typosquatted names are, follows from how package squatting defenses are built. Registries catch near-duplicates; they do not catch fabricated names that sound reasonable. That logic holds, but the source does not describe how individual registries, language ecosystems, or developer tools actually score plausibility, so the registry-side defense gap is asserted rather than measured. Second, the source notes that adversarial hallucination attacks, including token-level manipulation and retrieval poisoning, could push models toward attacker-chosen package names. That is a plausible direction the source flags, not a documented campaign. Treating it as an active threat overstates what the source establishes.
The workflow pressure is real even if the registry defenses are vague. The source cites estimates that over 40% of committed code already involves AI assistance, with daily use around 72% among developers who have tried AI coding tools, and projects that share continuing to rise. Slopsquatting does not require a sophisticated exploit chain; it requires a developer to trust an import statement. The source's practical guidance, verifying that recommended packages exist in official repositories and using automated checks against known registries, is reasonable advice, but the source does not benchmark how often those checks fail to catch hallucinated names that look like legitimate additions or extensions to real libraries, the same surface where registry protections are weakest.
The source also reports a separate vulnerability study covering 31,267 vulnerabilities across 14,675 packages in 10 languages, with reported vulnerabilities growing 98% year over year against a 25% growth in package count, and an 85% rise in average vulnerability lifespan. Those numbers describe the open-source vulnerability backlog broadly; the source uses them to argue that the detection environment is degrading. That is a defensible framing, but the connection to slopsquatting specifically depends on the assumption that hallucinated-name compromises behave like the broader vulnerability population, which the source does not test.
The useful question is not whether slopsquatting is real. The model behavior, the registry gap, and the developer-trust handoff all point in the same direction. The question is which workflows actually catch a fabricated package name before it ships, and whether proprietary-model advantages hold once attackers know which names to register. The source does not answer either, and the deployment case depends on both.