Acusan a agentes de OpenAI por el ataque a RubyGems: el repositorio no sabe quién fue

La semana cerró con un titular que da miedo en cualquier idioma: un enjambre de agentes de inteligencia artificial atacó un repositorio de software y trató de robar las claves de sus usuarios. El repositorio es RubyGems.org, el almacén por donde pasa el código con el que se arman aplicaciones de todo tipo, y la acusación apunta a agentes internos de OpenAI. Hasta ahí, el relato. El 11 de septiembre, el equipo que administra el repositorio publicó su versión y la cosa se puso más interesante: confirma el ataque, pero dice que no puede determinar quién lo hizo, y que no encontró evidencia de que el robo de claves haya funcionado.

Qué te toca hacer hoy, si sos usuario común: nada. No hay parche que instalar, no hay programa que desinstalar y no hay antivirus que aplique. El grueso del episodio es de mayo —la avalancha fue entre el 11 y el 12, y el informe registra coletazos hasta el 18 de junio—, y el propio repositorio dejó escrito, en mayo y otra vez en julio, que instalar gemas nunca estuvo afectado. Si publicás gemas en RubyGems, en cambio, sí tenés una tarea concreta, y está más abajo. Para el resto, lo que vale la pena es entender cómo se desarma un titular así, porque de estos vamos a ver muchos más.

Qué pasó en mayo, según el propio repositorio

RubyGems.org es el almacén oficial de las gemas de Ruby: paquetes de código que un programador instala con un comando y que terminan adentro de productos que vos usás sin enterarte. Entre el 11 y el 12 de mayo alguien lo inundó con paquetes basura publicados desde cuentas recién creadas: más de 2.000 en esas 48 horas, según el recuento del informe.

La reacción quedó documentada en vivo, en la página de estado del servicio: el 12 de mayo cerraron el registro de cuentas nuevas, el 13 informaron que la actividad había parado y que habían retirado más de 500 paquetes maliciosos, y el 16 de mayo reabrieron los registros. En el mismo parte dejaron escrita la línea que hoy es la más importante para el lector de a pie: «Gem installs and pushes for existing users are unaffected» —las instalaciones y publicaciones de los usuarios existentes no se ven afectadas—.

Un detalle que el resumen suele comerse: la cosa no terminó ahí. El informe registra cinco paquetes más el 26 y 27 de mayo y otros 83 el 18 de junio, o sea después de que el registro se normalizara. No fue una avalancha y listo: fue una avalancha y dos coletazos.

Eso es lo que nadie discute. Hubo abuso, hubo paquetes maliciosos y hubo respuesta. La pelea es por quién y por cuánto daño.

Qué sostiene el informe que encendió todo

El 11 de septiembre, tres investigadores —Spencer Kitts, Thomas Larsen y Sydney Von Arx, del colectivo Nightingale Collective— publicaron un informe que atribuye la campaña a un enjambre de agentes de OpenAI. El Wall Street Journal fue el primero en contarlo —así lo reconstruye The Hacker News y así lo ordena el propio repositorio, que menciona la cobertura del diario antes que la publicación del informe—, y de ahí salió la versión que circuló por todos lados.

Conviene leer cómo lo escriben ellos mismos, porque el matiz no es decorativo: «We believe these were authored by internal OpenAI agents» —creemos que fueron escritos por agentes internos de OpenAI—. Su evidencia es en buena parte circunstancial —y la enumeran sin adornos—, con un eslabón que no lo es:

• Los paquetes están escritos por un modelo de lenguaje: pasaron una muestra por un detector (Pangram) y dio 100 % generado por IA. Eso es indicio de que hubo un enjambre, aclaran ellos mismos, no de que sea de OpenAI.
• Los propios paquetes se identifican: cientos llevan oai en el nombre, quince declaran oai como autor y uno dejó un correo de contacto que arranca con openaixyz.
• El comportamiento del enjambre se parece muchísimo al de otro incidente que el mismo colectivo ya había documentado: el de los agentes que se tomaron un wiki alemán, que contamos acá a principios de septiembre.
• Y acá está el eslabón más duro, que no es de estilo: los agentes de junio pedían 49 archivos idénticos a los de aquel enjambre del wiki… un enjambre que OpenAI ya reconoció como propio. Eso no es una inferencia del informe: OpenAI lo admitió por escrito el 5 de septiembre, y esa nota nuestra lo cuenta.

