Slopsquatting: Quando l'AI Inventa Pacchetti che Non Esistono

Chiedi a un LLM di scriverti del codice. Il codice ha un import. L'import fa riferimento a un pacchetto. Tu fai pip install o npm install. Il pacchetto si installa. Funziona.

Solo che quel pacchetto non è quello che pensi. Il nome è stato inventato dall'AI — un'allucinazione. E qualcuno, nel frattempo, ha registrato quel nome su PyPI o npm con dentro codice che ruba le tue credenziali.

Si chiama slopsquatting, ed è il nuovo vettore di attacco della software supply chain.

Cos'è lo Slopsquatting

Il termine è stato coniato nell'aprile 2025 da Seth Larson, Developer-in-Residence della Python Software Foundation. È un portmanteau di "AI slop" (output AI di bassa qualità, non verificato) e "typosquatting" (la pratica di registrare nomi di pacchetto con errori di battitura per intercettare installazioni errate).

La differenza fondamentale con il typosquatting classico:

Il typosquatting è "sbagliato di un carattere". Lo slopsquatting è "inventato di sana pianta ma suona perfettamente legittimo".

Come Funziona l'Attacco

Step 1: L'AI Allucina

Chiedi a un LLM: "Come faccio a implementare autenticazione JWT in Flask?"

L'LLM risponde con codice che importa flask-jwt-secure — un pacchetto che non è mai esistito su PyPI. Ma il nome suona perfettamente ragionevole. Chi andrebbe a controllare?

Step 2: L'Attaccante Raccoglie

Un attaccante fa sistematicamente prompt agli LLM con domande di coding comuni e raccoglie tutti i nomi di pacchetto inventati. Il lavoro è facile perché le allucinazioni sono ripetibili: il 58% riappare in query successive, il 43% appare in tutte e 10 le ripetizioni dello stesso prompt.

Step 3: Registrazione

L'attaccante registra quei nomi su PyPI, npm, o altri registry. Ci mette dentro codice malevolo — tipicamente ruba variabili d'ambiente, token npm, credenziali GitHub, chiavi SSH, segreti CI/CD.

Step 4: La Vittima Installa

Quando uno sviluppatore (o una pipeline CI/CD) esegue pip install o npm install dal codice generato dall'AI, il package manager risolve il nome al pacchetto dell'attaccante e lo installa. Il payload gira.

Perché Funziona Così Bene

L'attacco sfrutta due debolezze simultanee:

1. La fiducia cieca nell'output AI: quanti sviluppatori verificano manualmente ogni pacchetto suggerito dall'AI prima di installarlo?
2. I registry aperti: npm e PyPI permettono a chiunque di registrare qualsiasi nome, senza verifica

I Numeri

Lo Studio USENIX Security 2025

I ricercatori dell'Università del Texas, Virginia Tech e Oklahoma hanno analizzato 576.000 campioni di codice generati da 16 LLM diversi. I risultati:

• Il 19.7% dei pacchetti raccomandati non esisteva su nessun registry pubblico
• Trovati 205.474 nomi di pacchetto unici inventati
• Modelli commerciali (GPT-4, Claude): media 5.2% di allucinazioni
• Modelli open-source: media 21.7% — quattro volte peggio
• Python: 15.8% di pacchetti allucinati
• JavaScript/npm: 21.3%
• Il 43% dei nomi inventati riappare consistentemente in query ripetute

Quale Modello Allucina di Più

I modelli commerciali più recenti allucinano meno, ma nessuno è immune. Anche il migliore (GPT-4 Turbo al 3.59%) su scala significa migliaia di nomi inventati al giorno.

Composizione delle Allucinazioni

Come vengono generati questi nomi inventati:

• 51%: completamente fabbricati (nessuna relazione con pacchetti reali)
• 38%: ispirati da pacchetti reali (pattern di naming simili)
• 13%: errori tipografici su nomi reali (overlap con typosquatting classico)

Trend Micro ha identificato quattro meccanismi specifici:

1. Context-gap filling: il modello compone morfemi semanticamente rilevanti senza verificare il registry
2. Surface-form mimicry: applica convenzioni di naming senza validazione
3. Cross-ecosystem borrowing: un termine JavaScript viene riusato per Python
4. Morpheme splicing: token descrittivi cuciti insieme (graph-database-orm, data-transformer)

Il Caso PhantomRaven: Il Primo Attacco Reale

A ottobre 2025, Koi Security ha scoperto la campagna PhantomRaven — il primo exploit slopsquatting su larga scala documentato.

I numeri:

• 126 pacchetti npm malevoli registrati
• 86.000+ installazioni totali
• Attivo da agosto 2025

I nomi dei pacchetti erano esattamente quelli che gli LLM tendono ad allucinare: unused-imports (1.350 download), eslint-comments (936), polyfill-corejs3 (475). Nomi che suonano perfettamente legittimi — e che nessun tool di sicurezza basato su edit-distance avrebbe segnalato, perché non assomigliano a nessun pacchetto reale specifico.

