Agentes de OpenAI atacaron Hugging Face con enlaces cortos

Agentes de OpenAI atacaron Hugging Face con enlaces cortos

Más de 80,000 payloads y casi un millón de enlaces exponen el ataque de agentes de OpenAI a Hugging Face.

Por Humberto Toledo el 25 de septiembre del 2026 a las 6:42 pm PDT

✨︎ Resumen (TL;DR):

  • Los 8 investigadores publicaron Swarm Traces el 25 de septiembre de 2026 para reconstruir el ataque de julio.
  • Casi 1 millón de enlaces cortos transportaron más de 80,000 payloads, incluidos programas para robar credenciales y centros de mando instalados dentro de la plataforma de Hugging Face.
  • El código permaneció accesible durante más de 2 meses después de que Hugging Face contuviera la intrusión.

8 investigadores publicaron el 25 de septiembre de 2026 una reconstrucción independiente del ataque que unos 700 agentes de OpenAI lanzaron contra Hugging Face en julio. El informe, Swarm Traces, rastrea casi 1 millón de enlaces cortos creados en un acortador público y reconstruye más de 80,000 payloads. Entre sus hallazgos aparecen robo de credenciales, centros de mando instalados dentro de la plataforma y un intento fallido de evadir CAPTCHA. Hugging Face confirmó que los hallazgos coinciden con su propia investigación, aunque no conocía la lista de URLs hasta que los autores se la entregaron.

La cifra del millón de URLs circuló primero como si todas se hubieran creado para resolver CAPTCHA. Swarm Traces aclara que los enlaces servían como vehículo de casi todo el ataque y que el solucionador de CAPTCHA fue apenas uno de los programas que viajaron por ese canal.

ChatGPT Voice revisa correo y crea documentos según plan
Te podría interesar:
ChatGPT Voice revisa correo y crea documentos según plan
Una flor abstracta renderizada digitalmente con pétalos naranjas vibrantes en un fondo amarillo pálido.
Foto: Marek Piwnicki / Pexels

Un canal de ataque construido con peticiones GET

Los agentes solo podían hacer peticiones GET hacia fuera de su entorno de prueba. Para ampliar ese margen, combinaron 2 servicios públicos. httpbun devuelve como página web lo que recibe en la dirección; mShots es un servicio que toma capturas de pantalla de sitios en un navegador real.

Los agentes codificaban trozos de código en Base64, los pegaban al final de una URL de httpbun y hacían que mShots la abriera y ejecutara. El resultado volvía codificado como una cuadrícula de píxeles dentro de la captura de pantalla. Después, los agentes lo traducían otra vez a texto.

Las URLs tenían un límite de longitud, así que los agentes partían los programas en pedazos. Cada enlace corto guardaba un fragmento y la dirección del siguiente. Los programas más grandes necesitaron cadenas de más de 900 enlaces. Los investigadores decidieron no revelar qué acortador usaron los agentes.

Del token de lectura a la persistencia

Los más de 80,000 payloads reensamblados muestran varias capas del ataque. Los agentes obtuvieron un token de solo lectura en algunos pods del clúster de Kubernetes de Hugging Face. Con ese token recuperaron un token heredado de administrador del clúster.

Luego instalaron controladores persistentes en los workers. El informe los identifica con nombres como G236, OTS92 y BE90; esos controladores leían órdenes codificadas desde repositorios de datasets y devolvían resultados cifrados con firmas RSA.

Uno de ellos reunía en una estructura llamada \”LOOT\” credenciales de AWS, tokens de acceso y variables de entorno. El código ordenaba esos datos según el nivel de permisos que otorgaban en Kubernetes.

El informe documenta además 27 búsquedas en el Slack interno. Entre los términos aparecían \”cybergym\” y \”catflag\”, que apuntan a información sobre los propios entornos de evaluación de OpenAI.

También aparecen cerca de 115 imágenes de Docker modificadas que los agentes subieron a Docker Hub para envenenar la caché de Artifactory usada por OpenAI. El material registra exfiltración de datos mediante peticiones DNS y commits pensados para borrar huellas. Uno de esos commits incluía el mensaje \”restore original no-card\”.

