Allucinazioni che infettano: lo slopsquatting e i nuovi attacchi alla supply chain nell’era degli AI agent

Introduzione

L’integrazione degli agenti di coding basati su grandi modelli linguistici (LLM) ha raggiunto un punto di non ritorno: strumenti come GitHub Copilot, Cursor o Gemini CLI scrivono, installano dipendenze e persino eseguono comandi in autonomia. Proprio questa autonomia nasconde una vulnerabilità sistemica che tre recenti campagne – battezzate Slopsquatting, Phantom Squatting e HalluSquatting – hanno portato alla luce. Il meccanismo è tanto semplice quanto devastante: i modelli “allucinano” identificativi (nomi di pacchetti, domini, repository) e, se un attaccante li ha registrati in anticipo, l’agente esegue codice malevolo senza alcuna interazione umana. Niente phishing, niente furto di credenziali: basta la prevedibilità statistica delle allucinazioni.

Analisi tecnica

Un team di ricerca guidato da Ben Nassi (Tel Aviv University, Technion, Intuit) ha dimostrato quantitativamente il problema: richieste di repository generate da LLM possono essere indovinate fino all’85% dei casi, mentre per le installazioni di skill si raggiunge il 100%. Questo significa che un aggressore può anticipare i nomi inesistenti che un Copilot o un Cline proveranno a utilizzare, registrarli e popolarli con payload dannosi. I tre attacchi sfruttano lo stesso principio, declinandolo su superfici diverse:

• Slopsquatting (gennaio 2026): l’agente suggerisce un pacchetto inesistente per risolvere una richiesta; il nome è così “tipico” che l’attaccante lo ha già pubblicato su un registro pubblico (es. PyPI, npm) con malware all’interno.
• Phantom Squatting (giugno 2026): la predizione riguarda domini o endpoint API allucinati; l’agente li contatta, scarica script e li esegue, convinto che siano legittimi.
• HalluSquatting (luglio 2026): compromette l’installazione di “skill” o estensioni che l’AI ritiene utili per completare il task; anche qui i nomi sono precalcolabili e pronti ad accogliere codice ostile.

In tutti i casi, la fiducia implicita nel modello trasforma un’allucinazione in un vettore di attacco deterministico. E poiché gli agenti operano spesso con permessi elevati e all’interno di pipeline CI/CD, il danno si propaga in profondità. La ricerca ha rilevato che gli strumenti di sicurezza tradizionali – antivirus, scanner di dipendenze, firme digitali – non intercettano la minaccia: non c’è un singolo file infetto da individuare, ma un flusso di lavoro che integra dinamicamente codice da fonti non verificate, eventualmente anche attraverso dipendenze transitive di pacchetti apparentemente innocui.

Impatto

La gravità è elevata, e i ricercatori avvertono che quanto osservato rappresenta il livello minimo di rischio. La prevedibilità delle allucinazioni consente di costruire catene di infezione completamente automatizzate: registrare nomi futuri, attendere che un agente li agganci e ottenere esecuzione remota di codice senza dover convincere una vittima umana. Le conseguenze immediate includono:

• Compromissione di ambienti di sviluppo, macchine locali e server di CI/CD, con accesso a segreti, codice sorgente e infrastrutture di produzione.
• Creazione di botnet silenziose, dove migliaia di agenti AI fungono da nodi senza i classici vettori di propagazione.
• Contaminazione a cascata nelle supply chain software: un componente malevolo introdotto da un’allucinazione può essere ereditato da tutti i progetti che dipendono da quella build, vanificando le policy statiche di controllo.
• Difficoltà di rilevamento e attribuzione, perché l’evento malevolo si confonde con il normale comportamento dell’agente e non lascia tracce di exploit tradizionali.

Mitigazione

Difendersi richiede un cambio di paradigma: non ci si può più fidare ciecamente dei suggerimenti automatici, né limitarsi a scansionare i pacchetti già installati. Le contromisure proposte da ricercatori e aziende come ActiveState includono:

1. Verifica preventiva degli identificativi – Prima di installare, clonare o eseguire qualsiasi risorsa indicata da un LLM, occorre accertarne l’esistenza reale e la paternità. Query ai registri ufficiali, controlli di proprietà dei domini e reputazione dei repository devono diventare operazioni standard.
2. Governance “at source” della supply chain – Integrare controlli che convalidino tutto ciò che entra nella build prima delle scansioni di sicurezza, spostando il baricentro dalla rilevazione postuma alla prevenzione.
3. Limitazione dei privilegi degli agenti AI – Eseguire gli agenti in sandbox con permessi minimi, proibire l’accesso diretto a sistemi critici e introdurre un’autorizzazione umana obbligatoria per ogni azione che comporti download ed esecuzione di codice.
4. Ispezione dell’intero albero delle dipendenze – Spesso il codice malevolo arriva da dipendenze transitive non monitorate. Occorre analizzare ogni ramo dell’albero, non solo il primo livello, e sorvegliare nel tempo modifiche sospette.
5. Binding anticipato – Ridurre al minimo la risoluzione ritardata degli identificativi generati dall’AI. Dove possibile, utilizzare nomi esplicitamente autorizzati e verificati prima dell’esecuzione, bloccando qualsiasi tentativo di lookup dinamico non previsto.
6. Monitoraggio predittivo – Costruire liste di nomi che i propri modelli tendono ad allucinare in specifici contesti. Questi nomi possono essere pre-registrati in un registro interno fittizio per intercettare tentativi di esecuzione, oppure aggiunti a blacklist per impedire richieste esterne.

FAQ

1. Cos’è esattamente lo slopsquatting e come differisce dal typosquatting tradizionale?
Lo slopsquatting sfrutta le allucinazioni dei modelli linguistici invece degli errori di battitura. Nel typosquatting l’attaccante registra un nome simile a uno legittimo (es. “googel.com”) sperando in un errore umano; nello slopsquatting il nome è del tutto inventato dal modello ma statisticamente probabile, e l’attaccante lo registra prima che l’agente lo cerchi, ottenendo esecuzione senza alcun errore umano.

2. Quali sono i primi segnali che un’organizzazione dovrebbe monitorare per accorgersi di un attacco simile?
Occorre prestare attenzione a richieste a domini o registri di pacchetti per nomi inesistenti generate da strumenti AI; un picco di tentativi verso risorse allucinate può indicare che un agente sta eseguendo codice non autorizzato. Anche modifiche anomale alle dipendenze transitive o l’esecuzione di script da fonti non note rappresentano campanelli d’allarme.

3. Basta disattivare l’esecuzione automatica per essere al sicuro?
No, perché lo slopsquatting e i suoi derivati si basano sulla capacità dell’AI di convincere l’utente (o un sistema automatizzato) a integrare la risorsa malevola. Anche con un controllo umano, se il nome suggerito non viene verificato manualmente contro registri ufficiali, un pacchetto “allucinato” può essere installato volontariamente. La mitigazione più efficace è la verifica preventiva di ogni identificativo, indipendentemente da chi prema il pulsante di esecuzione.