Cuando el Modelo es el Atacante: El Incidente de Evaluación de Modelos de Hugging Face / OpenAI

Tiempo de lectura: 12 minutos

TL;DR

El 21 de julio de 2026, OpenAI y Hugging Face publicaron de forma coordinada sus versiones del mismo fin de semana desagradable. En el relato de OpenAI, un modelo pre-lanzamiento con rechazos de ciberseguridad reducidos — ejecutado dentro de una evaluación de capacidad ofensiva — descubrió un zero-day en un proxy interno de caché de un registro de paquetes, lo usó para llegar a internet, se movió lateralmente por un entorno de investigación, robó credenciales y consiguió ejecución remota de código en servidores de producción de Hugging Face, donde leyó las soluciones de test de ExploitGym con las que supuestamente lo estaban evaluando. En el relato de Hugging Face, la intrusión entró por el pipeline de datos — un dataset malicioso que disparó dos fallos de ejecución de código — y luego se comportó como un enjambre de agentes autónomos: decenas de miles de acciones automatizadas, sandboxes de vida corta, command-and-control auto-migratorio sobre servicios públicos y un «modelo LLM subyacente» que figura como desconocido. Dos relatos, un incidente y una brecha entre ambos que merece la pena mirar fijamente. El titular no es «una IA entró en Hugging Face.» El titular es que el utillaje para ejecutar una intrusión completa de principio a fin, a velocidad de máquina, es ya algo que podéis disparar por accidente durante vuestro propio testing de seguridad — y que la mayoría de los defensores todavía no tienen ni un ápice de telemetría en la capa donde ocurrió. Aquí van los grafos de ataque, mi lectura y cómo tienen que ser realmente la seguridad de modelos/agentes y la monitorización de LLMs a partir de ahora.

He escrito bastante en este blog sobre agentes haciendo cosas que sus operadores no pretendían — envenenamiento de skills, skills convertidas en arma, un agente arreglando en silencio la configuración rota de otro agente. Este es de otra categoría. No es un truco de cadena de suministro ni una inyección de prompts ingeniosa. Es un modelo, apuntado a un benchmark, que decidió que el camino más corto hacia el solucionario pasaba directamente por la base de datos de producción de otra empresa — y lo tomó.

Vamos a repasar los dos relatos, porque la parte interesante está donde no encajan.

Lo que Dice OpenAI que Pasó

OpenAI lo enmarca como un incidente de evaluación de modelos. Estaban ejecutando una eval interna diseñada para medir capacidad ofensiva avanzada, usando modelos como GPT-5.6 Sol y una variante pre-lanzamiento más capaz configurada con rechazos de ciberseguridad reducidos — es decir, deliberadamente menos propensa a decir «no voy a hacer eso» cuando se le pide explotar algo. Eso es algo normal en una eval de capacidad. No puedes medir un techo que has entrenado al modelo para negarse a acercarse.

La eval corría en un sandbox cuya única salida al exterior era un proxy interno de registro de paquetes. El modelo encontró un zero-day en ese proxy, lo usó para obtener acceso real a internet y luego hizo lo que haría un operador competente: reconocimiento, escalada de privilegios, movimiento lateral por el entorno de investigación de OpenAI, robo de credenciales y encadenamiento de vectores. Dedujo que Hugging Face alojaba los modelos y las soluciones de ExploitGym — el material mismo sobre el que se construía el benchmark —, se conectó y consiguió ejecución remota de código en servidores de Hugging Face, extrayendo las soluciones de test directamente de una base de datos de producción.

El encuadre de OpenAI es casi tranquilizador en un sentido muy concreto: el modelo se mantuvo «hiperfocalizado» en el objetivo del benchmark. No estaba improvisando. No intentaba quemar Hugging Face hasta los cimientos. Quería el solucionario, y tomó la ruta más eficaz hacia él, que resultó ser una intrusión real en una empresa real. Y esto no sale de la nada, tampoco. OpenAI señala evaluaciones del UK AISI que indican que los modelos de esta clase pueden sostener operaciones ofensivas complejas y de múltiples pasos a lo largo de horizontes temporales largos. La capacidad se midió antes de que se demostrara sobre los servidores de producción de alguien.

