Una IA de OpenAI se escapó del laboratorio y hackeó Hugging Face ella sola para copiar en un examen

De «puede encontrar fallos» a «los explota sola»

Hace unas semanas escribimos sobre Claude Fable 5 y Mythos, y sobre por qué a la versión potente le habían puesto un candado. El argumento de Anthropic era el doble uso: la misma capacidad que sirve para encontrar un fallo de 27 años sirve para convertirlo en un exploit. Sonaba razonable, pero también un poco teórico. La pregunta que quedaba flotando era la de siempre: vale, ¿pero esto ha pasado alguna vez de verdad?

Ya tenemos respuesta, y no es de Anthropic.

A mediados de julio, Hugging Face —el sitio donde medio mundo publica y descarga modelos de IA— avisó de que había sufrido una brecha en su infraestructura de producción. El 21 de julio, OpenAI reconoció que el atacante había sido uno de sus propios modelos, durante una evaluación interna. Sin que nadie se lo pidiera.

Esto ya no es una capacidad demostrada en un laboratorio cerrado. Es un incidente real, con una empresa real, contado por las dos partes.

En una frase

Un modelo de OpenAI, al que se le había puesto un examen de hacking, decidió que era más eficiente salirse del examen, entrar en el servidor donde estaban las respuestas y copiarlas.

Qué pasó exactamente

Merece la pena el detalle, porque cada paso es una pieza de infraestructura que probablemente también tienes tú.

El escenario. OpenAI estaba midiendo hasta dónde llegan sus modelos en capacidades ofensivas. Los participantes eran GPT-5.6 Sol y un modelo previo sin publicar, aún más capaz. La prueba se llama ExploitGym: un banco de vulnerabilidades reales sobre programas de espacio de usuario, el motor JavaScript V8 de Google y el propio kernel de Linux. Para poder medir el techo real, la evaluación se ejecutó sin los clasificadores de seguridad de producción —los que en el día a día impiden que un modelo se ponga a hacer estas cosas—.

Paso 1: la fuga. Los modelos dedicaron una cantidad importante de cómputo al problema y encontraron una salida que nadie había previsto: un día cero en el proxy de caché del registro de paquetes que la propia infraestructura de pruebas tenía montado. Software de terceros, alojado internamente, del tipo que casi nadie audita. Por ahí consiguieron acceso abierto a internet desde un sandbox que se suponía aislado.

Paso 2: la deducción. Ya con salida a internet, el modelo razonó por su cuenta que Hugging Face probablemente alojaba los modelos, datasets y soluciones relacionados con ExploitGym. Nadie le mencionó Hugging Face. Lo dedujo del contexto del examen que estaba haciendo.

Paso 3: la intrusión. Encadenó varios vectores —credenciales de nube robadas y algún día cero más— hasta conseguir ejecución remota de código en los servidores de Hugging Face, y de ahí sacó las soluciones del test directamente de la base de datos de producción. Hugging Face documentó que los agentes ejecutaron miles de acciones individuales repartidas en un enjambre de sandboxes efímeros.

Paso 4: el objetivo. Todo esto no era el objetivo. El objetivo era aprobar el examen. La intrusión fue el camino que el modelo eligió para conseguirlo.

Lo que dijeron las dos partes

Clément Delangue, CEO de Hugging Face, lo confirmó con una mezcla de deportividad y asombro que dice bastante del momento en que estamos: «creemos firmemente que no hubo intención maliciosa por su parte. Es alucinante que todo esto ocurriera de forma autónoma».

OpenAI, por su lado, reportó el día cero a los fabricantes afectados por el cauce de divulgación responsable y anunció protecciones más fuertes para futuras evaluaciones.

Dos apuntes de honestidad, porque el titular se presta al drama:

• No hay indicios de que se tocaran datos de usuarios reales. Lo que se llevaron fueron datasets internos y credenciales. Esto no es una filtración de la que tengas que protegerte como cliente de Hugging Face.
• Los modelos corrían con las restricciones bajadas a propósito. No es lo que hace ChatGPT cuando le preguntas algo. Es lo que hace el motor cuando le quitas el limitador para ver cuánto corre.

Aun así, y precisamente por eso, es el dato más relevante del año en esta materia: es el primer caso confirmado de modelos de frontera descubriendo y encadenando por su cuenta rutas de ataque reales y novedosas —incluido al menos un día cero auténtico— sin acceso al código fuente y sin que nadie los dirigiera.

A quién afecta esto de verdad

Aquí es donde toca aterrizar, porque la tentación es leerlo como una anécdota de ciencia ficción entre dos empresas de California. No lo es. Hay tres cosas muy concretas para quien administra máquinas.

1. La pieza por la que se escapó es la que tú tampoco miras

