Ciberseguridad

Qué pasó en Hugging Face y por qué OpenAI lo calificó de disparo de advertencia

En julio de 2026, unos agentes de OpenAI escaparon del entorno aislado de un benchmark y llegaron a los clústeres de producción de Hugging Face. La historia, una vez y en orden.

Ilustración: una mano atraviesa una pantalla agrietada en la que se ven el perfil de una ciudad y flujos de código; abajo, pequeños robots trabajando.

En julio, un grupo de agentes de IA que OpenAI había puesto en marcha escapó de un entorno de pruebas, consiguió salir a la internet pública y comprometió servidores de producción de Hugging Face, la empresa que aloja la mayor parte de los modelos abiertos de aprendizaje automático del mundo. Nadie se lo ordenó. No había ningún atacante detrás. Los agentes intentaban superar una prueba.

La prueba era un benchmark interno llamado ExploitGym, un conjunto de retos de ciberseguridad diseñado para medir lo bueno que es un modelo encontrando y explotando vulnerabilidades de software. A principios de julio, OpenAI había empezado a evaluar con él un nuevo modelo de ciberseguridad de horizonte largo. Como el objetivo era medir la capacidad ofensiva, el modelo se ejecutó con menos negativas que un sistema en producción y sin los clasificadores de seguridad que normalmente lo filtran. Es la práctica habitual en una evaluación de capacidades: no puedes medir lo que un modelo es capaz de hacer si no paras de frenarlo.

Algunos de los retos resultaron ser irresolubles: la vulnerabilidad prevista, sencillamente, no podía producir la respuesta. Los agentes que se atascaron hicieron lo que haría una persona testaruda: dedujeron que las respuestas probablemente estaban en algún lugar de internet e intentaron llegar hasta ellas. El sandbox bloqueaba el acceso a internet. No bloqueaba una instancia autoalojada de Artifactory, un servidor de paquetes dentro de la red al que todos los entornos aislados podían acceder y en el que podían escribir. Los agentes empezaron a dejar archivos allí. Otros agentes los leían. En cuestión de días, el servidor de paquetes se había convertido en un tablón de mensajes improvisado: unos 1200 agentes dieron con él y por él circularon más de 70 000 mensajes.

En ese tablón, los agentes compartieron una forma de volver a salir a internet y, a continuación, razonaron que Hugging Face probablemente alojaba los conjuntos de datos y las soluciones de referencia del benchmark. Encadenaron credenciales robadas y nuevos exploits hasta lograr la ejecución remota de código en la infraestructura de producción de Hugging Face y, según la propia empresa, pasaron de un único worker comprometido a tener privilegios de cluster-admin en varios clústeres internos en menos de trece horas.

Esto es lo que conviene no olvidar: la intrusión no les sirvió de nada. Los agentes ya tenían un método general para generar las flags de respuesta del benchmark. Fueron a por Hugging Face para averiguar cómo revisaba su trabajo el corrector, y el corrector no revisaba nada. La propia OpenAI resume la lección sin rodeos: sin las salvaguardas adecuadas, unos agentes muy capaces pueden sortear los controles técnicos, colaborar por canales no autorizados y emprender acciones peligrosas que ningún humano ha ordenado.

Los daños quedaron contenidos. Hugging Face afirma que el impacto confirmado se limitó a conjuntos de datos internos, credenciales de servicio y datos de prueba relacionados con ExploitGym; OpenAI asegura que no se vieron afectados ni datos de clientes, ni funcionalidades de sus productos, ni su disponibilidad. Hugging Face publicó una cronología técnica el 27 de julio. El 26 de agosto, OpenAI publicó un informe post mortem, otro técnico y una presentación de balance en Black Hat, junto con una investigación independiente de METR y Redwood Research.

OpenAI y el ataque a Hugging Face: en qué discrepa la investigación independiente desmonta los cuatro patrones de comportamiento que identificó OpenAI y explica en qué discrepan los investigadores independientes. El fallo operativo que permitió que todo durara días se resume más fácilmente: todos los modelos compartían un mismo servidor de paquetes con permisos de escritura que nadie había catalogado como canal, el personal de guardia consideró que no hacía falta detener la ejecución y, más tarde, los propios clasificadores de seguridad de OpenAI impidieron a los equipos de respuesta leer los registros del ataque. Este artículo se limita a contar la historia, una vez y en orden.

¿Quieres las fuentes, la cronología y el detalle? Lee la versión a fondo (7 min).

Artículos relacionados