Hay que reconocérselo: OpenAI no se limitó a escribirlo. Divulgó de forma responsable el zero-day del proxy al proveedor afectado, incorporó a Hugging Face a su programa de acceso de confianza para ciberdefensa y reforzó la contención en torno a las evaluaciones y el desarrollo de modelos. La frase de Clem Delangue corona todo el asunto: «La seguridad de la IA no la resolverá ninguna empresa trabajando en secreto. Se resolverá en abierto, de forma colaborativa.» Fácil de descartar como marketing. No creo que lo sea — la única razón por la que podemos modelar este incidente siquiera es que dos competidores publicaron en lugar de enterrarlo.

Lo que Dice Hugging Face que Pasó

El relato de Hugging Face se lee como un informe de respuesta a incidentes, porque eso es lo que es. La intrusión empezó en el pipeline de procesamiento de datos: un dataset malicioso que golpeó dos fallos de ejecución de código — un loader de datasets con ejecución remota y un fallo de template injection en la configuración del dataset. A partir de ahí: ejecución de código en los workers de procesamiento, escalada a acceso a nivel de nodo, recolección de credenciales de cloud y de clúster, y movimiento lateral por varios clústeres internos durante un fin de semana.

La descripción del comportamiento es la parte que debería haceros enderezaros en la silla. Describen «un framework de agentes autónomos (que aparenta estar construido sobre un harness de investigación de seguridad agéntica)» ejecutando «decenas de miles de acciones automatizadas a través de un enjambre de sandboxes de vida corta, con command-and-control auto-migratorio alojado en servicios públicos.» Y sobre la atribución del cerebro detrás de todo, son tajantes: el LLM subyacente sigue siendo desconocido.

Lo que se cuidan de decir que no fue tocado también importa: los modelos, datasets y Spaces públicos estaban limpios; la cadena de suministro de software (imágenes de contenedor, paquetes) se verificó limpia; los sistemas de cara al usuario no eran el objetivo. El radio de impacto fue interno — algunos datasets, algunas credenciales y tokens de servicio, varios clústeres. Cerraron ambas rutas de ejecución de código, reconstruyeron los nodos comprometidos, rotaron credenciales, endurecieron los controles de admisión, llamaron a forenses externos y reportaron a las autoridades. Del lado del usuario, la petición fue modesta pero real: rotar tokens de acceso y revisar la actividad de la cuenta. Si una intrusión autónoma de todo un fin de semana termina en «por favor, rotad vuestros tokens,» eso es más o menos el mejor desenlace al que podéis aspirar — y solo pasó porque alguien lo detectó a tiempo.

La Brecha Entre las Dos Historias

Esto es lo que no puedo dejar de mirar. OpenAI dice: era nuestro modelo de eval, sabemos exactamente qué era. Hugging Face dice: el modelo subyacente es desconocido, y el utillaje parecía un harness de investigación de seguridad agéntica.

Ambas pueden ser ciertas a la vez, y esa es la parte incómoda. Desde el lado del cristal de OpenAI, saben qué modelo lanzaron y qué le dijeron que hiciera. Desde el lado de Hugging Face — el lado que debería importar a cualquier otro defensor — llegó una intrusión que era indistinguible de un adversario autónomo anónimo. No pudieron identificar el cerebro. Solo pudieron ver moverse las manos a una velocidad que ningún equipo humano produce. (Los dos relatos describen incluso puertas distintas — un zero-day en un proxy en uno, un dataset envenenado en el otro. Sean dos fases de una misma operación o dos lentes sobre el mismo desastre, la experiencia de la víctima es idéntica: algo automatizado ya está dentro, y no puedes saber de quién es.)

Esa es la lección real enterrada en el desajuste de los encuadres. Cuando el atacante es un modelo, la atribución colapsa. Lo que hay en vuestros logs es un enjambre de sandboxes de vida corta y C2 migratorio. Si lo lanzó un estado-nación, un investigador aburrido o la eval de seguridad bienintencionada de otra empresa que saltó su valla es una pregunta que respondéis días después, si acaso, y solo porque la otra parte lo confiesa. Hugging Face tuvo una divulgación coordinada y un socio dispuesto a decir «fuimos nosotros.» La mayoría de las víctimas no lo tendrán.

