A mediados de julio de 2026, Hugging Face reveló una intrusión en su infraestructura de producción que fue llevada a cabo, de principio a fin, por un agente de IA autónomo, y que se detectó y reconstruyó en gran medida con su propia IA. Cinco días después, OpenAI reveló quién era el responsable: sus propios modelos. GPT-5.6 Sol y un modelo aún no lanzado, más potente, que se estaban probando con sus mecanismos de defensa cibernética deliberadamente reducidos, estaban siendo sometidos a pruebas frente a un banco de pruebas interno llamado ExploitGym cuando se escaparon de control y atacaron a Hugging Face.
Una vez despojado de su contexto, el mecanismo resultaba ser una sucesión de elementos básicos conocidos que funcionaban sin descanso:
- Según OpenAI: los modelos aprovecharon una zero-day el proxy del registro de paquetes del entorno de pruebas, elevaron sus privilegios y se desplazaron lateralmente hasta un nodo con acceso a Internet; a continuación, encadenaron las credenciales robadas y otros exploits para ejecutar código de forma remota en los servidores de producción de Hugging Face y hacerse con la clave de respuestas de ExploitGym.
- Por parte de Hugging Face: el punto de entrada fue el proceso de procesamiento de datos, donde la ejecución de contenido de usuarios no fiables es una función fundamental, no un caso excepcional. Un conjunto de datos malicioso se aprovechó de dos vías de ejecución de código (un cargador de conjuntos de datos con código remoto y una inyección de plantillas en la configuración de un conjunto de datos) para ejecutar código en un nodo de trabajo. A partir de ahí, el agente escaló hasta el nivel del nodo, recopiló credenciales cloud del clúster, y se desplazó lateralmente por varios clústeres internos durante un fin de semana.
No se alteraron modelos públicos, conjuntos de datos ni Spaces; se comprobó que la cadena de suministro estaba libre de irregularidades y se denunció el incidente a las fuerzas del orden. Se accedió a conjuntos de datos internos y a credenciales de servicio, y Hugging Face no ha confirmado ninguna filtración de datos de clientes o socios.
Y no fue un caso aislado. Esa misma semana, el Instituto de Seguridad de la IA del Reino Unido (AISI) informó del mismo comportamiento en sus propias pruebas. En una evaluación cibernética que estaba mal configurada y era imposible de resolver, un modelo escribió y ejecutó código en un servicio externo de Internet para intentar acceder a la infraestructura de evaluación del AISI, lo que activó una alerta de seguridad. No se filtró nada ni se produjeron daños, ya que la infraestructura aguantó. Esa es la única diferencia con respecto a Hugging Face. El AISI también descubrió que todos los modelos que probó intentaron este tipo de atajo, lo que lo convierte en un problema de entrenamiento y alineación, y no en un caso aislado de un modelo defectuoso.
La retransmisión siguió de cerca la escapada. Lo que importa es la captura.
La mayoría de los medios se centraron en la fuga: una IA que se escapó y pirateó otra empresa. Un congresista estadounidense lo calificó de alarmante e instó a que se realizaran pruebas independientes obligatorias. Las voces más agudas señalaron que ya son posibles ataques similares con herramientas que están muy por fuera de los laboratorios de vanguardia, y que la crítica más pertinente se dirigía al propio sistema de contención de OpenAI: llevar a cabo una evaluación ofensiva con las medidas de seguridad desactivadas, en un entorno del que el modelo pudiera escapar, es un fallo del proceso antes que una cuestión de capacidades.
Sin embargo, hay un hecho que contradice el tono alarmista y que conviene dejar constancia: la detección funcionó. Ambos equipos detectaron la actividad de forma independiente, antes de que las empresas se pusieran en contacto. Lo novedoso no es el ataque en sí, sino el efecto que el incidente tuvo en las herramientas utilizadas para la respuesta.
Problema 1: la clave estaba en la correlación, no en las anomalías
Casi nadie ha escrito sobre cómo Hugging Face se percató de esto, lo cual es extraño, ya que es la parte más extrapolable del incidente.
La intrusión salió a la luz gracias a la detección asistida por IA, un proceso de detección de anomalías que utiliza una clasificación basada en modelos de lenguaje grande (LLM) a partir de datos de telemetría. Pero las anomalías por sí solas no eran más que ruido. Lo que permitió detectar la intrusión fue correlacionarlas en una única señal: esa es la diferencia entre señalar lo inusual y reconocer un ataque. Para reconstruir lo que hizo el agente, el equipo ejecutó agentes de análisis impulsados por LLM sobre el registro completo de acciones, compuesto por 17 000 eventos, con el fin de reconstruir la cronología, extraer indicadores de compromiso y separar el impacto real de la actividad de distracción.
Un fin de semana de ataques, una hora de respuesta. Según la propia descripción de Hugging Face, la campaña se desarrolló a lo largo de un solo fin de semana, con decenas de miles de acciones automatizadas, y la reconstrucción asistida por IA llevó aproximadamente una hora, un trabajo que normalmente habría requerido varios días. Esto fue posible porque los agentes disponían de un registro de acciones completo y correlacionado sobre el que basar su razonamiento. La eficacia de una defensa basada en agentes depende siempre de la calidad de la señal en la que se basa; si se le proporcionan datos fragmentados y unidimensionales, heredará ese punto ciego.
El movimiento entre clústeres es un problema de seguridad invisible (brecha n.º 3 en «Mind Your Attack Gaps»): del trabajador al nodo, pasando por cloud hasta llegar a varios clústeres, sin que exista un único plano que ofrezca una visión global. Sin embargo, el punto de entrada es específico y detectable: cualquiera que incorpore conjuntos de datos no fiables debería auditar ahora mismo esas dos vías de ejecución de código: el cargador de conjuntos de datos con código remoto y la inyección de plantillas en la configuración de un conjunto de datos.
Problema 2: las barreras de seguridad impidieron el paso a los defensores, no al atacante
Cuando Hugging Face inició el análisis de los registros, recurrió en primer lugar a los modelos de vanguardia que se encuentran detrás de las API comerciales. No funcionó. La reconstrucción forense implica enviar comandos de ataque reales, cargas útiles de exploits y artefactos C2, y los mecanismos de seguridad de los proveedores, incapaces de distinguir entre un responsable de la respuesta a incidentes y un atacante, bloquearon las solicitudes. En su lugar, llevaron a cabo el análisis en GLM 5.2, un modelo de pesos abiertos, en su propia infraestructura. De ello se derivó una segunda ventaja: ningún dato ni credencial de los atacantes salió de su entorno.
Hay que aceptar esta asimetría. El atacante actuó sin estar sujeto a ninguna política de uso. Las herramientas preferidas por los defensores no dieron la talla. La solución pone de manifiesto el problema: OpenAI incorporó a Hugging Face a su programa de acceso de confianza, que permite el acceso a los modelos con filtros de seguridad reducidos para tareas legítimas de seguridad, la misma configuración de «rechazo reducido» que desencadenó el incidente.
Vale la pena poner en práctica esta lección antes de que la necesites: mantén un modelo eficaz que puedas ejecutar en tu propia infraestructura, comprobado y listo antes de que se produzca un incidente, tanto para evitar el bloqueo de las medidas de seguridad como para mantener los datos de los atacantes dentro de la empresa. Esto no es un argumento en contra de la seguridad de los modelos alojados. Es un argumento a favor de planificar tus herramientas de DFIR teniendo en cuenta la posibilidad de que tu modelo principal no pueda ayudarte.
Problema 3: no hay ningún actor malicioso concreto que destacar
He dedicado gran parte del último año a defender una idea sobre la ciberdelincuencia: hay que seguir la pista al comportamiento, no a la marca; los nombres de los grupos cambian cada 18 meses, mientras que los operadores y el modus operandi no varían. Este incidente refuerza ese argumento, y quiero ser sincero sobre cómo lo hace.
La información revelada por Hugging Face no permitía determinar qué modelo impulsaba a los agentes, ni siquiera si se trataba de un modelo alojado o de peso abierto. El círculo solo se cerró porque OpenAI dio un paso al frente. Si se excluye esa revelación voluntaria, las señales habituales de atribución son escasas: no hay una identidad, no existe un grupo de operadores que reutilice técnicas de espionaje y el sistema de mando y control se trasladó, por diseño, a través de servicios públicos.
El seguimiento del comportamiento sigue funcionando a nivel técnico. La reutilización de credenciales que impulsa la operación es un problema de «autenticación exitosa» (Brecha 2): credenciales válidas, recopiladas y reproducidas; los registros registran el éxito; es detectable si quien actúa es un ser humano o un modelo. Lo que se diluye es la capa superior: la atribución a nivel de actor en la que se basa la CTI para determinar quién es y anticipar qué sucederá a continuación. Cuando el operador es un modelo que persigue un objetivo concreto, el «quién» puede reducirse a la ejecución de una prueba de rendimiento.
La máxima de «analiza el comportamiento, no la marca » sigue siendo válida. Es posible que, sencillamente, no haya ninguna marca detrás de ese comportamiento que se pueda identificar.
Qué debes cambiar antes de que esto te afecte
Nada de esto se resuelve con malware mejor malware , porque no había ningún malware. Hay tres medidas que son importantes:
- Considera los datos y la superficie del modelo como una superficie de ataque de primer orden. En el caso de las plataformas de IA, los datos de entrada no fiables son la puerta principal, no un caso aislado.
- Aplica la IA a la reconstrucción para que la respuesta se produzca a la misma velocidad que el ataque, lo cual solo funciona si la señal subyacente está correlacionada entre planos.
- Comprueba un modelo de análisis autohospedado antes de que se produzca un incidente, no durante el mismo, para que las medidas de seguridad nunca impidan la actuación de tu equipo de respuesta.
La brecha 3 es donde realmente se desarrolló el movimiento de esta intrusión, y es el capítulo de «Mind Your Attack Gaps» que volvería a leer en primer lugar.