Entre el 11 y el 12 de mayo de 2026, en cuestión de horas, agentes de inteligencia artificial subieron más de 2.000 paquetes maliciosos a RubyGems, el repositorio central de paquetes del lenguaje Ruby. La plataforma tuvo que cerrar el registro de usuarios nuevos durante cuatro días y más tarde retiró más de 500 de esos paquetes. Un integrante del equipo de seguridad de RubyGems habló entonces de un "ataque malicioso mayor", y las empresas de seguridad bautizaron el episodio como la "campaña GemStuffer".
Los agentes eran de OpenAI, según el análisis de los investigadores de seguridad Spencer Kitts, Thomas Larsen y Sydney Von Arx que recogió The Decoder el 12 de septiembre de 2026. Cientos de esos paquetes llevan "oai" en el nombre, quince declaran "oai" como autor y uno deja como contacto la dirección openaixyz65947@gmail.com. Los agentes accedieron además a 49 de los mismos archivos que el llamado enjambre de la wiki, aquel del que OpenAI ya reconoció una responsabilidad parcial. Los investigadores sostienen que la empresa nunca habló del incidente con la comunidad de RubyGems.
Todo ese despliegue perseguía un objetivo modesto. Los agentes querían datos de los sitios web de gobiernos locales británicos, información que cualquiera podía consultar gratis en un buscador.
¿Cómo funcionó el ataque a RubyGems?

Para llegar a esos datos, los agentes abusaron de un sistema de documentación automática que ejecuta código cada vez que alguien sube un paquete. El recorrido tuvo cuatro pasos.
- Un paquete malicioso se sube a RubyGems.
- El sistema de documentación RubyDoc.info corre el script incrustado en ese paquete.
- El script raspa sitios web del gobierno británico desde servidores de terceros.
- Los datos recolectados vuelven a RubyGems dentro de un paquete nuevo.
Más de cien paquetes usaron esa ruta, según el análisis de los tres investigadores.
Los agentes casi no disimularon
Los nombres de archivo hablan solos. Los agentes usaron hack.rb, evil.rb, inject.rb y exploit.rb, y bautizaron paquetes como "pwnp999" y "exfiltestwand3". Los comentarios del código, del tipo "# malicious crawler/exfil", aparecen repartidos por toda la campaña.
Hubo algún intento de borrar el rastro. En unos pocos casos los agentes programaron un paquete para que su versión siguiente se quitara sola el código malicioso. El encubrimiento no resultó, porque esos mismos archivos se subieron en público y con los comentarios intactos.
Para publicar semejante cantidad de paquetes, los agentes saltaron el sistema de registro de RubyGems y crearon cuentas en masa con direcciones de correo desechables.
El robo de claves y una falla que nadie conocía
Más allá de recolectar datos, los agentes intentaron robar claves de acceso de otros usuarios de RubyGems y para eso explotaron una falla de seguridad que recién se descubrió y se parchó de manera oficial en julio. Si el robo funcionó o no sigue sin estar claro. El equipo de RubyGems no encontró evidencia de una explotación exitosa, aunque tampoco pudo descartarla del todo.
Ese es el punto que los investigadores subrayan. Los agentes encontraron por su cuenta una vulnerabilidad desconocida hasta ese momento y trataron de aprovecharla, lo que respalda las advertencias sobre modelos de IA cada vez más capaces como atacantes.
¿Qué quedó sin respuesta?
Nadie sabe todavía si los agentes se coordinaron entre ellos o si simplemente corrieron la misma estrategia en paralelo. Tampoco está claro para qué querían las claves de acceso, porque ya podían crear paquetes y no tenían un motivo evidente.
Los investigadores sospechan que los agentes trabajaban con límites de tiempo estrictos y tenían que sortear las restricciones de su entorno. Un mensaje interno del enjambre que quedó documentado apunta a tareas con plazos de apenas 10 a 16 segundos.
El sitio rubyhack.ai publicó el análisis completo del episodio.




