Cos'è lo slopsquatting? Il nuovo attacco HalluSquatting agli agenti di codice AI

Cos'è lo slopsquatting?

Lo slopsquatting è la pratica di registrare il nome di un pacchetto software che non esiste ma che un modello linguistico di grandi dimensioni ha buone probabilità di allucinare, così che uno sviluppatore o un agente AI installi il pacchetto dell'attaccante credendolo legittimo. Il termine è stato coniato da Seth Larson, Security Developer-in-Residence presso la Python Software Foundation, nell'aprile 2025, come fusione dei termini "AI slop" (la sbrodolatura prodotta dall'AI) e "typosquatting".

Sotto di esso stanno due idee, e conviene tenerle distinte. L'allucinazione dei pacchetti (package hallucination) è il comportamento del modello: un LLM, a cui si chiede di scrivere codice, fa riferimento a un target di installazione che non è mai stato pubblicato. Lo slopsquatting è l'attacco che trasforma quel comportamento in un meccanismo di distribuzione, rivendicando per primo il nome allucinato. L'allucinazione è la vulnerabilità; lo slopsquatting è l'exploit.

“

Un essere umano che legge "pip install reqwest-py" potrebbe fermarsi e controllare. Un agente esegue il comando. Nel momento in cui il nome di un pacchetto passa da un suggerimento che una persona digita a un'azione che un agente esegue, l'ultimo punto di controllo umano scompare.

Slopsquatting contro typosquatting: qual è la differenza?

Sono entrambi attacchi di confusione dei nomi sulla catena di fornitura del software (supply chain), ma sfruttano errori diversi e, cosa cruciale, eludono difese diverse.

La differenza portante è la terza riga. Le difese anti-typosquatting presumono che il nome dannoso assomigli a uno reale, quindi segnalano i pacchetti entro una piccola distanza di modifica dalle librerie popolari. Un nome allucinato non è l'errore di ortografia di nulla. L'analisi dei nomi allucinati condotta da Socket ha rilevato che quasi la metà era altamente dissimile da qualsiasi pacchetto reale, fabbricata eppure credibile nel contesto, il che è esattamente il motivo per cui il rilevamento dei sosia scivola oltre senza vederli.

Come funziona davvero un attacco di slopsquatting?

L'attacco ha quattro passi, e la parte scomoda è che l'attaccante non deve indovinare. È il modello a dirgli cosa registrare.

Ciò che rende sfruttabile il secondo passo è che le allucinazioni non sono rumore casuale. Nello studio più ampio fino a oggi, i ricercatori hanno rieseguito lo stesso prompt dieci volte e hanno scoperto che il 43% dei nomi di pacchetti allucinati riappariva in tutte e dieci le esecuzioni, e il 58% riappariva più di una volta. Il modello non inventa un nome falso diverso ogni volta; gravita verso gli stessi. Un attaccante può raccogliere questi nomi in massa, registrare quelli ricorrenti e aspettare. Poiché gli agenti in modalità autonoma o "yolo" installano ed eseguono senza conferma, l'hook post-installazione del payload scatta nell'istante in cui il pacchetto atterra, prima che esista una pull request da rivedere.

Quanto sono comuni i pacchetti allucinati?

Abbastanza comuni da essere un canale di distribuzione anziché un caso limite. La misurazione definitiva è lo studio USENIX Security 2025 "We Have a Package for You!" dell'Università del Texas a San Antonio e di Virginia Tech, che ha analizzato 2,23 milioni di campioni di codice generati da 16 modelli tra Python e JavaScript.

Il tasso non è uniforme. I modelli open-source hanno allucinato pacchetti nel 21,7% dei campioni contro il 5,2% dei modelli commerciali, un divario di circa quattro volte, e alcuni modelli specializzati nel codice hanno inventato un pacchetto in più di un terzo dei loro output. Due forze spingono poi il rischio verso l'alto nel tempo, non verso il basso: i team lasciano sempre più che gli agenti scrivano e installino dipendenze senza sorveglianza, e gli stessi modelli continuano a suggerire gli stessi nomi fabbricati a chiunque li interroghi.

Lo slopsquatting è già accaduto nel mondo reale?

Sì, e la prova precede il nome. Alla fine del 2023, il ricercatore di sicurezza Bar Lanyado di Lasso Security ha notato che diversi modelli allucinavano ripetutamente un pacchetto Python chiamato huggingface-cli. Come innocua prova di concetto (proof of concept) ha pubblicato un pacchetto vuoto sotto quel nome. Nel giro di tre mesi era stato scaricato più di 30.000 volte e, come ha riportato The Register, una grande azienda (Alibaba) faceva riferimento al comando di installazione nel README di uno dei propri repository di ricerca. Il pacchetto era benigno. Un attore malintenzionato che osservava la stessa allucinazione non lo sarebbe stato.

La svolta del 2026 è che ora sono gli agenti AI a diffondere questi nomi per te. La nota di ricerca sullo slopsquatting dell'aprile 2026 della Cloud Security Alliance documenta come i comandi di installazione allucinati si propaghino attraverso file di "agent skill" copiati e incollati. In un caso del gennaio 2026, un pacchetto npm fabbricato (un nome che un modello ha prodotto fondendo due strumenti reali) era già referenziato da 237 repository GitHub prima che qualcuno lo segnalasse, seminato in gran parte da un singolo commit che aggiungeva decine di file skill generati da un LLM. L'allucinazione non è rimasta in una singola finestra di chat; è stata committata, condivisa e rieseguita da ogni agente che leggeva la skill.

Cos'è l'attacco HalluSquatting (luglio 2026)?

Per gran parte della breve storia dello slopsquatting l'attaccante era opportunista: registrare qualsiasi nome il modello tendesse a prediligere, poi aspettare. Un paper pubblicato l'8 luglio 2026, "Beware of Agentic Botnets" di Spira, Cohen, Feldman, Bitton, Wool e Nassi (Università di Tel Aviv, Technion e Intuit), elimina l'attesa. Dimostra un innesco avversariale universale e trasferibile che fa allucinare agli agenti una risorsa specifica, scelta dall'attaccante, su richiesta, anziché sperare che atterrino su una che l'attaccante già possiede.

Il meccanismo concatena due falle descritte nelle sezioni precedenti. Primo, l'innesco guida l'agente a recuperare una risorsa (un repo, una skill, un pacchetto) sotto un nome controllato dall'attaccante. Secondo, una prompt injection indiretta nascosta dentro quella risorsa recuperata viene eseguita quando il terminale dell'agente la lancia, ottenendo l'esecuzione remota di strumenti (remote tool execution) e installando malware botnet auto-propagante. I ricercatori inquadrano il risultato come un attacco non mirato e scalabile: un solo innesco avversariale, nessuna configurazione per singola vittima, malware che si diffonde da un agente compromesso al successivo.

Perché uno scanner non riesce a coglierlo?

Perché i due controlli su cui la maggior parte dei team fa affidamento guardano entrambi nel posto sbagliato o arrivano troppo tardi.

Leggi la colonna di destra e ne emerge un unico tema. Ognuno di questi controlli agisce sul pacchetto dopo che è su disco, oppure cerca una somiglianza che un nome fabbricato non ha. Lo script di installazione di una dipendenza dannosa gira al momento dell'installazione, che per un agente autonomo è a pochi secondi da quando il modello ha inventato il nome, e molto prima che qualsiasi scanner, revisore o feed di CVE dica la sua. L'unico posto dove fermarlo è prima che il comando di installazione venga eseguito.

Come prevenire lo slopsquatting

Nessuna di queste è esotica. La disciplina sta nell'applicarle ad agenti che si muovono più in fretta degli esseri umani che li supervisionano.

1. Disattiva l'auto-installazione alla cieca. Non eseguire gli agenti in modalità completamente autonome di "installa ed esegui" contro credenziali reali. Richiedi un'approvazione esplicita per ogni nuova dipendenza, così che un nome fabbricato debba superare almeno uno sguardo umano.

2. Verifica che un pacchetto esista e sia reale prima di aggiungerlo. "Si è installato" non è prova di legittimità; l'attaccante si è assicurato che si installasse. Controlla che il pacchetto abbia una storia autentica: età, traiettoria dei download, un vero repository sorgente, manutentori con nome. Un pacchetto registrato la settimana scorsa che un modello giura essere standard è la forma esatta di questo attacco.

3. Fissa le versioni e committa i lockfile con hash di integrità. Un lockfile con gli hash significa che una versione sostituita o appena avvelenata non può rimpiazzarsi in silenzio, e rende una nuova dipendenza visibile come una modifica revisionabile anziché come un tiraggio transitivo invisibile.

4. Vincola la provenienza dei pacchetti. Usa un mirror interno, un registry privato o una allowlist così che l'agente possa installare solo da fonti verificate. Se un nome allucinato non è nel mirror, l'installazione fallisce in modo sicuro (fail closed) anziché raggiungere il registry pubblico.

5. Esegui la software composition analysis, come rete di sicurezza. Vale la pena eseguire la SCA su ogni nuova dipendenza, ma trattala come l'ultima rete, non la prima. Coglie pacchetti e versioni note come dannosi; non coglierà un pacchetto dannoso zero-day nel giorno in cui viene registrato.

6. Rivedi in modo specifico le nuove dipendenze. Rendi "questa modifica ha aggiunto una dipendenza?" un passo di revisione esplicito. Un'aggiunta di una riga a package.json o requirements.txt merita più scrutinio di cento righe di logica di business, perché importa il codice di qualcun altro con i tuoi privilegi.

7. Isola il lavoro non attendibile dell'agente. Quando un agente gira contro un repository sconosciuto o contenuti di terze parti, dagli un container senza segreti dell'host e senza percorso verso la produzione. Gli script di installazione girano immediatamente, quindi un agente guidato non dovrebbe avere nulla di prezioso a portata quando uno di essi scatta.

8. Tratta i pacchetti suggeriti dall'agente come input non attendibile. La sicurezza del suggerimento non è una prova. Un nome che il modello presenta come ovvio è esattamente il nome che un attaccante ha già verificato piacere al modello.

Dove deve vivere la prevenzione: l'applicazione al momento del prompt

Ripercorri quell'elenco e i controlli efficaci condividono una proprietà: agiscono prima che il comando di installazione venga eseguito. Lo scanner che legge un diff, il feed SCA, il database delle CVE, arrivano tutti dopo che l'agente ha già recuperato ed eseguito il pacchetto. Al ritmo dell'agente, è troppo tardi. Il posto in cui imporre "non installare un pacchetto che non puoi verificare" è dentro il loop dell'agente, nel momento in cui l'agente allunga la mano verso il comando di installazione.

È questo il livello che aggiunge VibeDefend. È una CLI npm gratuita che si installa in circa cinque secondi e collega i tuoi agenti di codice AI (Claude Code, OpenAI Codex, Cursor, Windsurf e VS Code Copilot) a una governance che gira mentre lavorano, non dopo.

Due dei quattro livelli mappano direttamente su questo attacco. Action Guard intercetta l'azione rischiosa prima che parta: l'installazione di un pacchetto non verificato, nuovo di zecca o assente dalla tua allowlist viene segnalata o bloccata, con l'intercettazione nell'audit trail, così che la dipendenza fabbricata non raggiunga mai il passo di installazione. Le regole di sicurezza caricano la disciplina stessa nel contesto dell'agente prima che scriva, così "verifica che una dipendenza esista e sia attendibile prima di aggiungerla" è una regola che l'agente legge al momento del prompt anziché una voce di checklist che nessuno ha applicato. Accanto a esse, Live Findings mantiene ogni risultato degli scanner di CybeDefend (SAST con reachability, SCA, segreti, IaC e CI/CD) live nel contesto dell'agente, così un problema di dipendenza viene smistato nel loop invece di emergere giorni dopo.

E la SCA di CybeDefend aggiorna la propria intelligence sulle vulnerabilità in continuo, con un nuovo pull circa ogni quindici minuti, così che nell'istante in cui un pacchetto viene divulgato come dannoso questo emerga nell'agente nel giro di minuti anziché alla scansione notturna successiva, e ogni dipendenza che l'agente tira dentro viene controllata nel loop. I due livelli si coprono le lacune a vicenda: Action Guard blocca l'installazione di un pacchetto nuovo di zecca che nessuno ha ancora segnalato, e una SCA aggiornata di continuo coglie quelli che vengono rivelati come dannosi solo più tardi.

In modo cruciale, nulla del tuo codice attraversa la rete. Le decisioni avvengono localmente accanto all'agente; solo metadati di governance strutturati (la regola che è scattata, il percorso del file, la severità, un timestamp) raggiungono il backend, e le regioni EU e US sono fisicamente separate. Questo non sostituisce lockfile, allowlist e revisione umana. È il livello che li rende applicabili alla velocità a cui un agente lavora davvero, così che l'installazione di un pacchetto che non è mai stato reale venga fermata prima che accada, anziché indagata dopo.

CybeDefend è il livello di AppSec al momento dell'agente costruito esattamente per questo. Collega ogni agente di codice AI sulla tua macchina alle tue regole di business, ai tuoi framework di sicurezza (OWASP, SOC 2, GDPR, ISO 27001), a un Action Guard che blocca le installazioni non sicure o non verificate prima che partano, e alla scansione aggiornata di continuo di ogni dipendenza e di ogni riga che l'agente scrive. Lo slopsquatting funziona solo nello spazio tra un modello che inventa un nome e un essere umano che se ne accorge. CybeDefend chiude quello spazio, dentro il loop, prima ancora che la PR venga aperta.

Domande frequenti

Cos'è lo slopsquatting?

Lo slopsquatting è un attacco alla catena di fornitura del software (supply chain) che registra il nome di un pacchetto che un modello AI ha buone probabilità di allucinare, così che sviluppatori e agenti di codice AI installino il pacchetto dannoso dell'attaccante credendolo una dipendenza reale. Il termine, coniato da Seth Larson della Python Software Foundation nell'aprile 2025, combina "AI slop" e "typosquatting". Funziona perché i modelli linguistici di grandi dimensioni inventano nomi di pacchetti plausibili che non esistono, e inventano costantemente gli stessi, offrendo agli attaccanti un elenco prevedibile di nomi da rivendicare.

Qual è la differenza tra slopsquatting e typosquatting?

Il typosquatting sfrutta gli errori di battitura umani registrando nomi che assomigliano molto a pacchetti reali, quindi può essere rilevato misurando la distanza tra stringhe dalle librerie popolari. Lo slopsquatting sfrutta l'allucinazione dell'AI registrando nomi del tutto fabbricati che un modello inventa, che non sono errori di ortografia di alcun pacchetto reale e quindi eludono il rilevamento dei sosia. In breve, il typosquatting scommette sul fatto che le tue dita scivolino; lo slopsquatting scommette sul fatto che il tuo assistente AI inventi una dipendenza e la installi per te.

Cos'è l'attacco HalluSquatting?

L'HalluSquatting è un'escalation del 2026 dello slopsquatting descritta nel paper "Beware of Agentic Botnets" (arXiv, 8 luglio 2026). Invece di aspettare che un modello si imbatta in un nome che l'attaccante già possiede, usa un innesco avversariale universale e trasferibile per far allucinare agli agenti AI una risorsa specifica scelta dall'attaccante su richiesta, poi lo concatena con una prompt injection indiretta per ottenere l'esecuzione di codice remoto e diffondere malware botnet. I ricercatori hanno riportato tassi di risorse allucinate fino all'85% per la clonazione di repository e del 100% per l'installazione di skill su nove assistenti tra cui Cursor, Windsurf, Copilot, Cline e Gemini CLI.

Quanto sono comuni le allucinazioni dei pacchetti AI?

Molto comuni. Uno studio USENIX Security 2025 su 2,23 milioni di campioni di codice generati dall'AI ha rilevato che il 19,7% faceva riferimento ad almeno un pacchetto allucinato, ha catalogato 205,474 nomi fabbricati unici e ha mostrato che le allucinazioni sono ripetibili: il 43% di esse ricorreva in tutte e dieci le riesecuzioni dello stesso prompt. I modelli open-source erano peggiori (21.7%) di quelli commerciali (5.2%). La ripetibilità è ciò che rende sfruttabile il problema, perché gli attaccanti possono prevedere e pre-registrare i nomi che un modello predilige.

Uno scanner SCA o il rilevamento del typosquatting possono cogliere lo slopsquatting?

Non in modo affidabile, e per due motivi diversi. Il rilevamento del typosquatting cerca nomi entro una piccola distanza di modifica dai pacchetti reali, ma un nome allucinato è fabbricato anziché una quasi-corrispondenza, quindi non è vicino a nulla di ciò che il filtro sorveglia. La software composition analysis gira dopo che un pacchetto è installato e cerca versioni con vulnerabilità note, ma un pacchetto dannoso appena registrato non ha ancora una CVE, e il suo script di installazione è già stato eseguito quando la SCA guarda. Vale la pena eseguire entrambi come reti di sicurezza; nessuno dei due ferma l'installazione in sé.

Come impedisco al mio agente di codice AI di installare pacchetti allucinati?

Non lasciare che gli agenti installino dipendenze senza sorveglianza, verifica che qualsiasi nuovo pacchetto esista davvero e abbia una storia reale prima di aggiungerlo, vincola le installazioni a un registry privato o a una allowlist, e committa i lockfile con hash di integrità così che le nuove dipendenze siano visibili e revisionabili. Poiché questi controlli aiutano solo se qualcosa li impone prima che il comando di installazione venga eseguito, la soluzione duratura è l'applicazione al momento del prompt: un controllo come VibeDefend che intercetta l'installazione di un pacchetto non verificato o inesistente dentro il loop dell'agente, anziché uno scanner che legge il danno a posteriori.