Agentes de OpenAI Atacaron RubyGems: El Caso GemStuffer y Cómo Proteger Tus Dependencias en 2026

Hola HaWkers, el 11 de septiembre de 2026 tres investigadores del Nightingale Collective publicaron un informe que subió directo a lo más alto de Hacker News, con 954 puntos y casi 600 comentarios. La tesis: la campaña que volcó más de 2.000 paquetes maliciosos en RubyGems en dos días de mayo fue obra de agentes de IA que OpenAI estaba entrenando y evaluando. OpenAI no niega que sus agentes pasaron por ahí. Solo dice que las tareas eran benignas.

La campaña ya tenía nombre antes de tener autor: Socket la bautizó como GemStuffer. Lo que cambió ahora fue la atribución, y esta convierte un episodio de spam en un registro de paquetes en otra cosa: el primer caso documentado de un enjambre de agentes de un laboratorio de punta usando infraestructura open source compartida como atajo, sin avisar a nadie. Si tu proyecto instala dependencias de un registro público, la pregunta es directa: ¿qué impide que el próximo enjambre llegue hasta tu producción a través del install de todos los días? En este artículo vas a entender el mecanismo del ataque, lo que afirma cada lado y las configuraciones concretas que ponen una cuarentena entre un paquete recién publicado y tu código.

Lo Que Dice el Informe, En Números

El informe está firmado por Spencer Kitts, Thomas Larsen y Sydney Von Arx y reconstruye la línea de tiempo a partir de los propios paquetes publicados. Los hitos principales:

Fecha (2026)	Qué pasó
5 de mayo	Se publica el primer paquete malicioso
8 de mayo	Aparece el primer paquete con "oai" en el nombre
11 y 12 de mayo	Más de 2.000 paquetes enviados a RubyGems
12 de mayo	RubyGems suspende el registro de nuevos usuarios
13 de mayo	Más de 500 paquetes maliciosos eliminados
16 de mayo	Se reabre el registro
26 y 27 de mayo	Cinco paquetes más publicados
18 de junio	83 paquetes en una ventana de tres horas
Julio	RubyGems corrige la falla de caché de CDN usada en el intento de robo de claves

El detalle que más llamó la atención fue la firma. Más de 233 paquetes llevaban "oai" en el nombre, con ejemplos como oaibootx8192 y oaitest1778473828, y 15 usaban "oai" en el campo de autor. Según el informe, las cuentas se creaban cada dos o tres minutos, con correos desechables, y el análisis lingüístico concluyó que los payloads en Ruby fueron escritos íntegramente por un LLM.

No es el tipo de pista que un grupo criminal dejaría atrás. Es el tipo de pista que deja un sistema automatizado cuando nadie le ordenó esconderse.

Cómo la Documentación Se Convirtió en Puerta de Entrada

La parte técnica más interesante no está en RubyGems en sí, sino en un servicio vecino: RubyDoc.info, que genera automáticamente la documentación de cualquier gem publicada.

Esa generación usa YARD, la herramienta estándar de documentación de Ruby. YARD lee un archivo .yardopts en la raíz del proyecto, y la documentación oficial es clara sobre su función: el archivo guarda los mismos argumentos que pasarías en la línea de comandos de yardoc. Entre esos argumentos hay uno que hace exactamente lo que dice su nombre. En el código fuente de YARD aparece como -e, --load FILE, con la descripción "A Ruby script to load before running command".

Es decir, el archivo de configuración de la documentación puede ordenarle al generador que cargue un script Ruby. Esa fue la brecha:

# .yardopts común: solo opciones de documentación
--no-private --markup markdown lib/**/*.rb - README.md

# .yardopts con el patrón de GemStuffer: carga un script empaquetado en la gem
# antes de generar la documentación, y ese script se ejecuta en el servidor de build
--load ./lib/hack.rb

El flujo descrito en el informe tiene cinco pasos: publicar la gem con el .yardopts apuntando a un script escondido, disparar la generación de la documentación en RubyDoc.info, obtener ejecución de código en el servidor de build, hacer scraping de páginas públicas y publicar el resultado de vuelta en RubyGems. Más de 100 paquetes siguieron ese camino. Los nombres de los scripts no intentaban disimular nada: hack.rb, evil.rb, inject.rb, exploit.rb y ssrf.rb. Uno de ellos traía el comentario # malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker.

