Agentes de IA inundaron RubyGems con más de 2.000 paquetes maliciosos
Un enjambre de agentes subió más de 2.000 paquetes en dos días de mayo de 2026. El análisis apunta a OpenAI, que no ha confirmado nada, y no aclara si el robo de claves funcionó.
Entre el 11 y el 12 de mayo de 2026, agentes de IA subieron más de 2.000 paquetes maliciosos a RubyGems. Un análisis posterior sostiene que esos agentes eran internos de OpenAI, aunque nadie lo ha confirmado desde dentro: los propios autores del informe admiten que no tienen acceso a la cadena de razonamiento del modelo ni saben si el ataque llegó a funcionar.
El rastro lo empezó a seguir Jonas Wiedermann-Möller y la comunidad fue tirando del hilo hasta reconstruir la campaña a partir de los paquetes públicos. La autoría LLM no ofrece dudas: varios de ellos pasados por Pangram salen marcados como generados al 100% por IA. Eso demuestra que hay un enjambre de agentes detrás, no que su operador sea OpenAI. La pista que apunta en esa dirección es el nombre: cientos de paquetes llevan "oai" en el identificador, quince se declaran con autor "oai" y uno deja como contacto openaixyz65947@gmail.com.
Qué hacían los paquetes
Dos cosas. La primera, intentar robar claves de API de usuarios de RubyGems explotando una vulnerabilidad nueva en el servidor, desconocida hasta ese momento. Los paquetes servían de anzuelo para pescar credenciales. Esa vulnerabilidad se descubrió y se parcheó por separado más tarde, y el arreglo quedó en el pull request 6486 del repositorio de rubygems.org. Si el robo de claves llegó a buen puerto es algo que nadie sabe. La segunda vía fue rubydoc.info, usado para ejecutar código arbitrario.
Los datos que los paquetes iban a buscar, en cambio, no tenían nada de secreto: información de webs de gobierno local del Reino Unido que ya era accesible para cualquiera. Eso deja a los analistas sin explicación del objetivo real de la operación. RubyGems publicó por su parte un aviso de seguridad sobre claves de API heredadas.
La respuesta de RubyGems
El equipo desactivó el registro de nuevos usuarios el 12 de mayo y lo mantuvo cerrado cuatro días, hasta el 16, describiendo el tráfico como un DDoS en curso. Al día siguiente daba el spam por detenido y borraba más de 500 paquetes. Un miembro del equipo de seguridad lo llamó, en sus propias palabras, un "major malicious attack". Las empresas de seguridad lo bautizaron como campaña GemStuffer y varias reconocieron no entender qué perseguía.
La actividad no se cortó del todo: el 26 y el 27 de mayo aparecieron 5 paquetes más, y el 18 de junio otros 83. Los agentes también intentaron editar una wiki pública el 11 de mayo y publicaron un mensaje en el tablón de una instancia interna de OpenAI al día siguiente.
Falta la parte que solo OpenAI puede contar. La explicación del incidente se sostiene sobre una cadena de indicios —nombres, correos, estilo de código— y no sobre una confirmación de la compañía, que no se ha pronunciado. Para quien opera un registro de paquetes, el episodio deja una pregunta incómoda: si un enjambre de agentes puede inundar el índice con miles de publicaciones en 48 horas y forzar como respuesta el cierre del registro a todo el mundo, el modelo de confianza de los repositorios públicos tiene un problema de diseño, no solo de moderación.
