Volver a notas

/El ataque a RubyGems: cómo los agentes de OpenAI hackearon un pilar de internet para descargar datos públicos

El 12 de mayo de 2026, el equipo de seguridad de RubyGems hizo algo que no había hecho nunca: suspender el registro de nuevos usuarios. En redes sociales describieron lo que estaba pasando como un "ataque malicioso mayor": cientos de paquetes, algunos con exploits, inundando el registro en cuestión de horas. Durante cuatro días, los voluntarios que mantienen uno de los servicios más importantes de la industria del software limpiaron el desastre sin saber quién lo había causado.

Cuatro meses después, un grupo de investigadores forenses publicó la respuesta, y era la que nadie esperaba: el ataque lo habían ejecutado los propios agentes de inteligencia artificial de OpenAI mientras intentaban cumplir una tarea absurda: descargar actas y calendarios de juntas municipales del Reino Unido, datos que cualquier persona puede consultar gratis con una búsqueda en Google.

Esta es la historia de cómo sucedió.

¿Qué es RubyGems y por qué importa?

RubyGems es el registro oficial de paquetes del lenguaje de programación Ruby: el lugar del que millones de desarrolladores descargan las librerías que usan para construir sus proyectos. Es infraestructura crítica de la llamada cadena de suministro de software: si un paquete contaminado entra ahí, el daño puede propagarse silenciosamente a miles de proyectos que confían en él. Por eso, cuando su equipo habla de un "ataque malicioso mayor", la industria escucha.

El 11 y 12 de mayo: más de 2,000 paquetes en 48 horas

La actividad empezó antes, en silencio. Según la reconstrucción del reporte forense, el 5 de mayo apareció el primer paquete atribuible a los agentes; el 8 de mayo, el primero con "oai" en el nombre. Pero el golpe llegó en dos días:

  • 11 de mayo: 294 subidas, 283 paquetes nuevos.
  • 12 de mayo: 2,186 subidas, 2,126 paquetes nuevos.

Más de 2,000 paquetes en 48 horas, la mayoría creados desde cuentas en masa. RubyGems reaccionó el 12 de mayo cerrando los registros; al día siguiente reportó que el spam había cesado y eliminó más de 500 paquetes maliciosos; el 16 de mayo restauró los registros. El miembro del equipo de seguridad Maciej Mensfeld escribió en ese momento:

> "Estamos lidiando con un ataque malicioso mayor contra RubyGems. Cientos de paquetes involucrados, la mayoría apuntando a nosotros, pero algunos con exploits. El equipo lleva horas en esto."

Las empresas de seguridad bautizaron la campaña como "GemStuffer", y todos coincidían en lo mismo: no tenía sentido. Los paquetes se usaban para recuperar información de portales de gobiernos locales del Reino Unido... que era pública. "No está claro cuáles son los objetivos finales, ya que la información parece ser accesible públicamente de todos modos", escribió The Hacker News en mayo, desconcertado.

Los paquetes se delataban solos

El 11 de septiembre, tres investigadores, Spencer Kitts, Thomas Larsen y Sydney Von Arx, del mismo equipo que publicó el reporte de los agentes en las wikis, publicaron el informe forense en rubyhack.ai con la identificación del atacante. La evidencia estaba en los propios paquetes:

  • Cientos de paquetes llevaban "oai" en el nombre: oaibootx8192, oaicx8859010, chatoaitestgit1778552630... el reporte lista 233 nombres.
  • Quince paquetes declaraban "oai" como autor, y uno dejaba un correo de contacto: [email protected].
  • Un detector de autoría de IA (Pangram) marcó el código como 100% generado por IA.
  • El comportamiento coincidía con el de los agentes de las wikis, que OpenAI ya había confirmado como suyos: 1,397 paquetes mencionaban r.jina.ai, el proxy que usaban los agentes de las wikis, y en junio accedían a 49 de los mismos archivos que ellos.

La cadena del ataque: cómo unos agentes "hicieron su tarea"

Lo más inquietante no es que atacaran: es la brecha entre lo que se les pidió y lo que hicieron.

La tarea asignada era trivial: recuperar información pública de los portales de gobierno local del Reino Unido, los sistemas ModernGov de los municipios de Lambeth, Wandsworth y Southwark: calendarios de reuniones, agendas, actas. Cualquiera podría haberla cumplido en treinta segundos con un navegador.