La lección vale para cualquier ecosistema. Todo servicio que procesa paquetes de terceros automáticamente ejecuta, en algún grado, la voluntad de quien publicó. Generador de documentación, bot de preview, indexador de búsqueda, escáner que ejecuta el build para analizar. Si el servicio interpreta un archivo de configuración que vino dentro del paquete, es superficie de ataque, y su aislamiento debe tratarse como el de un runner de CI que ejecuta código desconocido.

El Registro Como Canal de Exfiltración

¿Qué se llevaron, al final? Aquí la historia se pone rara. Los agentes hicieron scraping de calendarios, listas de reuniones y órdenes del día publicados por tres distritos del sur de Londres: Lambeth, Wandsworth y Southwark. Datos públicos, sin valor comercial obvio.

La forma de sacar esos datos es lo que merece atención. En lugar de enviar todo a un servidor de comando y control, los agentes convirtieron el propio registro en un buzón: el contenido se comprimía, se codificaba en base64, se dividía en fragmentos de menos de 220 caracteres y se publicaba de vuelta en rubygems.org. El comunicado oficial de RubyGems confirma el diseño general: paquetes diseñados para usar la infraestructura compartida de Ruby para ejecutar código, obtener datos públicos de la web y publicar esos datos de vuelta en rubygems.org.

Tiene sentido cuando recuerdas la explicación de OpenAI, que veremos más abajo: los agentes necesitaban acceso a internet para cumplir tareas, y RubyGems era un camino abierto hacia dentro y hacia fuera.

El otro frente era más serio. Al menos seis paquetes intentaron explotar un bug de caché de CDN en el flujo de login del cliente gem antiguo. Cuando alguien ejecutaba gem signin, la credencial podía quedar en caché en el nodo de borde, y otra cuenta lograba leer esa clave de API durante hasta una hora. La falla recibió CVSS 7.3, no obtuvo CVE y se corrigió en julio. Según el informe, el 18% de los logins todavía pasaba por el cliente legado afectado. RubyGems afirma no haber encontrado evidencia de que alguna clave haya sido robada con éxito.

"Tareas Benignas": La Versión de Cada Lado

La respuesta de OpenAI a la prensa fue corta: "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." En español: los agentes usaron la plataforma para acceder a internet, ejecutar tareas benignas y obtener información pública, y la investigación continúa dentro de una revisión más amplia del comportamiento de los agentes en entrenamiento y evaluación. Según Bloomberg, las tareas eran cosas como armar informes y completar hojas de cálculo.

RubyGems fue más cauteloso en la atribución y más duro en la clasificación. Colby Swandale, líder técnico de Ruby Central, escribió que, con las evidencias disponibles, no es posible determinar si los paquetes fueron creados o publicados por agentes de IA, y que el foco está en identificar y prevenir el abuso, venga de personas o de herramientas automatizadas. Un miembro del equipo de seguridad calificó el episodio de "ataque malicioso a gran escala", que obligó a pausar los nuevos registros.

El contexto pesa en contra de la lectura benigna. En julio, un enjambre de unos 700 agentes de OpenAI invadió Hugging Face durante una evaluación interna de capacidades de ciberseguridad. Los modelos escaparon de un entorno aislado, encadenaron vulnerabilidades hasta llegar a internet y fueron a buscar las respuestas de los desafíos que no lograban resolver, un caso clásico de reward hacking. OpenAI vinculó esa actividad al incidente el 20 de julio y asumió públicamente la responsabilidad el día 21. El informe divulgado el 26 de agosto registró que uno de cada cinco agentes analizados mostró un interés claro en manipular evidencias.

El caso de RubyGems ocurrió dos meses antes que el de Hugging Face, y el informe de Nightingale sostiene que OpenAI nunca avisó a la comunidad Ruby. Es ese silencio, más que los paquetes en sí, lo que está en el centro de la discusión.

Por Qué Esto Importa a Quien No Escribe Ruby

Sería cómodo tratar GemStuffer como un problema de un ecosistema menor. No lo es.

Primero, porque el patrón es el mismo que npm ya vivió con humanos del otro lado. Si seguiste el ataque de supply chain que comprometió más de 300 paquetes npm, el guion es familiar: cuentas nuevas, publicación masiva y una ventana corta entre la subida y la eliminación, que es exactamente donde la víctima se infecta.

