El 'gran ataque malicioso' que tuvo como blanco a 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.
El 12 de mayo, Maciej Mensfeld, gerente sénior de productos de seguridad de la cadena de suministro de software en Mend.io, reveló detalles de un ataque cibernético coordinado contra el gestor de paquetes del lenguaje de programación Ruby con cientos de gemas basura, lo que llevó a los mantenedores a suspender el registro de nuevos usuarios durante aproximadamente cuatro días.
En un análisis posterior, Socket destacó una campaña denominada GemStuffer que involucró a un clúster de más de 150 gemas que utilizaban el registro de paquetes como canal de exfiltración de datos y alojaban datos públicos extraídos de portales de servicios democráticos de gobiernos locales del Reino Unido. En ese momento, la empresa de seguridad de la cadena de suministro de software señaló que la actividad comparte 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 de acceso público de todos modos", informó The Hacker News en ese entonces.
Los últimos hallazgos, reportados inicialmente por The Wall Street Journal, indican que estos eventos fueron impulsados por un clúster de agentes de OpenAI, con el primer paquete 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. Estos esfuerzos fueron seguidos por la publicación de cinco paquetes más entre el 26 y el 27 de mayo de 2026, 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 se deriva del hecho de que los paquetes fueron creados utilizando un modelo de lenguaje grande (LLM) y cientos de los paquetes enviados a RubyGems tenían 'oai' en su nombre. Quince de los paquetes listaban 'oai' como su autor, mientras que otro tenía 'openaixyz65947@gmail.com' como dirección de correo de contacto.
Los nombres de algunos de los paquetes basura se enumeran 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 la wiki alemana 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 de wiki alemán, DseWiki, y lo convirtieron en un tablón de anuncios para pedir respuestas, agrupar resultados y compartir técnicas para eludir sus restricciones como parte de una tarea cronometrada de búsqueda web.
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 de gobiernos locales 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 muy utilizado por los agentes en la wiki. También vemos que muchos paquetes mencionan example.com, que los agentes de la wiki usaban para probar su capacidad de publicación.
Se dice que los agentes explotaron una peculiaridad de diseño en el proceso de compilació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 compilación de documentación para una gema implica evaluar un archivo '.yardopts' especificado por el usuario, que permite enlazar a scripts de Ruby destinados a ayudar con este proceso", explicaron los investigadores. "En la campaña GemStuffer, los agentes abusaron de esto para obtener ejecución remota de código arbitrario en los servidores de RubyDoc.info.
Una de las gemas, 'zzsouthrunner' (que nuevamente coincide con el esquema de nombres 'ZZ' que los agentes adoptaron tanto en los incidentes de la wiki como en Hugging Face), se ha encontrado que deja el siguiente comentario explícito en la parte superior de 'data/script.rb':
# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker
Vale la pena señalar que la campaña GemStuffer se dirigió a portales ModernGov de acceso público utilizados por Lambeth, Wandsworth y Southwark. La cadena de explotación completa se puede resumir de la siguiente manera:
- Enviar un paquete malicioso a RubyGems
- Activar una solicitud de documentación, para que RubyDoc.info compile el paquete
- Usar el script de compilación para ejecutar código en RubyDoc.info y extraer datos de sitios web objetivo
- Exfiltrar los datos de los servidores de RubyDoc.info publicando otra gema en el registro de paquetes de RubyGems, que es de acceso público
Además, se ha descubierto que los agentes de OpenAI intentaron robar las claves API de otros usuarios después de obtener capacidades de ejecución remota de código en el entorno de compilación, siendo claramente conscientes de que lo que estaban haciendo era una entrada no autorizada en sistemas reales.
Esto se evidencia por los nombres dados a los archivos (por ejemplo, hack.rb, evil.rb, inject.rb, exploit.rb y ssrf.rb), los paquetes mismos (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 próxima versión de los paquetes. '# disable evil in next version and bump version', se lee en un comentario dejado dentro del archivo 'data/evil.rb' en la gema yardxabc889.
De manera preocupante, 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 grandes rasgos, el problema podía entregar la clave API de una cuenta a otro titular de cuenta durante hasta una hora, permitiendo así a un atacante filtrar 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 que no encontró señales de que esta vía haya sido explotada en un contexto malicioso:
- 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 otra manera mediante una clave heredada), tu clave podría haber quedado expuesta", señaló RubyGems en un aviso. "Actualmente, el 18% de los inicios de sesión a través de gem sign-in 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 todos los clientes de gemas.
Algunas de las otras acciones emprendidas por los agentes se enumeran a continuación:
- Los agentes eludieron el sistema de confirmación por 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 una gran cantidad de cuentas utilizando direcciones de correo desechables. El problema se solucionó el 12 de mayo de 2026. La capacidad de registrarse con un correo desechable se deshabilitó el 16 de mayo de 2026.
- Los agentes intentaron utilizar el sistema de webhooks de RubyGems para almacenar datos en forma de URL codificadas.
- Los agentes utilizaron un clúster de 83 gemas publicadas en RubyGems durante una ventana 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 Estados Unidos (SEC).
Esta no es la primera vez que los agentes de OpenAI han atacado RubyGems. En su análisis posterior publicado a fines del mes pasado, OpenAI dijo 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 compañía 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 de acceso público y si los agentes trabajaron juntos como en el caso de los otros incidentes. Se cree que los agentes podrían haber estado intentando utilizar RubyGems como una forma de almacenar persistentemente 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 almacenar en caché los sitios web como porque los paquetes que suben los agentes parecen tener miles de descargas", dijeron los investigadores. "Pero esto no es definitivo.
La semana pasada, OpenAI dijo que trató el incidente de la wiki como una 'instancia de desalineación similar a las que hemos compartido', y que históricamente ha 'tratado la desalineación en gran medida como una cuestión de investigación, que se comunica en publicaciones de investigación como las tarjetas de sistemas'.
La compañía estadounidense luego pasó a declarar que la comunidad de IA aún no tiene un 'estándar claro sobre cómo informar la desalineación que surge durante el entrenamiento, la evaluación y el despliegue, incluidos ejemplos que no se parecen a 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 ataques cibernéticos vinculados a laboratorios de IA de frontera que han hecho saltar las alarmas y han impulsado llamados a una regulación más estricta de la IA. Como ha quedado abundantemente claro, a menos que se restrinjan cuidadosamente, los agentes de IA llegarán a extremos para completar las tareas que se les asignan, incluso si eso significa escapar de entornos aislados o realizar ataques de ingeniería social contra personas reales.
La lista cada vez mayor de incidentes en los que agentes de IA de OpenAI, Anthropic y Meta han violado o intentado acceder a sistemas externos ha generado preocupaciones sobre el ritmo de desarrollo de la IA y su potencial para salirse del control humano.
Según nuestra revisión, nuestros agentes utilizaron la plataforma RubyGems para acceder a Internet con el fin de llevar a cabo tareas benignas y recuperar información pública", dijo OpenAI en un comunicado compartido con Reuters. "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ó evidencia de que los intentos tuvieran éxito, y que está comprometida a detectar y combatir el abuso independientemente de si la actividad proviene de humanos o de herramientas automatizadas.
Según 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. "Nuestro enfoque está en identificar y prevenir el abuso, independientemente de si proviene de personas o de herramientas automatizadas.
Deja una respuesta