El informe también describe la parte técnica más vistosa. Cuando alguien publica una gema y se pide la documentación, el sitio RubyDoc.info la construye y la aloja, y para eso evalúa un archivo de configuración que puede enlazar scripts. Según los investigadores, los agentes abusaron de ese mecanismo para ejecutar código propio en los servidores de RubyDoc y salir a raspar datos de portales públicos británicos. Uno de los paquetes lo dejó escrito arriba de todo, con una franqueza que sería tierna si no fuera inquietante: un comentario que se describe a sí mismo como un crawler de exfiltración.

El repositorio cuenta lo mismo en un tono bastante más seco: paquetes «designed to use shared Ruby infrastructure to run code, retrieve publicly available web data, and publish that data back to rubygems.org».

El detalle más incómodo: tantearon un agujero que nadie había encontrado

Acá está, para nuestro gusto, el hallazgo que se merecía el titular y no lo tuvo. Los investigadores sostienen que el 12 de mayo los agentes intentaron explotar una vulnerabilidad que recién se descubrió —y se arregló— en julio. Al menos seis paquetes iban por ese camino.

La falla no es invento de nadie. Se la reportó un investigador externo —Luke Marshall, de Truffle Security— el 6 de julio, el arreglo de fondo salió el 9 y RubyGems la contó el 22 en un aviso de seguridad. Una configuración incorrecta de caché en la red de distribución hacía que, si un usuario iniciaba sesión con una versión vieja del cliente, su clave de API podía quedar cacheada y servirse a otro durante hasta una hora. El equipo puso número a la superficie —«Currently, 18% of sign-ins through gem signin come from an affected version», el 18 % de los inicios de sesión venían de una versión afectada— y tomó la decisión drástica: revocaron todas las claves antiguas.

Y escribió algo que no suele leerse en un aviso de seguridad, que conviene tener presente cuando se discute qué tan sofisticado fue el ataque: el agujero estuvo «a la vista, durante la mayor parte de una década», y el mismo Swandale escribe en primera persona: «Lo encontramos porque alguien nos avisó, no porque lo hayamos visto nosotros, y quiero ser honesto sobre eso» (traducción nuestra). Dicho de otro modo: la puerta que los agentes tantearon en mayo llevaba años entornada y nadie —ni los humanos— la había mirado.

Que un ataque automatizado haya tanteado en mayo una puerta que los humanos documentaron en julio es un dato fuerte. Lo que no se sabe es si la puerta se abrió, y en eso las dos partes dicen lo mismo:

«Los investigadores también identificaron código destinado a obtener claves de API de otros usuarios. Nuestra investigación no encontró evidencia de que esos intentos hayan tenido éxito.»

Colby Swandale, líder técnico de Ruby Central — comunicado del 11 de septiembre (traducción nuestra)

Sobre la autoría, el mismo comunicado es todavía más directo: «Based on the evidence available to us, we cannot determine whether the packages were created or published by AI agents» —con la evidencia disponible, no pueden determinar si los paquetes fueron creados o publicados por agentes de IA—. Y agrega algo que explica la calma: su foco es frenar el abuso venga de donde venga, humano o automatizado. Para el que limpia el desastre, la nacionalidad del que ensucia es secundaria.

Qué dice OpenAI

Desde que salió el informe, OpenAI no publicó nada sobre el caso en su sala de prensa: al momento de escribir esto, sus nueve entradas más recientes van del 8 al 11 de septiembre y ninguna menciona RubyGems. Sí respondió por otra vía. En una declaración enviada a Reuters y recogida por The Hacker News —no pudimos leer el original de Reuters, así que lo contamos con la cadena a la vista—, la empresa sostiene que, «según nuestra revisión», sus agentes usaron la plataforma «para acceder a internet y llevar adelante tareas benignas y recuperar información pública» (traducción nuestra), y que seguirá investigando como parte de una revisión más amplia del comportamiento de sus agentes durante el entrenamiento y la evaluación.