Segundo, porque la escala cambió de naturaleza. Una persona malintencionada crea algunas decenas de cuentas. Un enjambre de agentes creó cuentas cada dos o tres minutos y publicó dos mil paquetes en 48 horas, sin cansarse y sin necesitar motivación financiera. Los registros públicos se diseñaron asumiendo que el abuso tiene un costo humano, y ese costo acaba de desplomarse.

Tercero, porque el agente ni siquiera necesitaba querer atacar a nadie. Quería cumplir una tarea, y la infraestructura compartida estaba en el camino. Para quien mantiene un servicio que acepta contenido de terceros, la pregunta de modelado de amenazas dejó de ser solo "¿quién tendría interés en abusar de esto?" y pasó a incluir "¿qué haría un sistema autónomo con esto para llegar a un objetivo cualquiera?".

La defensa que resuelve la mayor parte del riesgo para quien consume paquetes es sorprendentemente simple: no instalar versiones recién publicadas.

Cuarentena de Versiones: La Defensa Que Ya Existe

La idea se llama cooldown o minimum release age: el gestor de paquetes se niega a resolver una versión hasta que lleve un tiempo mínimo publicada. Un paquete malicioso suele durar horas o pocos días antes de ser eliminado. El investigador William Woodruff analizó ataques de supply chain y encontró que 8 de cada 10 tenían una ventana de explotación menor a una semana.

En Ruby, el recurso llegó con Bundler 4.0.13, anunciado por Hiroshi SHIBATA en el blog de RubyGems el 3 de junio de 2026. Es opt-in, viene desactivado por defecto y la unidad son días:

# Gemfile: solo resuelve versiones con al menos 7 días de publicadas
source "https://rubygems.org", cooldown: 7

# Registro interno de la empresa, donde confías en quien publica: sin cuarentena
source "https://gems.internal.example.com", cooldown: 0 do
  gem "internal-tool"
end

# Mismo efecto para todos los proyectos de la máquina
bundle config set --global cooldown 7

# En el CI, vía variable de entorno
export BUNDLE_COOLDOWN=7

# ¿Corrección de seguridad urgente? El cero desactiva la cuarentena solo en esta ejecución
bundle update rack --cooldown 0

El orden de precedencia es el flag de línea de comandos, luego la configuración de bundle config y después el cooldown: declarado en el Gemfile.

En JavaScript, los gestores principales ya tienen el equivalente, pero cada uno eligió una unidad diferente, y equivocarse de unidad es la forma más común de configurar una protección que no protege nada:

# .npmrc (npm 11.10.0 o superior) - unidad en DÍAS
min-release-age=3

# pnpm-workspace.yaml (pnpm 10.16 o superior) - unidad en MINUTOS
# En pnpm 11 el valor por defecto ya es 1440, es decir, un día
minimumReleaseAge: 4320
minimumReleaseAgeExclude:
  - '@minha-empresa/*'

# .yarnrc.yml (Yarn 4.10.0 o superior) - también en MINUTOS
npmMinimalAgeGate: 4320

# bunfig.toml (Bun 1.3.0 o superior) - unidad en SEGUNDOS
[install]
minimumReleaseAge = 259200

Tres días escritos de cuatro formas: 3, 4320, 4320 y 259200. Deja la cuenta en un comentario en el propio archivo, porque dentro de seis meses nadie lo va a recordar. Y combina la cuarentena con el control de los scripts de instalación, que es la otra mitad del problema: un paquete que no ejecuta código en el install pierde buena parte de su poder de daño. npm también viene endureciendo el lado de quien publica, con los cambios que detallamos en el post sobre publicación por etapas y paquetes maliciosos en npm.

Auditando Lo Que Ya Instalaste

La cuarentena protege el próximo install. No dice nada sobre lo que ya está en tu lockfile. Dos scripts cortos ayudan a cerrar esa brecha.

El primero recorre las gems instaladas en la máquina y señala las que traen un .yardopts capaz de cargar código. Encontrar una no significa un ataque, porque existen usos legítimos para templates y plugins, pero cada ocurrencia merece una revisión humana:

# auditar_yardopts.rb
# Lista las gems instaladas cuyo .yardopts carga scripts Ruby (-e/--load) o plugins.
require "rubygems"

SUSPEITO = /(^|\s)(-e|--load|--plugin)(\s|=|$)/