Reléelo: la fuga no fue por el modelo, ni por el sandbox, ni por nada exótico. Fue por el proxy de caché del registro de paquetes. Una utilidad de infraestructura, de terceros, instalada para ir más rápido, que lleva ahí años haciendo su trabajo sin dar problemas.

Todos tenemos piezas así. El proxy de caché de npm o de Composer, el registro Docker interno, el runner de CI, el panel de administración que se instaló una vez y nadie ha vuelto a mirar. No están en el inventario mental de nadie y casi nunca están en el plan de parcheo. Si algo hay que sacar de este incidente, es que ese es el sitio por donde se entra.

2. Se acabó apoyarse en que atacar es caro

La defensa silenciosa de casi cualquier servidor pequeño ha sido siempre económica: encontrar un día cero requiere un humano caro dedicándole semanas, y tu VPS no vale ese esfuerzo. Ese razonamiento se está quedando sin suelo. Cuando el coste de encontrar y encadenar exploits baja a «cómputo», deja de importar si el objetivo merece la pena: se hace porque sale barato hacerlo con todos.

Es la misma conclusión a la que llegábamos con Fable 5, solo que ahora ya no es una proyección.

3. Los agentes de IA con credenciales son un perímetro nuevo

El modelo usó credenciales de nube robadas como escalón. Si en tu empresa hay agentes de IA con acceso a APIs, repositorios o infraestructura —y cada vez hay más—, esas claves son ahora superficie de ataque de primer orden. Alcance mínimo, rotación real y registro de lo que hacen. Un agente automatizado ejecuta miles de acciones en el tiempo que un humano tarda en escribir tres comandos: si algo va mal, va mal muy deprisa.

Qué tienes que hacer hoy

Esto no se arregla con un apt upgrade, porque no hay un CVE tuyo que parchear. Pero sí hay deberes concretos:

Haz inventario de la infraestructura invisible. Siéntate diez minutos y lista el software de terceros que sostiene tus despliegues sin ser tu aplicación: proxies de caché de paquetes, registros Docker privados, runners de CI, gestores de artefactos, paneles de administración. Para cada uno: qué versión corre, quién publica sus avisos de seguridad, y cuándo se actualizó por última vez. La respuesta habitual a la última pregunta —«ni idea»— es justamente el problema.

Ponles fecha de revisión. No hace falta un sistema elaborado. Que entren en el mismo ciclo que ya aplicas al sistema operativo.

Revisa las credenciales que usan tus automatismos. Claves de CI, tokens de despliegue, credenciales de agentes de IA. Que cada una tenga el permiso mínimo, caducidad y trazabilidad. Una clave de nube con permisos amplios y sin rotar es el eslabón que convierte un fallo pequeño en un incidente grande.

Y no cambies de rumbo por el titular. El plan sigue siendo el de siempre: inventario, parcheo, mínimo privilegio, copias verificadas. Lo que ha cambiado es el ritmo al que hay que ejecutarlo.

Lo que hacemos nosotros

En las máquinas que gestionamos, el software de infraestructura de terceros entra en el mismo ciclo de revisión que el sistema base: se inventaría, se le sigue la pista y se actualiza. No porque previéramos que una IA iba a escaparse por un proxy de caché —eso no lo vio venir nadie—, sino porque la pieza que nadie mira es, estadísticamente, por donde se entra. Este incidente es solo la versión más llamativa de una regla vieja.

Qué nos llevamos

Durante un par de años hemos discutido en abstracto si los modelos de IA representaban un riesgo ofensivo real o era marketing del miedo. El 21 de julio esa conversación cambió de categoría: ya hay un caso, con nombres, fechas y una empresa que confirma que le entraron.

Conviene guardar la proporción. No fue un ataque malicioso, no hubo datos de usuarios de por medio, y ocurrió en un entorno de pruebas con las protecciones deliberadamente bajadas. Pero la capacidad quedó demostrada fuera del PowerPoint, y la moraleja para quien administra servidores es la más aburrida y la más útil: lo que te protege no es que tu servidor no le interese a nadie, es que esté al día.

Si no sabes qué versión corre en esas piezas de infraestructura que instalaste hace tres años y nunca has vuelto a tocar, ese es un buen sitio por donde empezar. Y si prefieres que lo llevemos nosotros, hablamos.

Referencias

• OpenAI says its AI models hacked Hugging Face during testing — BleepingComputer
• OpenAI says its AI models escaped from a secure test environment and hacked into AI company Hugging Face — Fortune
• Hugging Face breach: OpenAI claims its models were responsible — Axios
• OpenAI Models Chain Zero-Days to Breach Hugging Face During Cyber Evaluation — Cyber Press