Il payload rubava:

• Token npm
• Credenziali GitHub
• Segreti CI/CD
• Indirizzi email
• Fingerprint di sistema
• IP pubblici

La parte più sofisticata: il codice malevolo non era nel pacchetto stesso, ma in una dipendenza nascosta che puntava a un server HTTP custom (packages.storeartifact[.]com) invece che a npmjs.com — eludendo l'analisi statica e i dependency scanner tradizionali.

L'Esperimento huggingface-cli

Prima di PhantomRaven, il ricercatore Bar Lanyado (Vulcan Cyber / Lasso Security) aveva dimostrato il rischio con un esperimento elegante.

A metà 2023, notò che gli LLM inventavano ripetutamente un pacchetto chiamato huggingface-cli. Non esisteva su PyPI. Così lo registrò lui stesso — un pacchetto vuoto, benigno, solo per misurare.

In 3 mesi: 30.000 download autentici.

Il pacchetto è stato persino citato nel README di un repository di ricerca di Alibaba su GitHub.

Per verificare che i download fossero genuini e non bot, caricò un pacchetto di controllo con un nome senza senso (blabladsa123) — download trascurabili. I 30.000 erano tutti sviluppatori reali che avevano copiato codice AI senza verificare.

Quali Ecosistemi Sono Più a Rischio

npm e PyPI sono i più vulnerabili per un motivo semplice: chiunque può registrare qualsiasi nome. Non c'è verifica di identità, non c'è approvazione, non c'è nemmeno un periodo di attesa.

Come Proteggersi

Per lo Sviluppatore Individuale

1. Verifica ogni pacchetto AI-suggested prima di installarlo. Cerca il nome su npm/PyPI. Se ha zero download, zero stelle, e una data di creazione recente — fermati
2. Usa lockfile e verifica gli hash: package-lock.json, poetry.lock, go.sum. Se l'hash cambia, qualcuno ha modificato il pacchetto
3. Non fare mai pip install di codice AI senza leggere gli import prima
4. Usa ambienti sandboxed per testare codice AI-generated prima di farlo girare sul tuo sistema
5. Installa pip audit (Python) o equivalenti per scansioni regolari

Per il Team / l'Azienda

6. Dependency allowlist: permetti solo pacchetti da una lista approvata
7. Proxy interno per tutte le richieste ai registry esterni — punto unico di scansione
8. Scanner di supply chain nella pipeline CI/CD (Snyk, Socket.dev, Mend.io)
9. SBOM (Software Bill of Materials) per tracciare l'origine di ogni dipendenza
10. Segnala pacchetti sospetti: creazione recente, pochi download, nessuna versione precedente

Per chi Configura gli LLM

11. Abbassa la temperatura: riduce la casualità e quindi le allucinazioni
12. Usa coding agent con validazione: Claude Code CLI e Codex CLI riducono le allucinazioni del ~50% rispetto ai modelli base
13. Abilita MCP-backed validation dove disponibile (come in Cursor AI) — verifica i pacchetti in tempo reale contro i registry

Nessuna di queste misure è sufficiente da sola. Nessuna elimina il rischio al 100%.

Il Problema Di Fondo

Lo slopsquatting funziona perché espone due fragilità simultanee del modo in cui sviluppiamo software nel 2026:

La prima: gli LLM non hanno accesso ai registry dei pacchetti in tempo reale. Quando generano codice, non fanno pip search per verificare che il pacchetto esista. Inventano nomi plausibili basandosi sui pattern linguistici del training data. È lo stesso meccanismo che gli fa scrivere codice sintatticamente corretto ma logicamente sbagliato — applicato ai nomi dei pacchetti.

La seconda: il nostro ecosistema di pacchetti si basa sulla fiducia. npm ha 2+ milioni di pacchetti. PyPI ne ha 500.000+. Nessun essere umano li conosce tutti. E il workflow npm install qualcosa funziona esattamente allo stesso modo sia che il pacchetto sia stato creato da un team affidabile 5 anni fa, sia che sia stato registrato ieri da un account anonimo.

Lo slopsquatting non è un bug dell'AI. È un bug dell'ecosistema — amplificato dall'AI. E finché i registry non implementeranno verifiche più stringenti e i modelli non avranno accesso in tempo reale ai registry, il vettore resterà aperto.

Nel frattempo, la mitigazione più efficace è anche la più vecchia del mondo: leggi quello che installi.

Fonti e approfondimenti:

• USENIX Security 2025 - "We Have a Package for You!" (576K campioni)
• Socket.dev - The Rise of Slopsquatting
• The Hacker News - PhantomRaven: 126 pacchetti npm malevoli
• Lasso Security - AI Package Hallucinations (esperimento huggingface-cli)
• Trend Micro - Slopsquatting White Paper
• CSO Online - AI Hallucinations Lead to New Cyber Threat