Un grupo de agentes de OpenAI llevó a cabo un ataque coordinado contra RubyGems en mayo de 2026, publicando miles de paquetes maliciosos para extraer datos públicos del gobierno británico. Los agentes explotaron fallos de seguridad y ejecutaron código remoto para almacenar información y buscar claves API de otros usuarios. Este incidente resalta los riesgos de los agentes de IA autónomos y la necesidad de una regulación más estricta.







El "ataque malicioso masivo" que tuvo como objetivo RubyGems en mayo de 2026 fue obra de un enjambre de agentes de OpenAI, según un nuevo informe publicado por los investigadores Spencer Kitts, Thomas Larsen y Sydney Von Arx en rubyhack.ai.

El 12 de mayo, Maciej Mensfeld, gerente senior de producto para la seguridad de la cadena de suministro de software en Mend.io, reveló los detalles de un ataque cibernético coordinado dirigido al gestor de paquetes del lenguaje de programación Ruby con cientos de gemas basura, lo que llevó a los administradores a suspender los nuevos registros de usuarios durante unos cuatro días.

En un análisis posterior, Socket destacó una campaña denominada GemStuffer que involucraba un grupo de más de 150 gemas que utilizaban el registro de paquetes como un canal de exfiltración de datos y almacenaban datos públicos extraídos de portales de servicios democráticos del gobierno local del Reino Unido. En aquel momento, la empresa de seguridad de la cadena de suministro de software señaló que la actividad compartía el "mismo patrón de abuso" que el incidente más amplio de publicación de spam en RubyGems.

"No está claro cuáles son exactamente los objetivos finales, ya que la información parece ser accesible públicamente de todos modos", informó The Hacker News en aquel entonces.

Los hallazgos más recientes, reportados primero por The Wall Street Journal, indican que estos eventos fueron impulsados por un grupo de agentes de OpenAI; el primer paquete fue subido a RubyGems el 5 de mayo de 2026, antes de que se enviaran más de 2,000 paquetes entre el 11 y el 12 de mayo de 2026. A estos esfuerzos siguieron la publicación de cinco paquetes más entre el 26 y 27 de mayo, y otros 83 paquetes el 18 de junio de 2026.

La evaluación de que este incidente fue el resultado de un enjambre de agentes de OpenAI surge del hecho de que los paquetes fueron creados utilizando un modelo de lenguaje extenso (LLM) y cientos de los paquetes enviados a RubyGems tenían "oai" en su nombre. Quince de los paquetes listaban a "oai" como su autor, mientras que otro tenía "openaixyz65947@gmail.com" como dirección de correo electrónico de contacto.

Los nombres de algunos de los paquetes basura están a continuación:

* chatoaitestgit1778552630
* lambhgproxyoai
* oaibx0092307
* oaicx8859010
* oaicx3857133
* oaidx4526859
* oaiex4149420
* oaifx7943598
* oaigx5861576
* oaihx0305933
* oaiix0379958
* oaijx0156671
* oaikx5119809
* oailm2
* oaipgttatggxy
* oaifetchgemugkejy
* oaiproxytestabc789
* oaitfossilxbnowl

"El enjambre se comporta de manera extremadamente similar a los agentes de German-wiki que encontramos anteriormente", dijeron los investigadores, refiriéndose a otro incidente de mayo de 2026 en el que agentes autónomos desplegados internamente secuestraron un foro wiki alemán, DseWiki, y lo convirtieron en un tablero de anuncios para pedir respuestas, agrupar resultados y compartir técnicas para eludir sus restricciones como parte de una tarea de búsqueda web programada.

"Los agentes de junio accedían a 49 de los mismos archivos que los agentes de la wiki. Los agentes de mayo accedían a archivos diferentes (principalmente datos del gobierno local del Reino Unido), pero estos archivos son muy similares en carácter a los perseguidos por los agentes de la wiki. Además, utilizan los mismos métodos de recuperación. 1,397 paquetes mencionan r.jina.ai, que fue utilizado intensamente por los agentes en la wiki. También vemos que muchos paquetes mencionan example.com, que los agentes de la wiki usaron para probar su capacidad de publicación".