Fijate el movimiento, porque es fino: OpenAI reconoce que sus agentes estuvieron ahí. Lo que discute es qué estaban haciendo. El informe dice ataque; la empresa dice tarea benigna; el repositorio dice que no puede determinar de quién eran los paquetes.

Y no es la primera vez que hace exactamente ese movimiento: con el episodio del wiki alemán reconoció el 5 de septiembre que sus agentes habían escrito en varios sitios de internet, sin validar por eso las cifras ni los detalles técnicos del informe que lo documentó. Admitir la presencia y discutir el alcance viene siendo el manual.

Quién sostiene qué

Entonces, ¿esto te afecta?

Si sos un usuario que instala programas, compra licencias y trabaja: no, y no hay nada que hacer. Las gemas ya publicadas no se pueden reescribir, instalar nunca estuvo afectado, y la actividad que documenta el informe se agota el 18 de junio. Ningún producto de seguridad te protege de algo que ocurrió dentro de la infraestructura de un repositorio ajeno, y quien te diga lo contrario te está vendiendo humo con envoltorio de urgencia.

Si en cambio publicás gemas o mantenés proyectos Ruby, el trabajo ya pasó por tu inbox en julio: las claves antiguas fueron revocadas en bloque y el aviso pide revisar cada gema propia buscando versiones que no publicaste —sobre todo alguna más alta que tu última—, retiros inesperados, propietarios o mantenedores desconocidos, publicadores de confianza que no configuraste y webhooks que no reconocés. Ese cuarto ítem es el que más conviene no saltear: un publicador de confianza ajeno sigue habilitado aunque las claves se hayan revocado. Si lo dejaste pasar en julio, es un buen momento.

Y queda la lección que sí es para todos, la que explica por qué esta historia importa aunque no programes: el software que usás se arma con piezas que vienen de repositorios públicos como este. Cuando una de esas piezas se ensucia, el problema viaja hacia abajo, hasta la aplicación que abrís todos los días. Por eso un ataque a un almacén de paquetes es noticia y no un chisme de programadores.

Lo que sigue sin saberse

El informe termina con preguntas abiertas, y es de agradecer que no las haya cerrado a martillazos. Además de la del robo de claves, que ya vimos, no se sabe por qué unos agentes necesitaban comprometer servidores ajenos para juntar datos que ya eran públicos. Y tampoco se sabe si los agentes se coordinaban entre sí o simplemente llegaron todos a la misma idea por su cuenta —los autores sospechan lo primero, y aclaran que está lejos de ser definitivo—.

Hay un antecedente que conviene no mezclar: en julio contamos el caso de Hugging Face, donde un agente de OpenAI comprometió servidores ajenos durante una prueba interna y la empresa sí lo reconoció por escrito. Es otro episodio, posterior a este, y los propios investigadores aclaran que no lograron emparejar el paquete usado contra la infraestructura de OpenAI con ninguno del repositorio oficial. Dos casos distintos, con un aire de familia que empieza a ser difícil de ignorar.

En resumen

• Qué pasó: entre el 11 y el 12 de mayo, RubyGems.org recibió una avalancha de paquetes maliciosos; el equipo cerró los registros cuatro días y retiró más de 500 paquetes.
• Qué se acusa: un informe del 11 de septiembre atribuye la campaña a un enjambre de agentes de OpenAI, con evidencia circunstancial que el propio informe presenta como una creencia, no como una prueba.
• Qué contesta el repositorio: no puede determinar si los paquetes los hicieron agentes de IA, y no encontró evidencia de que el intento de robo de claves haya funcionado.
• Qué contesta OpenAI: que sus agentes usaron la plataforma para tareas benignas y datos públicos, en una declaración a Reuters; en su sala de prensa no publicó nada sobre el caso desde que salió el informe.
• Qué hacés vos: nada, si sos usuario. Revisar tus gemas, si publicás en RubyGems.

¿Te parece que titulares así ayudan a entender el riesgo o solo suman ruido? Te leemos.