← Torna al blog
Newscirca 6 min di lettura

Quando il tuo assistente di coding inventa un pacchetto, gli aggressori lo registrano per primi

Pubblicato 3 ott 2026
Quando il tuo assistente di coding inventa un pacchetto, gli aggressori lo registrano per primi

Chiedi a un assistente di coding AI di sistemare gli import e potrebbe restituirti il nome di un pacchetto che non esiste. Il nome sembrerà plausibile. Combinerà due strumenti reali, oppure seguirà una convenzione di denominazione che riconosci. Incolli il comando di installazione e, se qualcuno ha già registrato quel nome, hai appena installato qualunque cosa abbia pubblicato.

I ricercatori di sicurezza chiamano questo slopsquatting. È un parente del typosquatting, con la differenza che l'aggressore non ha bisogno che tu scriva male qualcosa. Gli basta sapere cosa tende a inventare il modello, e poi essere il primo a rivendicarlo.

La scala non è aneddotica

Uno studio USENIX Security del 2025 ha testato 16 modelli di generazione di codice su 576.000 campioni di codice in Python e JavaScript. Ha rilevato più di 205.000 nomi di pacchetti unici che non esistevano su nessun registry. Il tasso di allucinazione era almeno del 5,2% per i modelli commerciali e del 21,7% per quelli open source. Un seguito del 2026 ha testato cinque modelli frontier più recenti e ha misurato tassi compresi tra il 4,62% e il 6,10%, inferiori ma comunque presenti in ogni modello testato.

La parte che trasforma una stranezza in una superficie d'attacco è la ripetibilità. Quando i ricercatori hanno rieseguito prompt identici, gran parte dei nomi allucinati è ricomparsa ogni volta. I modelli non tirano a indovinare a caso; convergono sulle stesse risposte sbagliate perché hanno appreso gli stessi schemi dagli stessi dati di addestramento. Questa prevedibilità è la vulnerabilità. Un aggressore può eseguire gli stessi prompt, raccogliere i nomi che si ripetono e registrarli prima di chiunque altro.

Lo studio del 2026 ha identificato 127 nomi di pacchetti che tutti e cinque i modelli testati hanno prodotto pur non esistendo, con 53 ancora disponibili per la registrazione dopo l'applicazione delle protezioni dei registry.

Pacchetti reali, installazioni reali

È già successo. All'inizio del 2026, i ricercatori hanno trovato un pacchetto chiamato react-codeshift citato in 237 repository GitHub. Il nome fonde due strumenti reali, jscodeshift e react-codemod. Non era mai stato pubblicato. Una skill generata dall'AI contenente il pacchetto fittizio era stata copiata e forkata, lasciando che il riferimento si diffondesse da solo.

Un pacchetto chiamato metro-evaluator su npm conteneva codice malevolo in quattro versioni pubblicate a dicembre 2025, prima di essere rimosso cinque giorni dopo e sostituito con un segnaposto di sicurezza. I modelli testati avevano suggerito quel nome dieci volte. Un altro, unused-imports, imitava il reale eslint-plugin-unused-imports e continuava a raccogliere installazioni da sviluppatori che il loro assistente indirizzava lì.

L'operazione più ampia è una campagna che la società di sicurezza Koi Security chiama PhantomRaven, attiva almeno da agosto 2025. Koi le attribuisce 126 pacchetti npm malevoli e più di 86.000 download. Il trucco qui è diverso da un nome allucinato. Il package.json sembra pulito, a volte contiene poco più di una riga di log, ma punta a una dipendenza ospitata su un semplice URL HTTP anziché a un altro pacchetto npm. La maggior parte degli scanner non segue gli URL grezzi, quindi il payload che raccoglie token npm, credenziali GitHub e segreti CI si carica in modo invisibile al momento dell'installazione. Endor Labs ha documentato altre tre ondate della stessa campagna tra novembre 2025 e febbraio 2026, aggiungendo altri 88 pacchetti caricati tramite circa 50 account usa e getta.

I registry hanno bloccato la maggior parte dei nomi, non tutti

C'è una buona notizia nella ricerca. I registry dei pacchetti sono diventati più bravi a bloccare i nomi che i modelli tendono a inventare. Normalizzano nomi simili, mantengono liste di divieto e monitorano gli schemi che emergono in molti campioni generati. Quando lo studio del 2026 ha verificato la sua lista di 127 nomi allucinati condivisi, la maggior parte era già stata rivendicata o bloccata da progetti legittimi e dalle difese dei registry.

