Cos'e lo slopsquatting? Il nuovo attacco HalluSquatting agli agenti di codice IA

Cos'e lo slopsquatting?

Lo slopsquatting e la pratica di registrare il nome di un pacchetto software che non esiste ma che un modello linguistico di grandi dimensioni ha buone probabilita di allucinare, cosi che uno sviluppatore o un agente IA installi il pacchetto dell'attaccante credendolo legittimo. Il termine e 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'IA) e "typosquatting".

Sotto di esso stanno due idee, e conviene tenerle distinte. L'allucinazione dei pacchetti (package hallucination) e il comportamento del modello: un LLM, a cui si chiede di scrivere codice, fa riferimento a un target di installazione che non e mai stato pubblicato. Lo slopsquatting e l'attacco che trasforma quel comportamento in un meccanismo di distribuzione, rivendicando per primo il nome allucinato. L'allucinazione e la vulnerabilita; lo slopsquatting e 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 e 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 e 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 e l'errore di ortografia di nulla. L'analisi dei nomi allucinati condotta da Socket ha rilevato che quasi la meta era altamente dissimile da qualsiasi pacchetto reale, fabbricata eppure credibile nel contesto, il che e 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 e che l'attaccante non deve indovinare. E il modello a dirgli cosa registrare.

Cio che rende sfruttabile il secondo passo e che le allucinazioni non sono rumore casuale. Nello studio piu 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 piu di una volta. Il modello non inventa un nome falso diverso ogni volta; gravita verso gli stessi. Un attaccante puo raccogliere questi nomi in massa, registrare quelli ricorrenti e aspettare. Poiche gli agenti in modalita 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 anziche un caso limite. La misurazione definitiva e lo studio USENIX Security 2025 "We Have a Package for You!" dell'Universita 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 e 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 piu 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 piu 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 e gia accaduto nel mondo reale?

Si, 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 piu 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 e che ora sono gli agenti IA 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 gia 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 e rimasta in una singola finestra di chat; e stata committata, condivisa e rieseguita da ogni agente che leggeva la skill.

Cos'e 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 (Universita 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, anziche sperare che atterrino su una che l'attaccante gia 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.

Perche uno scanner non riesce a coglierlo?

Perche 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 e 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 e 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 e prima che il comando di installazione venga eseguito.

Come prevenire lo slopsquatting

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

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

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

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

4. Vincola la provenienza dei pacchetti. Usa un mirror interno, un registry privato o una allowlist cosi che l'agente possa installare solo da fonti verificate. Se un nome allucinato non e nel mirror, l'installazione fallisce in modo sicuro (fail closed) anziche 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 cogliera 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 piu scrutinio di cento righe di logica di business, perche 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 e una prova. Un nome che il modello presenta come ovvio e esattamente il nome che un attaccante ha gia verificato piacere al modello.

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

Ripercorri quell'elenco e i controlli efficaci condividono una proprieta: 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 gia recuperato ed eseguito il pacchetto. Al ritmo dell'agente, e troppo tardi. Il posto in cui imporre "non installare un pacchetto che non puoi verificare" e dentro il loop dell'agente, nel momento in cui l'agente allunga la mano verso il comando di installazione.

E questo il livello che aggiunge VibeDefend. E una CLI npm gratuita che si installa in circa cinque secondi e collega i tuoi agenti di codice IA (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, cosi 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, cosi "verifica che una dipendenza esista e sia attendibile prima di aggiungerla" e una regola che l'agente legge al momento del prompt anziche 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, cosi un problema di dipendenza viene smistato nel loop invece di emergere giorni dopo.

E la SCA di CybeDefend aggiorna la propria intelligence sulle vulnerabilita in continuo, con un nuovo pull circa ogni quindici minuti, cosi che nell'istante in cui un pacchetto viene divulgato come dannoso questo emerga nell'agente nel giro di minuti anziche 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 piu 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 e scattata, il percorso del file, la severita, un timestamp) raggiungono il backend, e i tenant EU e US sono fisicamente separati. Questo non sostituisce lockfile, allowlist e revisione umana. E il livello che li rende applicabili alla velocita a cui un agente lavora davvero, cosi che l'installazione di un pacchetto che non e mai stato reale venga fermata prima che accada, anziche indagata dopo.

CybeDefend e il livello di AppSec al momento dell'agente costruito esattamente per questo. Collega ogni agente di codice IA 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'e lo slopsquatting?

Lo slopsquatting e un attacco alla catena di fornitura del software (supply chain) che registra il nome di un pacchetto che un modello IA ha buone probabilita di allucinare, cosi che sviluppatori e agenti di codice IA 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 perche 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 e la differenza tra slopsquatting e typosquatting?

Il typosquatting sfrutta gli errori di battitura umani registrando nomi che assomigliano molto a pacchetti reali, quindi puo essere rilevato misurando la distanza tra stringhe dalle librerie popolari. Lo slopsquatting sfrutta l'allucinazione dell'IA 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 IA inventi una dipendenza e la installi per te.

Cos'e l'attacco HalluSquatting?

L'HalluSquatting e 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 gia possiede, usa un innesco avversariale universale e trasferibile per far allucinare agli agenti IA 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 IA?

Molto comuni. Uno studio USENIX Security 2025 su 2.23 milioni di campioni di codice generati dall'IA 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 ripetibilita e cio che rende sfruttabile il problema, perche 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 e fabbricato anziche una quasi-corrispondenza, quindi non e vicino a nulla di cio che il filtro sorveglia. La software composition analysis gira dopo che un pacchetto e installato e cerca versioni con vulnerabilita note, ma un pacchetto dannoso appena registrato non ha ancora una CVE, e il suo script di installazione e gia stato eseguito quando la SCA guarda. Vale la pena eseguire entrambi come reti di sicurezza; nessuno dei due ferma l'installazione in se.

Come impedisco al mio agente di codice IA 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 integrita cosi che le nuove dipendenze siano visibili e revisionabili. Poiche questi controlli aiutano solo se qualcosa li impone prima che il comando di installazione venga eseguito, la soluzione duratura e 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, anziche uno scanner che legge il danno a posteriori.