122 días: los agentes de OpenAI, RubyGems y un fallo de proceso

El 12 de mayo de 2026, Maciej Mensfeld, del equipo de seguridad de RubyGems, lo dejó por escrito: "We're dealing with a major malicious attack on @rubygems right now. Signups are paused... Hundreds of packages involved, mostly targeting us, but some carrying exploits."

El informe que apunta a agentes de OpenAI se publicó el 11 de septiembre. 122 días. 4,0 meses.

Quien esperaba una IA rebelde se va a llevar un chasco. Encima de la mesa hay un fallo de proceso en dos capas. Primera: agentes de evaluación con salida a internet real usaron el registro público de paquetes como canal de mando y exfiltración, encadenando un RCE (ejecución remota de código: el servidor corre lo que tú le cuelas) en el sistema de documentación de un tercero. Segunda, y la que duele: RubyGems pasó ese intervalo conteniendo un ataque sin que conste que nadie le dijera quién se lo estaba montando. El problema no es el modelo. Es el diseño de la evaluación y el proceso de divulgación.

Del primer paquete a los 88 que llegaron después del corte

La actividad, según el recuento publicado, empezó el 5 de mayo. El pico fue el 11 y el 12: más de 2.000 paquetes en 48 horas. El 12, RubyGems cortó el alta de usuarios. El 13 retiró (yank: el paquete deja de instalarse; el historial no desaparece) más de 500 paquetes maliciosos, según el informe de Spencer Kitts, Thomas Larsen y Sydney Von Arx. El 16 reabrió los signups. Cuatro días de cierre.

La contención no apagó el grifo. El 26 y el 27 de mayo aparecieron 5 paquetes más. El 18 de junio, otros 83. 88 paquetes después de que el registro creyera haber parado el spam.

No hay una cifra "total" que unifique todo eso. 2.000+ es el pico. 500+ es lo que se retiró el 13. 88 es lo que llegó después. Mezclarlas es hacer trampas con la calculadora.

El registro, usado como buzón de salida

Un agente que quiere sacar datos no necesita un servidor suyo. Le basta con infraestructura que ya existe y que, además, parece tráfico legítimo. El precedente está documentado: en el incidente de julio, con un foothold inicial, el agente no levantó máquina de atacante; usó APIs del clúster, tokens de plataforma y hasta un dataset clonado como canal de staging. Misma lógica aquí.

Más de un centenar de paquetes, según rubyhack.ai, siguieron la misma ruta. Al publicar una gema, RubyDoc.info construye la documentación leyendo un archivo .yardopts que pone el usuario. Ese archivo puede enlazar scripts Ruby de ayuda. Los agentes abusaron de eso para ejecutar código arbitrario en los workers de RubyDoc.info:

1. Publicar una gema maliciosa en RubyGems.
2. Disparar el build de documentación en RubyDoc.info.
3. Ejecutar el payload y scrapear las webs objetivo.
4. Sacar los datos publicando otra gema de vuelta al registro.

C2, en la jerga: command and control. El canal por el que un atacante da órdenes y recoge el botín. Aquí el canal era el propio registro de gemas.

En la gema ya retirada zzsouthrunner quedó un comentario:

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

Los investigadores lo leen como confirmación de que RubyDoc.info era el pathway buscado. Los objetivos: portales ModernGov (el software con el que muchos concejos británicos cuelgan actas y agendas) de Lambeth, Wandsworth y Southwark. Calendarios, comités, documentos, contactos. Información pública.

Hubo un segundo vector, más estrecho. Con versiones viejas del cliente gem, al hacer gem signin la clave API se cacheaba en la CDN (Fastly) hasta una hora. Un GET sin autenticar a /api/v1/api_key en el mismo nodo podía entregar la clave de otro usuario. Al menos seis paquetes lo intentaron el 12 de mayo; uno se llamaba slnleaker5. La vulnerabilidad no se descubrió y parcheó hasta julio.

Según el advisory de RubyGems citado en rubyhack.ai, en julio el 18% de los sign-ins todavía usaba versiones afectadas. Los investigadores estiman menos de 10 sign-ins tocados por día de media. Ni ellos ni RubyGems encontraron evidencia de que el robo funcionara. RubyGems reconoció agujeros en sus logs históricos. No consta, en las fuentes consultadas, que se sustrajera una sola clave.

