La prossima volta che un assistente IA ti consiglia di installare un pacchetto, verificherai se esiste davvero? La maggior parte degli sviluppatori non lo fa. È proprio in questo divario tra suggerimento e verifica che iniziano gli attacchi di slopsquatting e, in meno di tre anni, la minaccia si è evoluta da una semplice dimostrazione di fattibilità a livello di ricerca all'esecuzione remota di codice all'interno di agenti di programmazione autonomi. Questo articolo ripercorre l'evoluzione dello slopsquatting e analizza il significato di ogni fase per i team di sicurezza delle applicazioni e di DevSecOps.
Sei nuovo qui? Inizia con la nostra guida introduttiva su Cos'è lo slopsquatting e come difendersi da esso, poi torna per la cronologia.
Un attacco di slopsquatting in un paragrafo
Un attacco di slopsquatting registra un pacchetto dannoso con un nome che i modelli di intelligenza artificiale, prevedibilmente, interpretano in modo errato. Dove il typosquatting sfrutta un errore di digitazione umano richieste per richiesteLo slopsquatting sfrutta il modello stesso, inventando un nome plausibile che non esiste in alcun registro, e poi un attaccante rivendica esattamente quel nome prima che lo faccia chiunque altro di legittimo. Il termine è stato coniato da Seth Larson, Security Developer-in-Residence presso la Python Software Foundation, e reso popolare da Andrew Nesbitt. Ciò che rende questo schema degno di essere monitorato è la rapidità con cui si è evoluto.
Evoluzione dello squapsquatting
2023: il primo segnale d'allarme
Il ricercatore di sicurezza Bar Lanyado ha notato che diversi LLM continuavano a raccomandare un pacchetto chiamato abbracciandoface-cli, che non esiste (lo strumento reale si installa con pip install -U “huggingface_hub[cli]”Per dimostrare il rischio, caricò un pacchetto vuoto con quel nome inventato. Nel giro di tre mesi era stato scaricato più di 30,000 volte, senza alcuna promozione, e il nome falso era persino apparso nel file README di un repository collegato a una ricerca di una grande azienda tecnologica. Il pacchetto era innocuo. La lezione, però, non lo era: un nome inventato deve essere solo sufficientemente coerente perché qualcuno possa usarlo come arma.
2024: dal post sul blog alla copertura mediatica mainstream
Nel marzo 2024, The Register ha riportato la notizia di modelli di intelligenza artificiale in grado di inventare con sicurezza nomi di pacchetti software che gli sviluppatori scaricavano, alcuni potenzialmente infetti da malware. L'articolo era importante meno per ciò che rivelava a livello tecnico che per il messaggio che trasmetteva: abbracciandoface-cli Non si trattava più di una curiosità isolata, ma del primo segnale di un fenomeno abbastanza serio da essere segnalato dalla stampa tecnologica generalista, prima ancora dello studio su larga scala che ne avrebbe confermato la portata un anno dopo.
2025: la prima misurazione rigorosa
Il documento USENIX Security 2025 "We Have a Package for You!" (Spracklen et al.) ha testato 16 modelli di generazione di codice, commerciali e open source, su 576,000 esempi di Python e JavaScript. Ha trasformato il concetto di "slopsquatting" da aneddoto a dati concreti:
- Il 19.7% dei pacchetti consigliati non esisteva.
- I modelli open-source hanno avuto allucinazioni molto più frequentemente (21.7% in media) rispetto a quelli commerciali (5.2%).
- I peggiori trasgressori, CodeLlama 7B e 34B, hanno avuto allucinazioni in oltre un terzo delle loro produzioni.
- Considerando tutti i modelli, i ricercatori hanno registrato oltre 205,000 nomi allucinati unici, un insieme sufficientemente ampio da alimentare campagne prolungate in diversi ecosistemi.
Lo studio ha anche categorizzato come si formano i falsi: il 38% erano fusioni che uniscono due nomi di confezioni reali (esattamente lo schema che in seguito ha prodotto React Codeshift da jscodeshift and react-codemodIl 13% erano varianti tipografiche di confezioni reali e il 51% erano pure invenzioni, plausibili ma del tutto inventate. Il primo gruppo è il più importante ai fini della difesa, perché un nome composto da due elementi reali è il più difficile da individuare a colpo d'occhio.
La scoperta più importante per gli aggressori è che le allucinazioni non sono casuali e non cambiano a ogni tentativo. Quando i ricercatori hanno ripetuto gli stessi stimoli dieci volte ciascuno, il 43% dei nomi allucinati è apparso in ogni singola esecuzione e il 58% si è ripetuto più di una volta. Un aggressore non ha bisogno di tirare a indovinare. Osserva il comportamento del modello, annota i nomi che si ripetono e li registra per primi. Questa ripetibilità è ciò che trasforma un'allucinazione occasionale in un attacco scalabile.
2026: dai pacchetti isolati agli agenti autonomi
Quest'anno ha prodotto la prova più chiara finora che lo slopsquatting non è più limitato a uno sviluppatore che copia e incolla un suggerimento installazione di npm.
Nel gennaio 2026, il ricercatore di sicurezza Charlie Eriksen ha trovato un pacchetto npm allucinatorio, React Codeshift, che le istruzioni dell'agente generate dall'IA si erano già diffuse in 237 repository tramite fork, con agenti che tentavano ancora di installarle quotidianamente. Ha avuto origine in un singolo commit di file di abilità dell'agente scritti dall'IA che nessun essere umano aveva revisionato. Eriksen registrò il nome personalmente, a scopo difensivo, prima che un attaccante potesse usarlo come arma.
Separatamente, un pacchetto veramente dannoso chiamato importazioni inutilizzate, allucinato al posto del legittimo eslint-plugin-unused-imports, ha continuato a generare installazioni anche dopo che npm lo ha bloccato per motivi di sicurezza, dimostrando per quanto tempo un attacco di slopsquatting può continuare a trovare vittime dopo essere stato segnalato.
Successivamente, nel luglio 2026, i ricercatori hanno descritto una tecnica correlata, denominata "HalluSquatting", che collega un'allucinazione a un'iniezione di prompt: un agente di programmazione IA che recupera una risorsa allucinata per conto di un utente può essere dirottato per eseguire codice fornito dall'attaccante. Ciò estende l'evoluzione dello slopsquatting da un rischio di installazione passivo a un vettore attivo di esecuzione di codice remoto all'interno dei flussi di lavoro di sviluppo agentivo.
Perché il “vibe coding” ha ampliato la superficie di attacco
Il problema dello "slopsquatting" non sarebbe così rilevante se il codice generato dall'IA fosse una nicchia. Ma non lo è. L'ascesa degli assistenti di programmazione, degli agenti autonomi e dei flussi di lavoro di "vibe coding", in cui gli sviluppatori rivedono meno codice prima di eseguirlo, ha modificato la superficie di attacco in due modi concreti.
Innanzitutto, il punto di ingresso non è più solo lo sviluppatore. Un attacco di typosquatting si basava su un singolo errore di battitura. Ora l'errore ha origine all'interno del modello e si propaga a centinaia di sviluppatori che pongono domande simili e ricevono la stessa raccomandazione errata.
In secondo luogo, la superficie di attacco si è spostata verso l'alto nella catena. Non è più sufficiente monitorare il codice scritto da un essere umano. I team devono monitorare le dipendenze suggerite da un assistente IA, i server MCP a cui si connette e gli agenti che installano i pacchetti senza alcun intervento umano. La sicurezza delle applicazioni tradizionale, progettata per esaminare i repository e l'intervento umano commits non è mai stato progettato per osservare quell'interazione tra sviluppatore, IA e registro, che è esattamente dove ora si nasconde lo slopsquatting.
Cosa significa questo per la prevenzione
Niente di tutto ciò rende l'IA generativa intrinsecamente insicura. Introduce un rischio nella catena di fornitura che gli strumenti tradizionali non sono stati progettati per rilevare e richiede i principi di verifica che già applichiamo a qualsiasi dipendenza esterna: non fidarsi per impostazione predefinita, verificare la fonte e automatizzare tale verifica invece di fare affidamento sulla memoria di ogni sviluppatore. Il playbook difensivo completo è nella nostra guida a Sicurezza della catena di approvvigionamento basata sull'intelligenza artificialeMa in breve, la verifica manuale, pur rimanendo necessaria, smette di essere efficace nel momento in cui un nome inventato può raggiungere migliaia di sviluppatori contemporaneamente, o un agente può installarlo senza alcuna revisione umana.
Ferma i pacchetti allucinanti prima che un agente li installi.
I casi del 2026 hanno una caratteristica in comune: l'installazione pericolosa avviene senza l'intervento umano. Questa è esattamente la lacuna Xygeni Shield è costruito per. Shield è un agente leggero sull'endpoint dello sviluppatore che blocca i pacchetti dannosi al momento dell'installazione, utilizzando Allerta precoce sul malware (MEW) verdetti che funzionano prima che esista una firma. Quando un assistente IA o un agente autonomo tenta di installare un pacchetto appena registrato e inesistente, Shield lo valuta quando viene recuperato e lo blocca, quindi lo script di installazione non viene mai eseguito, indipendentemente dal fatto che un essere umano lo stesse guardando o meno. Ogni blocco confluisce nello stesso Xygeni console come risultati del codice, della compilazione e dell'esecuzione, e Shield Funziona in parallelo con il tuo sistema EDR esistente, anziché in contrasto con esso.
Inizia gratuitamente. Il piano Developer di Xygeni è €0: 10 repository, 200 scansioni al mese, fino a 5 collaboratori, nessuna carta di credito richiesta. Sign up with GitHub, GitLab o Google ed esegui la tua prima scansione in meno di 10 minuti; Shield La protezione degli endpoint sarà presto disponibile nel piano Developer.
FAQ
Un gestore di pacchetti può impedire autonomamente lo slopsquatting?
Non del tutto. Il sistema di rilevamento delle collisioni di npm blocca i nomi troppo simili a pacchetti esistenti, il che aiuta a contrastare il typosquatting, ma un nome inventato è una stringa completamente nuova senza collisioni da rilevare. Se un malintenzionato registra il pacchetto inventato prima che uno sviluppatore lo installi, l'installazione si completa senza errori perché il pacchetto esiste realmente. La prevenzione richiede la verifica dell'origine e del comportamento del pacchetto, non solo i controlli del registro stesso.
Cosa distingue i casi di occupazione abusiva di terreni del 2026 dai precedenti casi di slopsquatting?
In passato, gli incidenti si basavano sul semplice copia-incolla da parte di un essere umano di un comando di installazione suggerito. Nei casi del 2026, agenti autonomi installavano o tentavano di installare pacchetti inesistenti senza alcuna revisione umana, e la tecnica HalluSquatting si è spinta oltre, combinando un'allucinazione con l'iniezione di un prompt per ottenere l'esecuzione di codice remoto all'interno del flusso di lavoro dell'agente.