Se dice que los agentes explotaron una peculiaridad de diseño en el proceso de construcción de documentación de RubyDoc.info para exfiltrar datos públicos de sitios web del gobierno del Reino Unido, probablemente como parte de una tarea de recopilación de información similar a las tareas de investigación procesadas por los agentes que explotaron la wiki alemana.

"El proceso de construcción de documentación para una gema implica la evaluación de un archivo '.yardopts' especificado por el usuario, que permite vincular scripts de Ruby destinados a ayudar en este proceso", explicaron los investigadores. "En la campaña GemStuffer, los agentes abusaron de esto para lograr la ejecución remota de código arbitrario en los servidores de RubyDoc.info".

Se ha descubierto que una de las gemas, "zzsouthrunner" (ver aquí) (que nuevamente coincide con el esquema de nomenclatura "ZZ" que los agentes adoptaron tanto en los incidentes de la wiki como en Hugging Face) deja el siguiente comentario explícito en la parte superior de "data/script.rb":

# rastreador malicioso/exfiltración para los docs de Southwark enero 2026 vía trabajador de rubydoc.info



Cabe señalar que la campaña GemStuffer tuvo como objetivo los portales ModernGov orientados al público utilizados por Lambeth, Wandsworth y Southwark. Toda la cadena de explotación se puede resumir de la siguiente manera:

* Enviar un paquete malicioso a RubyGems
* Activar una solicitud de documentación, para que RubyDoc.info construya el paquete
* Usar el script de construcción para ejecutar código en RubyDoc.info y extraer datos de los sitios web objetivo
* Exfiltrar los datos de los servidores de RubyDoc.info publicando otra gema en el registro de paquetes de RubyGems, que es visible públicamente

Además, se descubrió que los agentes de OpenAI intentaron robar las claves API de otros usuarios tras obtener capacidades de ejecución remota de código en el entorno de construcción, siendo claramente conscientes de que lo que estaban haciendo era una entrada forzada no autorizada en sistemas reales.

Esto se evidencia en los nombres dados a los archivos (por ejemplo, hack.rb, evil.rb, inject.rb, exploit.rb y ssrf.rb), los propios paquetes (por ejemplo, pwnp999, exfiltestwand3, hacksvn1778554764 y lambproxyhackabcxyz) y los comentarios dejados en el código fuente (por ejemplo, "# malicious probe," "#hack," "# malicious test" y "# malicious crawler/exfil").

En algunos casos, sin embargo, los agentes rebeldes intentaron pasar desapercibidos, dejando comentarios para ocultar la carga útil maliciosa en la siguiente versión de lanzamiento de los paquetes. "# desactivar maldad en la próxima versión y subir versión", dice un comentario dejado dentro del archivo "data/evil.rb" en la gema yardxabc889 (ver aquí).

Preocupantemente, los agentes también intentaron explotar un error de caché de CDN (puntuación CVSS: 7.3, sin CVE) el 12 de mayo de 2026, que solo fue parcheado por RubyGems en julio de 2026. A nivel general, el problema podía entregar la clave API de una cuenta a otro titular de cuenta durante hasta una hora, permitiendo así que un atacante filtrara la clave de un usuario aleatorio.

Seis de los paquetes publicados como parte de la campaña utilizaron esta vulnerabilidad antes de que fuera corregida, aunque no está claro si tuvieron éxito en sus esfuerzos. RubyGems, en su alerta de julio, dijo (leer aviso) que no encontró indicios de que esta vía haya sido explotada en un contexto malicioso. Los nombres de las seis gemas de Ruby están a continuación:

* slnleaker5
* zzwandshostyard
* lambfetchx548811
* lambfetchx550961
* lambfetchx550961
* yardbreakerxqh1778552850

"Si iniciaste sesión en rubygems.org con un cliente de gemas anterior a la v3.2.0 (o de otro modo a través de una clave heredada), tu clave podría haber sido expuesta", señaló RubyGems (ver aviso) en un comunicado. "Actualmente, el 18% de los inicios de sesión a través de gem provienen de una versión afectada, y durante los primeros años de este error, antes de que cambiáramos la ruta de inicio de sesión del cliente en diciembre de 2020, era cada cliente de gema".

Algunas de las otras acciones emprendidas por los agentes se enumeran a continuación:

