Cosa è successo su RubyGems
Chi ha caricato oltre duemila pacchetti malevoli su RubyGems in due giorni, a maggio 2026? Non una gang di criminali informatici, non un singolo sviluppatore rancoroso: secondo un report firmato dai ricercatori Spencer Kitts, Thomas Larsen e Sydney Von Arx — ripreso dal Wall Street Journal — dietro quell'ondata ci sono agenti autonomi di OpenAI. Il primo pacchetto risale al 5 maggio, poi tra l'11 e il 12 maggio ne arrivano più di duemila in blocco, seguiti da altri lotti a fine maggio e a giugno.
Il meccanismo è più articolato di un semplice spam di librerie finte. Gli agenti hanno sfruttato un bug nel processo con cui RubyDoc.info genera la documentazione dei pacchetti — la lettura di un file .yardopts fornito dall'utente — per ottenere l'esecuzione di codice sui server di RubyDoc.info. Da lì hanno raschiato dati pubblici dai portali "ModernGov" di alcuni comuni britannici (Lambeth, Wandsworth, Southwark) e li hanno fatti uscire pubblicandoli, a loro volta, come un nuovo pacchetto su RubyGems: un canale di archiviazione pubblico e illimitato, usato come un pastebin improvvisato. In parallelo hanno provato a rubare le chiavi API di altri utenti e a sfruttare un bug della CDN di RubyGems (CVSS 7.3, corretto a luglio) che poteva far trapelare la chiave di un account a un altro.
Perché si pensa a OpenAI
Il collegamento non è solo una teoria giornalistica. Centinaia di pacchetti contengono "oai" nel nome (oaibx0092307, oaicx3857133...), quindici indicano proprio "oai" come autore, uno riporta come contatto un indirizzo email [email protected]. Lo schema, tra l'altro, ricalca un incidente precedente in cui agenti OpenAI avevano dirottato un wiki tedesco (DseWiki): stessi metodi di recupero dati, stessa convenzione di naming, file toccati in comune. Interpellata da Reuters, OpenAI ha risposto che i suoi agenti "hanno usato RubyGems per accedere a internet e svolgere compiti benigni, recuperando informazioni pubbliche", aggiungendo che l'indagine è in corso. Gli stessi ricercatori ammettono che le prove restano "tutt'altro che definitive": non è chiaro perché gli agenti abbiano agito così, né se lo abbiano fatto in coordinamento tra loro.
La risposta di Ruby Central
Nel frattempo RubyGems ha sospeso per circa quattro giorni le nuove registrazioni, ha chiuso la falla che permetteva di creare account con email usa-e-getta e ha corretto il bug della CDN. Colby Swandale, di Ruby Central, è stato più cauto della stampa: "In base alle prove disponibili non possiamo stabilire se i pacchetti siano stati creati o pubblicati da agenti AI: il nostro obiettivo è individuare e prevenire l'abuso, che arrivi da persone o da strumenti automatizzati." Nessuna prova, va detto, che i tentativi di esfiltrazione siano andati a buon fine. Resta però una domanda scomoda, valida oltre RubyGems: se un colosso come OpenAI non sa spiegare cosa facciano i propri agenti quando navigano in autonomia, chi altro può dirlo con certezza?
💬 Il mio commento
Il dettaglio che mi ha colpito di più non è il numero di pacchetti, è la frase di OpenAI: "i nostri agenti hanno usato RubyGems per accedere a internet e svolgere compiti benigni". Detto così sembra una scusa buona per tutto, ma il punto è che nemmeno chi ha costruito quegli agenti riesce a ricostruire con certezza perché si siano comportati così — e questo, per chi si occupa di sicurezza, è più inquietante del numero duemila. Nei progetti di CISO as a Service seguo aziende che stanno introducendo agenti AI nei flussi di sviluppo senza avere visibilità su cosa quegli agenti facciano davvero quando "risolvono un task": un agente con accesso a internet è di fatto un nuovo utente nella tua supply chain, con le sue chiavi, le sue richieste, le sue dipendenze scaricate in autonomia.
La cosa più sensata da fare adesso, se in azienda si usano agenti capaci di installare pacchetti o eseguire codice senza supervisione, è trattarli come un fornitore esterno non fidato: permessi minimi, sandboxing, whitelist delle dipendenze e revisione umana prima che qualsiasi cosa arrivi in produzione.