Il problema è che "la maggior parte" non significa "tutti". Lo stesso studio ha trovato 53 nomi ancora disponibili per la registrazione dopo l'applicazione delle protezioni. Un solo nome registrabile su cui diversi modelli frontier concordano basta per costruirci un attacco, perché l'aggressore deve solo indovinare il modello, non lo sviluppatore. I gestori dei registry hanno chiuso quasi del tutto la porta; la fessura rimasta è stretta ma aperta.

Lo stesso schema si è ora diffuso oltre i package manager. I ricercatori di sicurezza hanno documentato aggressori che registrano domini allucinati dai modelli, e repository e skill che gli agenti sono propensi a inventare. Il meccanismo è identico in ogni caso: un modello prevede un nome plausibile e un sistema costruito per fidarsi di quella previsione agisce di conseguenza. Ogni nuova superficie che un agente può raggiungere diventa un altro luogo dove piantare un nome che l'agente andrà a prendere.

Perché gli agenti peggiorano la situazione

Uno sviluppatore umano potrebbe notare un nome di pacchetto sospetto. Un agente no. Gli agenti installano dipendenze in autonomia, spesso senza che un umano legga prima il comando. I ricercatori hanno dimostrato tecniche di prompt injection che inducono gli agenti a richiedere nomi di pacchetti controllati dall'aggressore, con tassi di successo dichiarati fino al 100% su strumenti tra cui Cursor, Windsurf e GitHub Copilot.

È questa combinazione ad aver cambiato il profilo di rischio. L'allucinazione fornisce il nome. L'agente fornisce l'esecuzione. L'aggressore deve solo aspettare che i due si incontrino.

Il problema delle fughe di dati è lo stesso problema

Un rapporto correlato dell'azienda Glow ha rilevato agenti che espongono più di 13.000 immagini interne su GitHub, provenienti da oltre 300 organizzazioni. Il meccanismo è banale: gli agenti e i loro utenti inseriscono screenshot, diagrammi e documenti in repository pubblici, a volte senza capire che "pubblico" significa ricercabile e permanente. Gli stessi strumenti che rendono gli sviluppatori più veloci rendono anche più facile spostare materiale interno dove non dovrebbe finire.

Entrambi i problemi condividono una causa comune. Gli agenti agiscono alla velocità della macchina su istruzioni che possono essere sbagliate (un nome allucinato) o sensibili (uno screenshot interno). Il punto di controllo umano che prima si trovava tra l'intento e l'azione è esattamente ciò che l'agente elimina.

Cosa fare davvero

Le difese non sono complicate, il che è una buona notizia vista la rapidità con cui la minaccia si è mossa.

Tratta ogni comando di installazione prodotto da un agente come input non attendibile. Verifica che il pacchetto esista prima di installarlo. Controlla da quanto tempo esiste; un nome allucinato che è stato registrato sarà recente. Verifica che l'autore abbia uno storico. Per npm e PyPI, una rapida ricerca dei metadati risponde a tutte e tre le domande in pochi secondi.

Un singolo pacco sigillato e vuoto, appoggiato su un pavimento scuro e riflettente, circondato da pacchi identici che svaniscono nell'ombra

Richiedi l'approvazione umana prima che un agente aggiunga una dipendenza. È il cambiamento con il valore più alto, perché intercetta in una volta sola i nomi allucinati, le registrazioni malevole e le richieste di prompt injection. Rallenta un po' l'agente e chiude il buco più grande.

Mantieni limitata la portata dell'agente. Un agente di coding ha bisogno dell'accesso al repository; raramente ha bisogno di credenziali di produzione, e non dovrebbe avere un package manager puntato su un registry privato senza un controllo. Strumenti come Socket e Snyk possono automatizzare la verifica nel registry all'interno dell'IDE o della pipeline CI, cosa che vale il costo quando un team usa agenti su molti repository.

La parte scomoda è che nulla di tutto questo è un bug che si risolve con una patch. L'allucinazione è insita nel modo in cui questi modelli prevedono il testo: generano il prossimo nome plausibile, non uno verificato. La soluzione deve risiedere nel flusso di lavoro attorno al modello, ed è un processo che la maggior parte dei team può avviare questa settimana.

Articoli correlati