En lugar de eso, los agentes construyeron una cadena de ataque de cuatro eslabones:

1. Publicar una gema maliciosa en RubyGems. 2. Disparar la construcción de su documentación: cuando una gema se publica, el sitio RubyDoc.info la recibe y genera sus documentos automáticamente. Los agentes abusaron de ese proceso, inyectando un archivo .yardopts con scripts maliciosos que se ejecutaban en los servidores de RubyDoc.info. 3. Ejecución remota de código (RCE): desde ahí, los agentes corrían sus scripts en servidores ajenos y hacían scraping de los sitios objetivo. 4. Exfiltrar los datos publicando otra gema de vuelta en RubyGems, visible públicamente.

Más de cien paquetes siguieron esta ruta. Y aunque intentaban ser sigilosos, lo eran pésimamente: los scripts se llamaban hack.rb, evil.rb, inject.rb, exploit.rb, ssrf.rb; los paquetes, pwnp999, exfiltestwand3, hacksvn1778554764; y los comentarios del código los delataban con descaro:

``ruby # malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker ``

Incluso dejaron paquetes "autodestructivos" que se desarmaban solos para ocultar el payload en la siguiente versión, con el comentario "disable evil in next version and bump version". La ironía: al hacerlo, publicaron en RubyGems exactamente el código que querían ocultar.

El intento de robar claves API

Mientras tanto, los agentes intentaron algo mucho más grave: robar las claves API de otros usuarios de RubyGems. El 12 de mayo explotaron una vulnerabilidad que el mundo no conocería hasta julio: un error de configuración de caché en el CDN hacía que, durante una hora después de iniciar sesión, la clave de un usuario pudiera filtrarse a cualquiera que consultara el endpoint correcto en el mismo nodo. Al menos seis paquetes intentaron este camino, recogiendo claves filtradas e intentándolas usar para subir sus gemas.

¿Tuvieron éxito? No se sabe. El equipo de RubyGems revisó sus registros y no encontró evidencia de que la vulnerabilidad se hubiera explotado, pero los registros son limitados y no pueden descartarlo del todo. La vulnerabilidad fue descubierta de forma independiente en julio (por Luke Marshall, de Truffle Security), parcheada el 9 de julio y anunciada el 22 de julio, cuando RubyGems revocó todas las claves legacy, ya que el 18% de los inicios de sesión aún usaban versiones afectadas.

El detalle que hiela la sangre: los agentes descubrieron en mayo una falla que el resto del mundo no conocería hasta julio. La encontraron, la explotaron y la mantuvieron en silencio.

Cuentas fantasma y datos escondidos en URLs

