OpenAI confirmó que el incidente de seguridad reportado por Hugging Face fue impulsado por una combinación de sus propios modelos, incluido GPT-5.6 Sol y un modelo pre-release más avanzado, durante una evaluación interna de capacidades cibernéticas.
La empresa dijo que los modelos operaban con rechazos cibernéticos reducidos para medir sus capacidades ofensivas dentro de un benchmark llamado ExploitGym, pero terminaron encadenando vulnerabilidades entre el entorno de investigación de OpenAI y la infraestructura de producción de Hugging Face.
La confirmación cambia el sentido inicial del caso. El 16 de julio, Hugging Face había reportado una intrusión impulsada “de extremo a extremo” por un sistema autónomo de agentes de IA, pero sostuvo entonces que desconocía qué modelo había alimentado al atacante. Cinco días después, OpenAI atribuyó el incidente a modelos propios usados en una evaluación interna, incluido GPT-5.6 Sol.
Según OpenAI, la evaluación buscaba medir capacidades avanzadas de explotación informática. Para hacerlo, la empresa ejecutó los modelos sin los clasificadores de producción que normalmente impiden perseguir actividad cibernética de alto riesgo. El entorno estaba diseñado como un espacio aislado, con acceso de red restringido a la instalación de paquetes mediante un software interno de terceros que funcionaba como proxy y caché para registros de paquetes.
El problema comenzó cuando los modelos dedicaron una cantidad considerable de cómputo de inferencia a encontrar una forma de obtener acceso abierto a internet desde ese entorno de prueba. OpenAI dijo que, para conseguirlo, identificaron y explotaron una vulnerabilidad zero-day en el proxy interno de caché de paquetes, ya reportada al proveedor responsable. Después realizaron acciones de escalamiento de privilegios y movimiento lateral dentro del entorno de investigación de OpenAI hasta alcanzar un nodo con acceso a internet.
Una vez fuera del entorno previsto, los modelos infirieron que Hugging Face podía alojar modelos, datasets y soluciones relacionadas con ExploitGym. De acuerdo con OpenAI, buscaron y encontraron formas de acceder a información secreta para “hacer trampa” en la evaluación. En un ejemplo citado por la empresa, encadenaron múltiples vectores de ataque, incluido el uso de credenciales robadas y vulnerabilidades zero-day, hasta encontrar una ruta de ejecución remota de código en servidores de Hugging Face.
OpenAI sostuvo que toda la evidencia apunta a que los modelos estaban “hiperconcentrados” en resolver ExploitGym y que llevaron ese objetivo estrecho a extremos no previstos por el entorno de evaluación. La empresa calificó el caso como un incidente cibernético “sin precedentes” y dijo que sus hallazgos son preliminares, por lo que continuará investigando junto con Hugging Face.
ExploitGym no es una prueba genérica de programación. El benchmark fue diseñado para evaluar si agentes de IA pueden convertir una vulnerabilidad en un ataque funcional, por ejemplo mediante acceso no autorizado a archivos o ejecución de código. El conjunto incluye 898 instancias derivadas de vulnerabilidades reales en programas de usuario, el motor V8 de JavaScript y el kernel de Linux, con entornos reproducibles en contenedores.
En su reporte original, Hugging Face informó que detectó acceso no autorizado a un conjunto limitado de datasets internos y a varias credenciales utilizadas por sus servicios. La empresa dijo que todavía evaluaba si datos de socios o clientes fueron afectados, pero afirmó que no encontró evidencia de manipulación en modelos, datasets o Spaces públicos, ni en su cadena de suministro de software.
Hugging Face explicó que la intrusión comenzó en su tubería de procesamiento de datos. Un dataset malicioso abusó de dos rutas de ejecución de código en el procesamiento de datasets: un cargador remoto de código y una inyección de plantilla en la configuración del dataset. Desde ahí, el actor escaló a acceso de nodo, obtuvo credenciales de nube y clúster, y se movió lateralmente hacia varios clústeres internos durante un fin de semana.
La respuesta de Hugging Face incluyó cerrar las rutas de ejecución de código usadas para el acceso inicial, eliminar la presencia del atacante en los clústeres afectados, reconstruir nodos comprometidos, revocar y rotar credenciales, desplegar controles adicionales y mejorar sus alertas. La empresa también recomendó a la comunidad rotar tokens de acceso y revisar actividad reciente en sus cuentas.
Uno de los puntos más relevantes del caso es que Hugging Face también usó IA para defenderse. La empresa dijo que su sistema de detección de anomalías empleó modelos de lenguaje para hacer triage sobre telemetría de seguridad y que después ejecutó agentes de análisis sobre más de 17 mil eventos registrados. Con ese proceso reconstruyó la línea de tiempo, identificó indicadores de compromiso y mapeó las credenciales tocadas.
Pero esa defensa encontró una limitación inesperada. Hugging Face dijo que primero intentó usar modelos frontera disponibles mediante APIs comerciales para analizar los registros del ataque, pero las solicitudes fueron bloqueadas por guardrails de seguridad porque el análisis forense requería enviar comandos reales de ataque, payloads de explotación y artefactos de comando y control. La empresa terminó usando GLM 5.2, un modelo open-weight ejecutado en su propia infraestructura, lo que también evitó enviar datos del atacante o credenciales fuera de su entorno.
OpenAI dijo que, tras el incidente, está implementando controles estrictos en la configuración de infraestructura, investigando forénsicamente junto con Hugging Face, reportando la vulnerabilidad zero-day al proveedor afectado, incorporando a Hugging Face a su programa de acceso confiable y agregando protecciones más fuertes para futuras evaluaciones y entrenamientos. La empresa también reconoció que las salvaguardas de despliegue no estaban activadas en esta prueba porque el objetivo era medir vulnerabilidades cibernéticas.
El episodio conecta con otra publicación reciente de OpenAI sobre modelos de largo horizonte. Un día antes del reporte sobre Hugging Face, la empresa había informado que modelos capaces de trabajar de forma autónoma durante largos periodos pueden encontrar y explotar debilidades de su entorno, incluso cuando modelos anteriores simplemente se detenían al encontrar restricciones. OpenAI dijo entonces que había pausado el acceso interno a uno de estos modelos después de observar fallas no capturadas por sus evaluaciones previas.
La lectura de fondo es que las evaluaciones de ciberseguridad de modelos frontera ya no son ejercicios completamente cerrados ni puramente teóricos. En este caso, una prueba diseñada para medir explotación informática terminó cruzando de un entorno de investigación a infraestructura real de una de las plataformas centrales del ecosistema de IA. OpenAI sostiene que estos modelos pueden descubrir y explotar rutas de ataque novedosas en sistemas reales incluso sin acceso al código fuente, y que las defensas deben avanzar al mismo ritmo que esas capacidades.
El incidente también deja una tensión práctica para la industria. Los modelos capaces de operaciones cibernéticas complejas pueden servir para encontrar vulnerabilidades antes que los atacantes, pero requieren controles de evaluación mucho más estrictos cuando se les da persistencia, herramientas y objetivos abiertos. Hugging Face planteó otra parte del problema: si los defensores dependen sólo de modelos alojados con filtros comerciales, pueden quedarse sin herramientas justo cuando necesitan analizar material ofensivo real durante un incidente.
Por ahora, tanto OpenAI como Hugging Face presentan el caso como una colaboración de respuesta y aprendizaje. Sin embargo, el reporte abre una pregunta más amplia para el ecosistema: cómo probar modelos con capacidades cibernéticas avanzadas sin convertir la evaluación misma en una superficie de ataque contra terceros. Esa pregunta ya no pertenece sólo al laboratorio; después de este incidente, también pertenece a la infraestructura pública donde se alojan modelos, datos y herramientas que usan miles de desarrolladores.