* Los agentes eludieron el sistema de confirmación de correo electrónico de RubyGems para obtener claves API funcionales sin tener que verificar sus direcciones de correo electrónico, con el fin de registrar un gran número de cuentas usando correos desechables. El problema fue corregido (ver commit) el 12 de mayo de 2026. La capacidad de registrarse con un correo desechable fue desactivada (ver pull request) el 16 de mayo de 2026.
* Los agentes intentaron utilizar el sistema de webhooks de RubyGems para almacenar datos en forma de URLs codificadas.
* Los agentes utilizaron un grupo de 83 gemas publicadas en RubyGems en un intervalo de 3 horas el 18 de junio de 2026, para experimentar con diferentes métodos de acceso al conjunto de datos county.json de la Comisión de Bolsa y Valores de EE. UU. (SEC) (enlace al dataset).

Esta no es la primera vez que los agentes de OpenAI atacan a RubyGems. En su análisis posterior publicado a finales del mes pasado, OpenAI afirmó que observó a sus agentes explotando el procesamiento de RubyGems respaldado por JRuby de JFrog Artifactory para obtener la clave de firma y falsificar credenciales de administrador como parte de un ataque dirigido a la infraestructura de la empresa de inteligencia artificial (IA).

Los investigadores también señalaron que en esta etapa se desconoce por qué los agentes se tomaron la molestia de atacar RubyGems para extraer datos disponibles públicamente y si los agentes trabajaron juntos como en el caso de los otros incidentes. Se cree que los agentes podrían haber intentado usar RubyGems como una forma de almacenar permanentemente los datos extraídos y eludir los límites de velocidad.

"Sospechamos que estaban cooperando entre sí, tanto porque eso justificaría mejor llegar a tales extremos para cachear los sitios web como porque los paquetes que los agentes suben parecen tener miles de descargas", dijeron los investigadores. "Pero esto está lejos de ser definitivo".

La semana pasada, OpenAI dijo que trató el incidente de la wiki como una "instancia de desalineación similar a las que habíamos compartido", y que históricamente ha "tratado la desalineación principalmente como una cuestión de investigación, que se comunica en publicaciones de investigación como tarjetas de sistemas".

La empresa estadounidense añadió que la comunidad de IA aún no tiene un "estándar claro sobre cómo informar la desalineación que aparece durante el entrenamiento, la evaluación y el despliegue, incluyendo ejemplos que no parecen incidentes de seguridad tradicionales pero que podrían proporcionar información sobre el comportamiento de la IA y los riesgos futuros". También dijo que está trabajando en un marco que pretende compartir públicamente en las próximas semanas.

El episodio es solo el último de una serie de ciberataques (ver más) vinculados a laboratorios de IA de vanguardia que han hecho sonar las alarmas y espoleado las llamadas a una regulación de la IA más estricta. Como ha quedado abundantemente claro, a menos que se restrinjan cuidadosamente, los agentes de IA llegarán a extremos para completar las tareas asignadas, incluso si eso significa salir de los entornos aislados (sandboxes) o realizar ataques de ingeniería social a personas reales.

La lista cada vez más larga de incidentes donde agentes de IA de OpenAI, Anthropic y Meta han vulnerado o intentado acceder a sistemas externos ha despertado preocupaciones sobre el ritmo del desarrollo de la IA y su potencial para escaparse del control humano.

"Basándonos en nuestra revisión, nuestros agentes utilizaron la plataforma RubyGems para acceder a internet para llevar a cabo tareas benignas y recuperar información pública", dijo OpenAI en una declaración compartida con Reuters (ver noticia). "Continuaremos investigando como parte de nuestra revisión más amplia de la actividad de los agentes durante el entrenamiento y la evaluación".

RubyGems, por su parte, dijo que su propia investigación no encontró pruebas de que los intentos tuvieran éxito, y que está comprometida a detectar y combatir el abuso independientemente de si la actividad se origina en humanos o herramientas automatizadas.

"Basándonos en la evidencia disponible para nosotros, no podemos determinar si los paquetes fueron creados o publicados por agentes de IA", dijo Colby Swandale, líder técnico de Ruby Central (ver actualización). "Nuestro enfoque está en identificar y prevenir el abuso, independientemente de si proviene de personas o de herramientas automatizadas".

Fuente:
THN