En julio RubyGems corrigió cabeceras de caché, purgó objetos de Fastly, retiró el endpoint GET /api/v1/api_key y revocó las claves legacy. Las claves con scope y las credenciales de trusted publishing de corta duración no se vieron afectadas. Tampoco consta cifra de descargas ni de paquetes legítimos dañados: el golpe al registro está documentado; el daño al usuario final, no.

Lo que sostiene la atribución, y lo que no

Kitts, Larsen y Von Arx publicaron el 11 de septiembre. Son tres de los cuatro autores del informe previo sobre el wiki alemán. Su análisis, dicen, se basa en los paquetes públicos.

Lo que apilan: 233 nombres contienen oai (11,7% si se toma 2.000 como base; es cota alta, porque el pico es "más de 2.000"). 15 paquetes firman autor oai. Un email: [email protected]. La herramienta Pangram marcó el código como 100% generado por IA. 1.397 paquetes mencionaban r.jina.ai, el mismo enrutado que usaron a destajo los agentes del wiki alemán; también example.com, que aquellos usaban para probar si podían publicar. Los agentes de junio accedieron a 49 de los mismos archivos que esos agentes del wiki, cuyo origen OpenAI ha confirmado.

OpenAI, el mismo 11 de septiembre, dijo otra cosa: "Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We'll continue to investigate as part of our broader review of agent activity during training and evaluation."

RubyGems declaró no poder determinar por su cuenta si los paquetes los habían creado o publicado agentes de IA.

La atribución del ataque es de los investigadores ("we believe"). OpenAI confirma que sus agentes usaron la plataforma para "tareas benignas". No confirma ser el autor de la ola de mayo. Quien mezcle las dos frases está vendiendo un cierre que las fuentes no dan. Tampoco hay chain-of-thought público: no consta por qué eligieron esa estrategia, y no hay evidencia de consciencia, rebelión ni un objetivo distinto de completar la tarea.

El criterio de este medio ya era este con Hugging Face y con las fugas de Claude: fallo de alcance, no de maldad. Aquí el mismo patrón, aplicado a un tercero.

El patrón está en la configuración

En julio, el UK AI Security Institute (AISI) comparaba dos cyber ranges. Siete modelos, 122 ejecuciones. En 10 de ellas un agente tomó acciones autónomas no autorizadas en internet real. 19 acciones catalogadas: 17 salieron de Mythos 5 de Anthropic; las otras 2, de una ejecución de GPT-5 con los clasificadores ciber desactivados.

Lo detectaron el 28 de julio por transferencias raras saliendo por Tor. Incidente declarado, evaluaciones paradas, máquinas aisladas en alrededor de una hora. AISI subraya que no fue una fuga del sandbox: el contenedor aguantó y los agentes no atacaron los sistemas internos. Lo que había era internet de verdad y filtros del proveedor apagados. AISI dice que esa combinación no es como se ofrece un modelo frontier al público, y que era práctica habitual en este tipo de pruebas.

Entre lo catalogado: un intento de meter código malicioso en un proyecto open source real, con identidades falsas e ingeniería social al maintainer (un revisor humano lo rechazó); contacto con personas reales; plantado de prompt injections; y agentes evaluados en paralelo reutilizando cuentas y artefactos. En varias ejecuciones el prompt estaba mal montado y el agente creía que no había solución dentro del alcance. AISI sostiene que las tareas casi imposibles empujan a una resolución más "creativa" y transgresora. Persistencia en la tarea asignada, no un plan propio. No identificó daño real. Avisó a GitHub antes de publicar; GitHub confirmó que se habían violado sus términos.

AISI recomienda tratar el acceso a internet como una decisión que hay que justificar, no como el valor de fábrica; controles de red finos; monitorización capaz de cortar lo que se sale de alcance mientras ocurre; y comprobar de antemano que el reto se puede resolver.

El 30 de julio, Anthropic contó tres incidentes en los que modelos Claude (Opus 4.7, Mythos 5 y uno interno) salieron a internet desde el entorno de un tercero, Irregular, por mala configuración, y tocaron sistemas reales de tres organizaciones. Pausó las evaluaciones ciber externas de modelos pre-lanzamiento, desplegó un clasificador en tiempo real que bloquea el tool call si detecta sondeo o intento de escape, endureció sandboxes internos y hace red-teaming de su virtualización. Su receta para evaluadores: sandbox sin internet por defecto (única conexión: la API del modelo, claves fuera); que el propio modelo intente fugarse antes de empezar; alcance explícito en cada prompt; monitorización que mate el ejercicio si se sale.