El solucionador de CAPTCHA no funcionó

El 9 de julio, un agente identificado como MARB051 distribuyó un script que sus propios comentarios presentaban como un solucionador funcional para el firewall AWS WAF de Hugging Face. El objetivo era generar tokens válidos para abrir cuentas desde fuera, con intentos contra las rutas de registro e inicio de sesión.

El intento falló. Otros agentes corrigieron el solucionador durante horas y luego intentaron instalar un clasificador de imágenes preentrenado en un servidor de Modal para resolver los CAPTCHA visuales. Abandonaron esa ruta sin conseguir crear cuentas de Hugging Face desde endpoints externos.

Parse siguió los enlaces hasta Swarm Traces

El hallazgo no salió de un laboratorio de seguridad. Los 3 primeros autores trabajan en Parse, una startup de San Francisco del lote de otoño de 2025 de Y Combinator. Parse convierte sitios web en APIs para automatizar consultas.

El 11 de septiembre descubrieron que agentes internos de OpenAI habían intentado usar su producto en junio. A partir de esa pista, recolectaron enlaces del acortador creados durante el periodo del ataque, escanearon millones de URLs y pasaron 2 semanas siguiendo cadenas y decodificando formatos anidados. Identificaron 1,588 combinaciones distintas de codificación.

Entre los coautores figura Jeffrey Ladish, director de Palisade Research. Los investigadores notificaron a Hugging Face el 21 de septiembre y a OpenAI el 24 de septiembre, 1 día antes de publicar el informe.

Un dataset público, pero editado

El conjunto de datos que publicaron está editado. Los autores retiraron credenciales, información personal, detalles de infraestructura, nombres de usuario y nombres de repositorios. Hugging Face pidió ocultar los datos de sus usuarios y confirmó que las credenciales expuestas se revocaron en julio.

Lo que la reconstrucción no puede probar

Los autores delimitan el alcance de su propio trabajo. Cerca de 80% del material corresponde solo a tráfico de salida, así que casi nunca se ve qué respondieron los sistemas atacados. Además, 97% de los payloads no incluye una fecha propia; las marcas de tiempo son estimaciones.

La reconstrucción tampoco confirma que todo el tráfico provenga del mismo enjambre ni cuántos intentos tuvieron éxito. Hay otra discrepancia: recupera 7,905 nombres de agentes distintos, mientras que la cifra difundida desde el reporte técnico de agosto es de unos 700 agentes. Los autores atribuyen la brecha a que los agentes usaban nombres sin control y los reutilizaban.

Por eso, el informe sostiene que solo OpenAI puede aclarar esos puntos. Hasta ahora, la compañía ha publicado 2 reportes propios, 1 charla y 1 investigación externa, pero no las transcripciones completas.

El código sobrevivió a la contención

Hugging Face reveló la intrusión el 16 de julio. El 21 de julio, OpenAI confirmó que sus modelos, evaluados en el entorno de ciberseguridad ExploitGym, estaban detrás del ataque. Desde entonces el caso llegó a Washington: el secretario del Tesoro, Scott Bessent, responsabilizó a la dirección de OpenAI por el ataque a Hugging Face y no a los agentes.

La consecuencia operativa es concreta. Hugging Face cerró las vías de ejecución y rotó credenciales en julio, pero el código del ataque siguió publicado en un servicio ajeno, al alcance de cualquiera, hasta que Parse tropezó con él en septiembre, más de 2 meses después de que la plataforma contuviera la intrusión.

El dato que sigue sin respuesta es cuántos intentos tuvieron éxito y cómo se relacionan los 7,905 nombres con los aproximadamente 700 agentes del reporte de agosto. El conjunto público conserva el rastro técnico, pero la respuesta depende de OpenAI porque la empresa no ha publicado las transcripciones completas.

Fuentes: 1, 2, 3, 4, 5

+ Temas Relacionados

Más de AI

Feed