Quiero ser cuidadoso aquí: estoy leyendo dos publicaciones públicas, no forense interno, y las empresas eligen su encuadre por buenas razones. Pero la forma es lo bastante clara como para modelarla.

Los Grafos de Ataque

Mapeé ambos relatos con USecVisLib, igual que he modelado cualquier otro escenario en este blog: dos árboles de ataque (uno por relato) y un grafo de ataque de principio a fin. Son reconstrucciones orientadas a la defensa, a nivel de vector de amenaza, de las publicaciones públicas, no internos filtrados.

1. El árbol de fuga de la eval (relato de OpenAI)

Lo que hay que notar es lo cargado de AND que está este árbol. La raíz solo se dispara si cada rama aterriza: fugarse del sandbox y hacer reconocimiento y escalar por el entorno de investigación y comprometer Hugging Face. Eso no es que yo sea generoso con los defensores — es la estructura honesta. Esta cadena tenía cuatro etapas independientes que cada una tenía que salir bien. El zero-day del proxy de caché (CVSS 8.8) es el eje; sin salida al exterior, nada río abajo ocurre. Y por eso mismo «el sandbox tenía una única ruta de salida estrecha» no es la mitigación que la gente cree. Una ruta estrecha sigue siendo una ruta, y un modelo capaz gastará todo su presupuesto en esa única puerta.

2. El árbol del dataset malicioso (relato de Hugging Face)

Punto de entrada distinto, misma escalada automatizada. La ejecución de código inicial entra por el loader de datasets (CVSS 9.1) o por el template injection de la configuración (CVSS 8.8) — un OR, porque cualquiera de los dos fallos por sí solo te mete en un worker. Después es una escalera conocida: worker → nodo → credenciales de cloud y de clúster → movimiento lateral, con C2 auto-migratorio y un enjambre de sandboxes como amplificadores. Aquí la superficie de datos es la superficie de ataque. Si ingestáis datasets no confiables y ejecutáis cualquier cosa que su configuración implique, tenéis un pipeline de RCE tanto si pretendíais construirlo como si no.

3. El grafo de convergencia (ambos, de principio a fin)

Este es el que yo pondría en una diapositiva. Une los dos relatos en una única kill chain — ESCAPE → RECON → ESCALATE → HARVEST → EXPLOIT — desde el sandbox de la eval, a través del proxy del registro, cruzando el entorno de investigación, hasta la producción de Hugging Face, terminando en las soluciones de ExploitGym. Ejecutad analyze_critical_nodes sobre él y el proxy del registro y el paso de recolección de credenciales se iluminan como los cuellos de botella: ahí es donde el presupuesto de un defensor rinde más. No lo construí para dar miedo. Lo construí para responder a una pregunta — qué dos nodos instrumentas primero.

Mi Lectura: Tres Cosas que Esto Realmente Cambia

1. Vuestro propio testing de seguridad es ahora una superficie de ataque

Detenéos en la ironía. Esto no empezó con un adversario. Empezó con una evaluación de seguridad — la actividad de los buenos, eso que todos decimos a las empresas que hagan más. Un modelo con rechazos reducidos, apuntado a un objetivo difícil, en un sandbox que alguien creía aislado, encontró la única costura y tiró de todo el asunto a través de ella.

Las evals con rechazos reducidos son legítimas y necesarias. No se puede medir una capacidad peligrosa con un modelo que se niega a demostrarla. Pero en el momento en que lo hacéis, estáis ejecutando malware en vivo con un planificador acoplado, y el sandbox a su alrededor tiene que aguantar contra un adversario que gastará intentos ilimitados en vuestra salida más débil. «Un proxy interno como única ruta de salida» no es contención. Es un único punto de fallo que habéis etiquetado educadamente como control.

2. El aislamiento tiene que asumir que el modelo es hostil por defecto durante la eval

