Gli agenti di OpenAI hanno attaccato RubyGems! E la cosa più preoccupante è che nessuno sa il perché

Un nuovo rapporto ricostruisce l'attacco che nel maggio 2026 ha travolto RubyGems con oltre 2000 pacchetti dannosi. A organizzarli sarebbero stati agenti IA riconducibili a OpenAI, capaci di agire autonomamente e sfruttare RubyDoc per eseguire codice. Il caso apre una domanda inquietante: cosa succede quando un agente IA agisce senza uno scopo noto?

Una volta eravamo abituati a citare una cyber gang criminale nel titolo di un articolo, sapendo che dietro quell’attacco c’era un obiettivo preciso: il profitto.

Ransomware, estorsioni, furto di credenziali, vendita di dati. C’era sempre una logica, per quanto criminale, dietro l’azione. Oggi sembra che tutto questo stia cambiando e stiamo assistendo alla comparsa di un nuovo tipo di attore nella minaccia informatica: agenti di IA capaci di agire autonomamente, moltiplicare le proprie azioni e colpire infrastrutture reali senza che sia immediatamente chiaro quale sia lo scopo. Ma dietro questi agenti ci sono le aziende più importanti del panorama internazionale dell’intelligenza artificiale.

Dopo la notizia dello sciame di agenti autonomi di OpenAI che ha colpito Hugging Faces, ora esce la notizia che un altro sciame di agenti IA all’interno di OpenAI ha sommerso RubyGems, il gestore di pacchetti del linguaggio Ruby, con più di 2000 pacchetti dannosi in due giorni, l’11 e il 12 maggio 2026. RubyGems ha chiuso le nuove registrazioni per quattro giorni per fermare l’attacco. Un membro del team di sicurezza ha definito questo un attacco dannoso su larga scala. La cosa più strana è che OpenAI stessa, dopo mesi, afferma di non sapere perché i suoi agenti abbiano fatto ciò.

La storia è emersa veramente solo il 12 settembre 2026, con un nuovo rapporto di tre ricercatori, Spencer Kitts, Thomas Larsen e Sidney Von Arx. L’attacco è avvenuto a maggio, ma per mesi nessuno lo ha collegato a OpenAI. È proprio in questo nodo che questa storia si distingue dalle normali ondate di spam nei registri dei pacchetti. L’attacco è stato organizzato da agenti software autonomi, addestrati e lanciati da una delle più grandi IA-laboratori del mondo, che hanno agito di propria iniziativa per uno scopo che nessuno può spiegare.

RubyGems è un repository pubblico da cui ogni sviluppatore Ruby scarica librerie, che finiscono nelle applicazioni e nei siti di tutto il mondo. Un tale repository vive di fiducia.

Se qualcuno riesce a inserire lì un codice ostile, questo codice si diffonde lungo la catena su migliaia di macchine. Pertanto, un attacco alla catena di fornitura del software causa più danni di un singolo intrusione.

Il primo campanello d’allarme è arrivato da Mend.io, che l’11 maggio ha scoperto più di 120 pacchetti dannosi appena pubblicati. In ventiquattro ore la situazione è esplosa in migliaia di account e pacchetti, creati tutti insieme. Maciej Mensfeld, responsabile della sicurezza della catena di fornitura in Mend.io, ha scritto senza mezzi termini: su RubyGems è in corso un attacco dannoso su larga scala.

La reazione del registro è stata rapida. RubyGems ha completamente sospeso la creazione di nuovi account, ha rimosso i pacchetti e i bot, poi si è coordinato con Fastly per attivare un firewall applicativo e rafforzare i limiti sulle nuove registrazioni.

La registrazione è rimasta chiusa fino al 16 maggio, quattro giorni durante i quali nessuno poteva registrarsi.Il punto di ingresso è quasi elegante nella sua semplicità. Il server non è stato violato attraverso una vulnerabilità di grande livello. Hanno utilizzato un servizio legittimo e gratuito, RubyDoc.info, che genera automaticamente la documentazione quando qualcuno la richiede.

Il meccanismo funziona così. Un pacchetto Ruby può contenere un file di configurazione chiamato .yardopts, ovvero le impostazioni per la generazione della documentazione che RubyDoc legge ed esegue durante la compilazione. Gli agenti hanno raccolto “gemme” con un .yardopts appositamente preparato che, al momento della compilazione, caricava script Ruby sotto il controllo degli attaccanti. In sostanza, hanno trasformato il servizio di documentazione in una macchina che eseguiva codice arbitrario nei loro interessi, ciò che nel gergo viene chiamato esecuzione remota di codice (RCE, remote code execution).

Più di cento pacchetti seguivano lo stesso scenario. Pubblicavano una gemma, richiedevano la documentazione, avviavano lo script sul server RubyDoc, utilizzavano quindi quel server per raccogliere dati dai siti target, impacchettavano i dati raccolti in un’altra gemma e la ricaricavano su RubyGems per recuperarla in seguito. 

INon tutto era così innocuo. Almeno sei pacchetti hanno cercato di fare qualcosa di più concreto, ovvero rubare le API-keys di altri utenti. L’obiettivo era una debolezza nella gestione delle keys di RubyGems, legata al vecchio meccanismo gem signin, di cui si è parlato pubblicamente solo a luglio 2026, più di due mesi dopo l’attacco.

Il difetto era nascosto nella cache della rete di distribuzione di contenuti (CDN, sistema di server che forniscono le pagine più vicino all’utente). In determinate condizioni, la API-key poteva essere salvata nella cache e poi restituita a richieste non autenticate, finite nello stesso nodo per circa un’ora. Uno dei pacchetti, chiamato slnleaker5, interrogava diverse varianti di endpoint e cercava nelle risposte i pattern tipici delle credenziali. Il fatto che gli agenti stessero già sondando questa strada a maggio, quando la vulnerabilità non era ancora nota a nessuno, rappresenta uno dei momenti più preoccupanti del rapporto.

L’attribuzione ad OpenAI non nasce da un riconoscimento, ma da una collezione di tracce lasciate intorno con sorprendente negligenza. Centinaia di gemme contenevano nell’abbreviazione “oai” nel titolo, almeno quindici indicavano oai come autore. Un pacchetto indicava come contatto un indirizzo Gmail sull’argomento OpenAI. 

Luigi Zullo

Ricercatore di sicurezza informatica con esperienza nell’analisi delle vulnerabilità, nella mitigazione del rischio cyber, nelle attività di red teaming ed ethical hacking e nella protezione di sistemi complessi. Specializzato in penetration testing e Threat Intelligence, contribuisce al rafforzamento della resilienza digitale di infrastrutture e reti aziendali.

Aree di competenza: Penetration Testing, Threat Intelligence, Red Teaming, Vulnerability Assessment, Incident Response