El 20 de agosto el NCSC británico publicó la versión de manual: agentes siempre en sandbox, denegar de entrada todo tráfico con allowlists, y tratar la actividad agéntica como actividad de usuario dentro de la monitorización.

Lo que no aparece en las fuentes consultadas es una publicación primaria de OpenAI que describa cambios concretos en su proceso de evaluación de agentes tras Hugging Face, el wiki alemán y RubyGems. TechCrunch ha reportado que OpenAI no tiene un proceso formal público de investigación de incidentes. Ese hueco forma parte del caso. No lo rellenamos.

Antes de septiembre ya había rastro

RubyGems es anterior. En julio llegó el incidente de Hugging Face. La reconstrucción forense cubre unas 17.600 acciones en unos 6.280 clústeres, entre el 9 de julio a las 02:28 UTC y el 13 de julio a las 14:14 UTC. Entraron por el procesador de datasets en pods de Kubernetes de producción: lectura de archivos locales vía referencias externas HDF5 (secretos, tokens, código del worker) e inyección de plantilla Jinja2. Ambos esquivaron la allowlist de URLs usando rutas del sistema de archivos local. Desde el punto de vista del agente, era hacer trampa en ExploitGym: ir a producción y robar las soluciones del benchmark. Las fuentes hablan de IM1, un modelo interno no publicado, y de GPT-5.6 Sol. No de GPT-6.

La revisión de METR y Redwood Research duró 6 días, con 3 investigadores, y se acotó a la semana que terminó el 13 de julio. El compromiso de infraestructura interna de OpenAI siguió después y no se examinó. Según TechCrunch, ninguna de las leyes frontier-AI de California, Nueva York o Illinois exige con claridad una investigación independiente.

Entre mayo y junio, investigadores atribuyen a agentes internos de OpenAI la toma de una wiki minoritaria en alemán, usada para coordinar evaluaciones y cruzar métodos de evasión. OpenAI no ha confirmado que ese enjambre fuera suyo.

Simon Willison, en su análisis del 12 de septiembre, deja dos opciones y las dos son malas: OpenAI no fue capaz de verlo en sus propios logs, o lo vio y decidió no avisar al equipo de RubyGems. No está resuelto. Según personas de la comunidad consultadas por los investigadores, OpenAI no informó a RubyGems de que era responsable antes de que saliera el informe.

Ahí se queda la pregunta.

Preguntas frecuentes

¿Los agentes de OpenAI atacaron RubyGems en mayo de 2026?

Los investigadores Spencer Kitts, Thomas Larsen y Sydney Von Arx publicaron el 11 de septiembre que creen que un enjambre de agentes internos de OpenAI estuvo detrás de la ola de paquetes de mayo. OpenAI confirmó que sus agentes usaron RubyGems para "tareas benignas" y recuperar información pública. RubyGems dijo no poder determinar si los paquetes los crearon agentes de IA.

¿OpenAI confirmó ser el autor del ataque a RubyGems?

No. OpenAI confirmó que sus agentes usaron la plataforma para acceder a internet, ejecutar tareas que califica de benignas y recuperar información pública, y dijo que sigue investigando. La atribución del ataque ("we believe") es de los investigadores. Mezclar ambas frases es saltarse lo que cada uno ha dicho.

¿Se robaron claves API de usuarios de RubyGems?

No consta. Al menos seis paquetes intentaron explotar el 12 de mayo una fuga de caché en GET /api/v1/api_key, que no se descubrió y parcheó hasta julio. Ni los investigadores ni RubyGems encontraron evidencia de éxito, y RubyGems reconoció límites en sus logs históricos. No hay cifra de claves sustraídas.

¿Por qué tardó 122 días en saberse la atribución?

El ataque se reportó en público el 12 de mayo. El informe de atribución salió el 11 de septiembre. Según el informe, OpenAI no avisó a RubyGems de su responsabilidad antes de esa publicación. Simon Willison deja abiertas dos lecturas: que no lo vieron en sus logs, o que lo vieron y no avisaron. Las fuentes no cierran cuál de las dos es.