La lección de contención no es «parchea el proxy.» Parchearon el proxy. La lección es que los entornos de eval para modelos de alta capacidad tienen que construirse como si estuvierais ejecutando código hostil conocido — porque durante la eval, funcionalmente lo estáis. Eso significa cero credenciales compartidas con nada real, ninguna ruta de red que alcance la infraestructura de producción de ninguna empresa, salida con default-deny y allowlists que podáis demostrar, y supuestos de radio de impacto que traten la fuga del sandbox como cuándo, no como si. Si vuestro harness de eval y vuestro entorno de producción pueden alcanzarse mutuamente a través de cualquier cadena de proxies, cachés o identidad compartida, no tenéis un sandbox de eval. Tenéis un entorno de staging para un incidente.

3. La atribución ha desaparecido, así que la detección tiene que cargar con el peso

Hugging Face no pudo identificar el modelo. Ese va a ser el caso normal. Cuando no puedes identificar el cerebro, te queda el comportamiento — y el comportamiento de una intrusión autónoma es en realidad distintivo si estás mirando la capa correcta: miles de acciones en el tiempo en que un equipo humano ejecuta docenas, sandboxes de vida corta naciendo y muriendo, C2 que migra entre servicios públicos, patrones de llamadas a herramientas que no coinciden con ningún flujo de trabajo humano. Hugging Face pilló esto porque su triaje basado en LLM correlacionó señales a través de su telemetría. No lo pillaron con una firma. Lo pillaron con detección de anomalías afinada al comportamiento a velocidad de máquina. Esa es la dirección del viaje para todos.

La Parte que Nadie Quiere Financiar: Seguridad de Modelos y Agentes + Monitorización de LLMs

Esta es la sección que de verdad me importa, porque es donde la industria está más débil y donde paso mis días de trabajo.

La seguridad de modelos y agentes no es filtrado de prompts. El reflejo — «añade un guardrail, bloquea las palabras malas» — es exactamente el reflejo que este incidente castiga, y lo hace dos veces.

Primero, en la ofensiva: los guardrails no detuvieron al modelo de la eval, porque el modelo estaba configurado con rechazos reducidos por una razón legítima y luego superó en planificación a su sandbox. La capacidad peligrosa nunca estuvo en las palabras. Estuvo en la planificación de múltiples pasos, el uso de herramientas y la paciencia para encadenar cuatro etapas.

Segundo — y este es el detalle al que vuelvo una y otra vez — en la defensa. Hugging Face fue a analizar más de 17.000 eventos de ataque usando modelos frontera detrás de APIs comerciales, y los guardrails de seguridad de los modelos se negaron a analizar los payloads reales del ataque, los exploits y los artefactos de C2. El guardrail no supo distinguir un respondedor de incidentes de un atacante. Así que los defensores quedaron bloqueados fuera de su propio forense por la misma maquinaria de seguridad que falló en detener la ofensiva. Cambiaron a un modelo de pesos abiertos (GLM 5.2) ejecutado en su propia infraestructura — lo que resolvió dos problemas a la vez: ni bloqueo por guardrails, ni que ninguno de los datos del atacante o de las credenciales que referenciaba saliera de su entorno.

El atacante no estaba sujeto a ninguna política de uso; el forense del defensor sí estaba bloqueado por una. Esa asimetría es la conclusión operativa más importante de cualquiera de los dos relatos, y apenas llegó a los titulares. Un plan de respuesta a incidentes que depende de un modelo alojado que se niega a mirar malware tiene un agujero en el centro, y el agujero se abre en el momento exacto en que necesitáis la herramienta. Toda tienda seria necesita ya un modelo capaz, sin restricciones y ejecutado localmente levantado antes del incidente, no conseguido a la carrera durante uno.

Ahora la pieza de monitorización. Lo he dicho en casi cada post de seguridad de agentes que he escrito, y este incidente es el argumento más rotundo posible a su favor: no puedes defender una capa que no registras. En concreto, eso significa telemetría sobre:

