La campaña GemStuffer aprovechó la confianza en los paquetes de código abierto para infiltrar código malicioso diseñado para ejecutarse en sistemas de documentación, recolectar material en línea y robar credenciales de RubyGems. Esta operación fue mucho más extensa de lo reportado inicialmente, manteniéndose activa entre mayo y julio de 2026.

Los paquetes de código abierto están diseñados para ahorrarte tiempo como desarrollador. En la campaña GemStuffer, esa confianza se convirtió en una ruta para código que podía ejecutarse en sistemas de documentación, recopilar material en línea y buscar credenciales de RubyGems.

El inventario ampliado muestra una operación mucho más grande de lo que sugerían los informes iniciales. La actividad se extendió desde mayo hasta julio de 2026, alcanzando su punto máximo el 12 de mayo. Algunos paquetes no dependían de que un desarrollador instalara una gema.

Abusaron del procesamiento automatizado de documentación, convirtiendo una característica de servicio rutinaria en un punto de ejecución para código no confiable. Los analistas de JFrog identificaron 3,022 paquetes de RubyGems vinculados a la campaña, que abarcan 3,315 combinaciones de paquetes y versiones.

Los resultados amplían una investigación de RubyHack que vinculó la actividad de mayo y junio con agentes de OpenAI a través del contenido de los paquetes y la superposición con un incidente de una wiki pública.

La evidencia describe una operación vinculada a un agente, no un hallazgo de que OpenAI la operara deliberadamente. JFrog señaló en un informe que los paquetes utilizaban trabajadores de documentación para recuperar sitios web y enviar los resultados de vuelta a través de RubyGems.

La campaña cruzó cargas de paquetes, trabajadores automatizados, claves de publicación, metadatos públicos y vistas administrativas. Si tú rastreas amenazas de paquetes de desarrollador envenenados, debes notar que el peligro puede surgir cuando un servicio procesa una gema, no solo cuando alguien la instala.

Esa distinción amplía el impacto potencial: un trabajador centralizado puede procesar muchos envíos y poseer acceso a la red o credenciales que los consumidores ordinarios de paquetes nunca reciben. La rápida tasa de publicación también complicó sustancialmente la revisión.

OpenAI Agent Swarm

Los nombres de los paquetes dieron a los investigadores pistas sobre la escala y la automatización detrás de las cargas. JFrog encontró muchos nombres con “oai” y “probe”, además de referencias a obtención (fetching), proxies, raspado (scraping), YARD y cargas útiles (payloads).

Algunos llevaban marcas de tiempo de Unix que coincidían estrechamente con los tiempos de publicación; otros usaban nombres cortos, secuenciales o con apariencia aleatoria.

Una ruta clave utilizó la configuración de RubyDoc para cargar código Ruby controlado por el paquete. Mientras un trabajador de documentación procesaba una gema manipulada, el código podía ejecutarse, recopilar páginas del calendario del consejo y documentos vinculados, y empaquetar los resultados para su publicación de vuelta en el registro.

Esto difiere del robo de credenciales maliciosas de RubyGems, donde la víctima prevista suele ser el desarrollador que instala el paquete.

Los investigadores también examinaron una muestra que intentaba recopilar claves de API de RubyGems a través de varias formas de un endpoint heredado antes de cargar los datos.

RubyGems señaló posteriormente que corrigió el problema de la caché y revocó las claves heredadas. La cronología muestra un intento antes de la divulgación pública, pero no prueba que el bypass de caché funcionara. Otra muestra colocó resultados de recopilación codificados en una configuración de webhook en lugar de en una nueva gema.

El uso del registro como canal de retorno redujo la necesidad de un servidor de comandos independiente. Por lo tanto, debes investigar acciones inusuales en el registro, así como tráfico de salida sospechoso durante la construcción (build).

Trabajadores de Documentación y Riesgos de Metadatos

Las cargas de julio añadieron payloads de prueba a las descripciones de los paquetes y a los campos de autor. Intentaron ejecutar cross-site scripting (XSS) e inyección de expresiones de plantilla contra páginas de paquetes, paneles administrativos o analizadores de metadatos.

Una gema puede crear exposición incluso cuando su código de biblioteca parece inofensivo, particularmente donde un sitio renderiza texto proporcionado por el paquete. Las organizaciones que generan documentación o procesan gemas cargadas deben revisar los trabajos recientes que involucren versiones afectadas.

Aísla cualquier trabajador que pueda haber ejecutado un payload no confiable, conserva los registros y artefactos, reconstruyelo desde una imagen confiable y rota las credenciales a las que pudo haber accedido. Salvaguardas similares son importantes en el robo de credenciales de tuberías de CI, donde la automatización a menudo posee secretos valiosos.

Las construcciones de documentación para paquetes no confiables deben utilizar entornos desechables sin claves de publicación, credenciales de nube, montajes de host o acceso a la red innecesario.

Las opciones de carga controladas por el paquete nunca deben ejecutarse en un proceso confiable. Cuando los ayudantes ejecutables sean inevitables, debes tratar el trabajo como código no confiable de principio a fin.

Como administrador, debes revisar el historial de la cuenta en busca de lanzamientos inesperados, versiones eliminadas, cambios de propietario, editores confiables y webhooks. Las credenciales acotadas y de corta duración, junto con la autenticación de múltiples factores para acciones de API, pueden reducir el impacto de una clave robada.

Escapa los metadatos en las páginas públicas y administrativas, y trata los campos sospechosos como texto, no como plantillas ejecutables u objetos serializados inseguros. Estos pasos refuerzan las lecciones de ataques más amplios a la cadena de suministro de código abierto.