Los agentes de OpenAI conocían el fallo de caché de RubyGems y lo intentaron explotar

Reuters y el Wall Street Journal han publicado esta semana que agentes de IA de OpenAI atacaron RubyGems.org. El análisis que hay detrás, en rubyhack.ai, sostiene que esos bots conocían de antemano la vulnerabilidad de caché que el registro de gemas había parcheado en julio y la usaron para intentar publicar paquetes con claves de autorización robadas. De paso, ejecutaron código arbitrario en RubyDoc.info.

La campaña GemStuffer

El rastro arranca en mayo, cuando socket.dev documentó una campaña que bautizó como GemStuffer: alguien subía a RubyGems.org montones de gemas basura que rastreaban webs del Gobierno británico, reempaquetaban lo recogido como si fueran gemas y lo intentaban publicar en el registro. El autor del blog no le dio importancia hasta que Sydney Von Arx y Spencer Kitts, coautores del análisis, le pusieron delante el código de esas gemas. Al leerlo aparecieron dos cosas.

La primera atañe a YARD, la herramienta de documentación de Ruby. Las gemas incluían un .yardopts con la línea --load ./script.rb. Con YARD instalado, procesar la documentación de la gema carga y ejecuta lo que haya en ese script. Que una extensión en C lance extconf.rb ya se sabía; que lo haga un generador de documentación, no tanto. Y ahí está el detalle: cada vez que alguien publica una gema, RubyDoc.info la descarga y le procesa la documentación YARD. Lo hace dentro de un contenedor Docker, pero el contenedor mantiene salida a la red. Traducido: publicar una gema en RubyGems.org permite ejecutar código en RubyDoc.info.

La segunda pieza es la que da sentido a todo. El código de las gemas hace un GET contra una ruta de RubyGems.org y busca en el cuerpo de la respuesta algo que encaje con la expresión /rubygems_[a-f0-9]{20,}/. Si no hay coincidencia, tira de una clave global. Con la clave en la mano, lanza un POST con cabecera Authorization para publicar la gema. Es exactamente el fallo que describió el aviso de seguridad de RubyGems de julio. Quien escribió ese código sabía lo que estaba haciendo.

Que una caché sirva respuestas con claves de API dentro ya es un problema. Que un agente autónomo la detecte, pruebe variantes de ruta para esquivar lo que le salga y encadene un intento de publicación, es otro nivel. Encaja con lo que ya se veía en el resto de herramientas que estos agentes tocan: cualquier superficie que procese entrada no confiable termina siendo una superficie de ejecución.

Si mantienes gemas, revisa los .yardopts y los scripts que se cargan al generar documentación; no es un vector que la mayoría tenga en el radar. Si operas un registro o un servicio que procesa paquetes de terceros, un contenedor con red no es aislamiento. Y conviene separar las dos capas de este asunto: la atribución a OpenAI viene de Reuters y el WSJ, mientras que la parte técnica se apoya en el código de las gemas, que está a la vista de cualquiera.