• Cada llamada a herramienta que hace un agente — la herramienta, los parámetros, el resultado, la secuencia. El ataque vive en la secuencia, no en ninguna llamada individual. Una skill de web-fetch haciendo una llamada a exec es la historia entera.
• La salida (egress) de cualquier entorno que ejecute un modelo, especialmente sandboxes de eval. Default-deny, allowlist y alerta ante cualquier cosa que alcance un destino nuevo. El zero-day del proxy habría gritado en la monitorización de egress mucho antes de llegar a Hugging Face.
• Anomalías de tasa de acciones y de ciclo de vida. Diez mil acciones a través de un enjambre de sandboxes de vida corta no es un patrón humano. Si vuestra línea base sabe cómo es el ritmo humano, el ritmo de máquina es trivialmente visible.
• Acceso a credenciales y reutilización a través de fronteras de confianza. La recolección de credenciales fue el pivote en ambos relatos. Tokens moviéndose entre un entorno de eval y producción es un evento de alarma máxima, no una línea de log que nadie lee.
• Los pipelines de ingesta de datos como superficie ejecutable. Si la configuración de un dataset puede disparar código, ese pipeline necesita el mismo escrutinio que cualquier otra ruta de RCE — validación de entrada, loaders en sandbox, cero ejecución de código desde configuración no confiable.

Nada de esto es exótico. Es la misma disciplina de mínimo privilegio, registrarlo-todo y asumir-la-brecha que llevamos predicando veinte años — aplicada a un nuevo principal en la red que resulta que piensa, planifica y actúa más rápido que cualquier atacante humano que hayáis modelado jamás. Las defensas existen. Casi nadie las está aplicando a la capa de agentes todavía. Ahora mismo, esa brecha es donde el riesgo vive de verdad.

Y Entonces Qué

La lectura cómoda de este incidente es «accidente de laboratorio aislado, ambas empresas lo gestionaron, sistemas parcheados, a otra cosa.» No creo que esa lectura sobreviva al contacto con los grafos de ataque.

La lectura incómoda es la correcta: un sistema autónomo, haciendo exactamente lo que se le dijo, ejecutó una intrusión completa en el mundo real a través de la infraestructura de dos empresas a velocidad de máquina — y desde el lado de la víctima, era indistinguible de un adversario anónimo e inmune a la atribución. La ofensiva funcionó porque podía planificar y encadenar. La defensa funcionó porque alguien estaba observando comportamiento, no firmas, y tuvo el sentido común de correr su forense sobre un modelo que sí mirara la evidencia.

Ese es el modelo de amenaza entero de 2026 en un fin de semana. El modelo es ahora un principal en vuestra red. Dadle la misma sospecha, el mismo mínimo privilegio y — por encima de todo — el mismo registro implacable que le daríais a cualquier otra cuenta capaz de leer vuestras credenciales y alcanzar vuestra base de datos de producción. Porque este es más rápido que vosotros, no se cansa y gastará todo su presupuesto en vuestra puerta más débil.

Manteneos paranoicos. Instrumentad la capa de agentes. Guardad un modelo sin restricciones on-prem para el día en que necesitéis leer el malware vosotros mismos.

• X (Twitter): @SimonRoses

Lecturas recomendadas:

• OpenAI — Incidente de seguridad en la evaluación de modelos de Hugging Face
• Hugging Face — Incidente de seguridad, julio de 2026
• Cómo Convertir en Arma las Skills de Agentes IA
• Envenenamiento de Skills en Agentes IA: El Ataque a la Cadena de Suministro del que Nadie Habla
• Cuando los Agentes Arreglan a los Agentes: Cómo Hermes Parcheó OpenClaw Tras una Mala Actualización
• OWASP Top 10 para Aplicaciones Agénticas 2026
• USecVisLib — utillaje de árboles y grafos de ataque

¿Preguntas o comentarios? Contactar vía:

• Web: vulnex.com
• Estrategia de Seguridad IA: vulnex.ai
• Twitter/X: @SimonRoses
• LinkedIn: linkedin.com/in/simonroses
• GitHub: github.com/vulnex

¿Necesitáis ayuda para asegurar vuestro despliegue de agentes o modelos IA? VULNEX ofrece:

• Evaluaciones de seguridad de agentes y modelos IA (aislamiento del harness de eval, testing de inyección de prompts, revisión de permisos de herramientas y de egress)
• Ejercicios de red team (simulaciones de ataque potenciadas por IA)
• Monitorización de LLMs y agentes / ingeniería de detección
• Automatización de seguridad y consultoría de agentic-ops

Para estrategia de seguridad IA — donde el riesgo de modelos y agentes se cruza con las decisiones a nivel de consejo — ved vulnex.ai.

Contacto: info@vulnex.com