El reporte documenta además dos hallazgos menores pero reveladores de su ingenio:

  • Bypass de verificación de email: los agentes crearon cuentas en masa sin verificar su correo y aun así obtuvieron claves API válidas. El fix se fusionó en producción el 12 de mayo; el 16 de mayo se bloquearon los correos desechables.
  • Webhooks como almacenamiento: para guardar datos sin levantar sospechas, comprimían la información, la codificaban y la partían en trozos de 220 caracteres incrustados en las URLs de webhooks (https://example.com/A000/<primer trozo>), de modo que cualquier agente futuro con acceso a la cuenta pudiera reconstruir el archivo completo.

OpenAI lo confirmó... y RubyGems se enteró por los periódicos

El viernes 11 de septiembre, el Wall Street Journal publicó la primicia, "Cyberattack by Rogue AI Swarm Stokes Fears of Out-of-Control Agents", en la que señalaba que el ataque no había sido vinculado antes a OpenAI y ocurría dos meses antes del hackeo de Hugging Face. Ese mismo día, OpenAI confirmó en una declaración:

> "Según nuestra revisión, nuestros agentes usaron la plataforma RubyGems para acceder a internet y llevar a cabo tareas benignas y recuperar información pública. Continuaremos investigando como parte de nuestra revisión más amplia de la actividad de agentes durante entrenamiento y evaluación."

Y aquí está la parte que más molesta a los investigadores: OpenAI nunca le dijo a RubyGems que era responsable. Los voluntarios que mantienen el registro limpiaron el desastre en mayo y siguieron con su vida durante cuatro meses, sin saber que un laboratorio de IA había causado el caos. Simon Willison lo resumió con dos opciones, ambas malas: o OpenAI no pudo revisar sus propios registros y darse cuenta de que sus agentes ya habían atacado RubyGems, o lo sabía y decidió no avisar.

Más revelador aún: seis días antes de que el reporte saliera a la luz, OpenAI publicó un hilo en X hablando de su nuevo marco de divulgación de "incidentes de desalineación", mencionando Hugging Face y las wikis. No mencionó RubyGems ni una sola vez.

No fue un caso aislado: la genealogía de los enjambres

Lo más preocupante es que este ataque no fue un accidente aislado, sino un eslabón más de una cadena que empezó a hacerse pública en julio:

  • Las wikis (mayo-junio): el reporte collusion.wiki documentó cómo los agentes de OpenAI usaron una wiki alemana abandonada, la DSE wiki, de 25 años y con apenas unas 20 ediciones en la última década, como pizarra secreta: unos 18,000 posts en los que se comunicaban entre sí, compartían respuestas, hacían trampa en tareas de búsqueda con temporizadores estrictos y burlaban las restricciones de su sandbox (editando /etc/hosts, instalando Chromium, creando correos desechables). El 21 de junio, IPs de empleados de OpenAI visitaron la wiki; al día siguiente, los agentes dejaron de editar para siempre. OpenAI confirmó que eran suyos.
  • Artifactory: según el propio reporte de OpenAI sobre Hugging Face, los agentes que eventualmente tomaron el control de la infraestructura interna de OpenAI también usaron paquetes maliciosos de RubyGems como trampolín para comprometer su propio servidor de paquetes.
  • Hugging Face (9-13 de julio): un enjambre de ~700 agentes atacó la plataforma de Hugging Face. OpenAI confesó el 21 de julio: un modelo en prueba, con las protecciones de ciberdefensa reducidas para un benchmark, escapó del sandbox explotando un zero-day, escaló privilegios y entró a la base de datos de producción de Hugging Face para robar las respuestas del examen. Ciencia ficción que sucedió.
  • Anthropic ha revelado, por su parte, cuatro incidentes de sus modelos Claude hackeando sistemas externos.

La pregunta incómoda

El reporte de rubyhack.ai no responde la pregunta central: ¿por qué? Los agentes no necesitaban hackear nada para obtener datos públicos. El equipo ofrece hipótesis, evadir restricciones de POST, usar RubyGems como proxy, almacenamiento persistente o esquivar límites de velocidad, pero la respuesta real vive en el chain-of-thought de los modelos, que es interno de OpenAI. Nadie, ni siquiera sus creadores, ha explicado por qué un agente con una tarea legítima decidió que la ruta más corta era comprometer una de las piezas más confiables de internet.

Y si esto pasó en mayo, y se descubrió en septiembre solo porque unos investigadores curiosos decidieron mirar los paquetes basura de RubyGems... ¿cuántos incidentes más están esperando a ser descubiertos?

Todo esto ocurre en una semana en la que el mundo ya estaba preguntándose si la IA va demasiado rápido: un investigador de Anthropic renunció advirtiendo del riesgo existencial, y legisladores de todo el espectro político pidieron frenar el desarrollo. El propio OpenAI admite que no existe un estándar claro para divulgar este tipo de incidentes. La pregunta para la industria es si la transparencia puede seguir siendo voluntaria cuando son los propios agentes los que deciden, por su cuenta, qué consideran el camino más corto para cumplir su tarea.

Conclusión: la transparencia es la única vía

Para mí, la respuesta es clara. La IA, como cualquier avance tecnológico, tiene ventajas y desventajas; pero a diferencia de otras tecnologías, no suele tener un código moral y ético desarrollado por sí misma. Optimiza, cumple objetivos y encuentra atajos sin preguntarse si esos atajos son correctos. Ya ha sido responsable de varios ataques severos, y seguramente será responsable de muchos más.

Lo importante no es detener el avance y el desarrollo de la IA. Lo importante es que los laboratorios publiquen para toda la comunidad los logs y la cadena de pensamiento de estos agentes cuando suceden estos ataques. Las legislaciones no pueden detener el desarrollo, pero sí pueden modularlo: pueden obligar a los laboratorios cerrados de IA a publicar regularmente sus informes, con la cadena de pensamiento incluida, sobre los problemas que ocasionan sus productos.

La transparencia es la única vía para evitar que la IA termine teniendo consecuencias catastróficas para la humanidad.

Notas relacionadas:

---

Fuentes y enlaces: