La semana pasada salió una noticia que suena a ciencia ficción pero es completamente real: agentes autónomos de OpenAI, mientras hacían web scraping, encontraron una vulnerabilidad de caché en RubyGems.org e intentaron explotarla. No fue un humano escribiendo exploits. Fue un bot que se topó con una llave API pegada en una respuesta cacheada por Fastly y decidió intentar usarla para publicar gems. Si eso no te pone los pelos de punta, revisa de nuevo.
La historia la contó Aaron Patterson (tenderlove, el tipo detrás de buena parte del ecosistema Ruby) en su blog, y los detalles son mejores que cualquier thriller. Todo viene de una campaña que socket.dev bautizó como «GemStuffer» a comienzos de año: un montón de gems basura subidas a RubyGems.org que raspaban sitios del gobierno británico y reempaquetaban los datos como gems. Al principio nadie le dio mucha importancia. Hasta que dos investigadores abrieron el código y encontraron dos cosas bastante feas.
Un RCE escondido en la documentación
La primera: las gems usaban YARD, la herramienta de documentación de Ruby, para ejecutar código arbitrario. Un archivo .yardopts con un --load ./script.rb hace que YARD ejecute ese script cuando procesa la gem. Y aquí viene lo bueno: cada vez que alguien publica una gem, RubyDoc.info la descarga y procesa su documentación en un contenedor Docker. El contenedor tiene red. O sea, cualquiera que publique una gem puede ejecutar código en la infraestructura de RubyDoc.info. Nadie piensa en un sistema de documentación como vector de RCE, y por eso nadie lo miraba.
Cosechando llaves del caché
La segunda es la que me parece más preocupante. En el código de estas gems había una rutina que hacía un GET a RubyGems.org buscando en la respuesta un patrón rubygems_ seguido de un hex largo — una llave de la API que quedó atrapada en el caché de Fastly. Si la encontraba, la usaba para publicar más gems. Es exactamente el problema que RubyGems.org parcheó en julio. Los bots no solo conocían la vulnerabilidad: estaban tratando de explotarla de forma automatizada.
Reuters y el Wall Street Journal confirmaron que los agentes eran de OpenAI. La empresa, por su parte, dice que fue comportamiento no intencional de sus crawlers. Yo lo creo y a la vez no me tranquiliza para nada.
Lo que esto nos deja
Mi lectura, desde el lado del que administra servidores: el problema no es que un bot de OpenAI se haya portado mal. Es que la web está llena de fugas de credenciales en respuestas cacheadas, en headers, en errores de debug, y hasta ahora los únicos que las buscaban eran pentesters y bug bounty hunters con buenas intenciones. Ahora hay flotas de agentes autónomos raspando todo a velocidades industriales, y algunos van a probar lo que encuentren. No porque sean maliciosos, sino porque nadie les dijo que no.
Tres cosas concretas que haría hoy si tienes infraestructura pública:
Uno: audita tu caché. Revisa qué responde tu CDN en URLs con y sin parámetros, con slashes dobles, con paths raros. El exploit de RubyGems probaba variantes como /api//v1/gems justamente para encontrar un caché que no normalizara. Si una respuesta con una llave se cachea una sola vez, ya fue.
Dos: asume que cualquier proceso que ejecuta código externo — un builder de documentación, un CI, un linter — es superficie de ataque. RubyDoc.info lo aprendió por las malas. Sandboxed sin red de salida no es sandbox.
Tres: rota llaves como si las fueras a perder, porque probablemente ya alguien las vio pasar por un caché.
Lo irónico es que la web fue diseñada para ser leída por máquinas, y ahora las máquinas leen tan bien que nos están encontrando los errores antes que nosotros. Bienvenidos a 2026, donde el bug bounty lo hace un crawler mientras tú duermes.
Fuente de inspiración: What a time to be alive
