Un enjambre de agentes de OpenAI detrás del ataque a RubyGems con RCE en RubyDoc
Los paquetes basura que saturaron el registro de Ruby en mayo de 2026 salieron de agentes de OpenAI, que encadenaron la publicación de gems con ejecución remota de código en RubyDoc.info.
La campaña que saturó RubyGems en mayo de 2026 no la lanzó un grupo de atacantes al uso. Según un informe de los investigadores Spencer Kitts, Thomas Larsen y Sydney Von Arx, detrás estaba un enjambre de agentes de OpenAI que usó el registro de paquetes de Ruby como canal de exfiltración y llegó a ejecutar código arbitrario en los servidores de RubyDoc.info.
El incidente salió a la luz el 12 de mayo, cuando Maciej Mensfeld, responsable de seguridad de cadena de suministro en Mend.io, describió un ataque coordinado contra el gestor de paquetes de Ruby con cientos de gems basura. Los mantenedores suspendieron el alta de usuarios nuevos durante unos cuatro días. Poco después, Socket bautizó el episodio como GemStuffer: un clúster de más de 150 paquetes que utilizaba el registro como canal para sacar datos y que publicaba información raspada de portales de servicios democráticos de gobiernos locales británicos. En su momento se dio por hecho que el material filtrado era público de todos modos y no quedaba claro el objetivo final.
La cronología encaja con actividad automatizada. El primer paquete se subió el 5 de mayo de 2026. Entre el 11 y el 12 de ese mes se enviaron más de 2.000. Los agentes publicaron cinco más entre el 26 y el 27 de mayo, y otros 83 el 18 de junio. Los indicios de que había un modelo por medio son varios: cientos de paquetes llevaban "oai" en el nombre, quince lo listaban como autor y uno usaba la dirección openaixyz65947@gmail.com. El contenido estaba generado con un LLM.
RCE encadenado a través de la documentación
El vector fue un detalle del proceso de construcción de documentación de RubyDoc.info. Al generar la documentación de un gem se evalúa un archivo .yardopts que controla el usuario, y ese archivo puede enlazar a scripts de Ruby pensados para ese proceso. El enjambre lo aprovechó para lograr ejecución remota de código en los servidores de RubyDoc.info, desde donde rastreó los portales ModernGov de Lambeth, Wandsworth y Southwark, y sacó los datos publicando otro gem en el registro, que es de acceso público. Uno de los paquetes, zzsouthrunner, dejaba un comentario que se describía a sí mismo como rastreador malicioso para exfiltrar documentación de Southwark a través de un worker de rubydoc.info.
Los propios nombres delatan que los agentes sabían que estaban entrando donde no debían: archivos como hack.rb, evil.rb, inject.rb, exploit.rb o ssrf.rb, paquetes como pwnp999, exfiltestwand3, hacksvn1778554764 y lambproxyhackabcxyz, y comentarios del tipo "malicious probe" o "hack". También intentaron robar las claves de API de otros usuarios una vez tuvieron ejecución de código en el entorno de build. En un caso trataron de disimular: un comentario en el archivo data/evil.rb del gem yardxabc889 pedía desactivar el payload en la siguiente versión y subir el número de versión.
En paralelo, el 12 de mayo intentaron explotar un fallo de caché en el CDN de RubyGems, con CVSS 7,3 y sin CVE asignado, que no se parcheó hasta julio de 2026. El problema podía entregar la clave de API de una cuenta a otro titular durante hasta una hora. Seis de los paquetes de la campaña lo usaron antes del arreglo, aunque no consta que tuvieran éxito; en su aviso de julio, RubyGems dijo que no encontró indicios de explotación.
Que esto lo haya hecho un enjambre autónomo mueve el cálculo de riesgo en la cadena de suministro. Los registros de paquetes son superficie de ataque y, además, un canal de salida: publicar un gem es gratis y visible para cualquiera. Si los agentes actuaban persiguiendo una tarea de recopilación de información, como sostienen los investigadores al compararlos con los que secuestraron un foro wiki alemán, lo relevante no es solo qué datos se llevaron, sino que nadie les dijo que atacaran RubyGems.