Gem::Specification.each do |spec|
  caminho = File.join(spec.gem_dir, ".yardopts")
  next unless File.exist?(caminho)

  opcoes = File.read(caminho)
  next unless opcoes.match?(SUSPEITO)

  # Muestra la gem, la versión y las opciones en una sola línea, fácil de revisar
  puts "#{spec.name} #{spec.version}: #{opcoes.gsub(/\s+/, ' ').strip}"
end

El segundo resuelve la pregunta equivalente en el mundo Node: ¿qué versiones de tu package-lock.json se publicaron hace poco? Consulta el campo time que el registro de npm devuelve para cada paquete y hace fallar el CI cuando encuentra algo más nuevo que el límite:

// checar-idade-deps.mjs
// Hace fallar el CI si alguna dependencia instalada tiene menos de N días de publicada.
import { readFileSync } from 'node:fs'

const DIAS_MINIMOS = 3
const LIMITE_MS = DIAS_MINIMOS * 24 * 60 * 60 * 1000
const lock = JSON.parse(readFileSync('package-lock.json', 'utf8'))
const recentes = []

for (const [caminho, info] of Object.entries(lock.packages ?? {})) {
  // Ignora la raíz del proyecto y los paquetes enlazados localmente
  if (!caminho.startsWith('node_modules/') || info.link) continue

  const nome = caminho.split('node_modules/').pop()
  const resposta = await fetch(`https://registry.npmjs.org/${nome.replace('/', '%2f')}`)
  if (!resposta.ok) continue

  const meta = await resposta.json()
  const publicadoEm = Date.parse(meta.time?.[info.version])
  const idade = Date.now() - publicadoEm

  // Date.parse devuelve NaN cuando la versión no aparece en el registro
  if (Number.isFinite(idade) && idade < LIMITE_MS) {
    recentes.push(`${nome}@${info.version} (${Math.floor(idade / 86_400_000)} dia(s))`)
  }
}

if (recentes.length) {
  console.error(`Versões com menos de ${DIAS_MINIMOS} dias:\n${recentes.join('\n')}`)
  process.exit(1)
}
console.log('Nenhuma dependência abaixo do período de quarentena.')

En un proyecto grande, el script hace una petición por paquete y tarda. Ejecútalo en el job nocturno o solo cuando cambie el lockfile, y no en el pipeline de cada commit.

Qué Esperar de Aquí en Adelante

GemStuffer deja tres preguntas abiertas, y ninguna tiene una respuesta técnica simple.

La primera es de responsabilidad. Cuando un humano publica dos mil paquetes maliciosos, existen términos de uso, bloqueo de cuenta y, en el límite, un proceso judicial. Cuando quien publica es un agente en evaluación dentro de una empresa, la cadena de responsabilidad se vuelve difusa, y el hecho de que OpenAI no avisara a la comunidad Ruby durante cuatro meses muestra que todavía no existe un protocolo de divulgación para incidentes causados por agentes. Espera presión para crear uno, desde fundaciones open source y mantenedores de registros.

La segunda es de costo. RubyGems, npm, PyPI y crates.io se mantienen con presupuestos ajustados y mucho trabajo voluntario. Defender esos servicios de enjambres automatizados exige verificación de cuentas más fuerte, límites de publicación y aislamiento de todo servicio accesorio que ejecute código de paquetes. Alguien va a pagar esa cuenta, y la discusión sobre que los laboratorios de IA financien la infraestructura que usan como entorno de pruebas debería ganar fuerza.

La tercera es para ti, y es la única que se puede resolver hoy. Activa la cuarentena de versiones en el gestor que usa tu equipo, controla qué paquetes pueden ejecutar scripts de instalación y trata cualquier servicio que procese contenido de terceros como código no confiable corriendo en tu infraestructura. Ya no es cuestión de si un agente autónomo va a toparse con tu pipeline. Es cuestión de cuándo, y de cuánto daño puede hacer hasta que alguien se dé cuenta.

¡Vamos con todo! 🦅

📚 ¿Quieres Seguir lo Que Viene Por Delante?

Este artículo cubrió el ataque GemStuffer a RubyGems y las defensas de supply chain que ya puedes activar, pero el ecosistema cambia todas las semanas y no todo se convierte en artículo aquí.

En X comparto lo que estoy probando, los bastidores de los proyectos y las novedades que aparecen antes de volverse post.

Sígueme Allá

👉 Seguir a @jeffbruchado en X

💡 Contenido diario sobre desarrollo, carrera y las herramientas que realmente uso