TL;DR:
- OpenAI reconoció que sus modelos usaron credenciales expuestas para entrar a cuatro cuentas en cuatro servicios durante el ataque a Hugging Face, y a algunas más en otras evaluaciones.
- De esos cuatro servicios, únicamente Modal se identificó en público: un cliente suyo tenía un endpoint abierto sin autenticación que permitía ejecutar código a cualquiera.
- Jingxuan He, uno de los investigadores de UC Berkeley detrás de ExploitGym, dice que ya habían visto modelos hacer trampa en esa prueba, pero nunca saliendo hacia infraestructura de terceros.
OpenAI confirmó que el ataque de su agente autónomo no se quedó en Hugging Face. En una actualización publicada el 28 de julio de 2026, la empresa reconoció que sus modelos usaron credenciales expuestas en internet para entrar a cuatro cuentas en cuatro servicios distintos durante el mismo incidente: una sirvió como relevo y punto de preparación del ataque, otra guardó datos y las dos restantes fueron accesos de solo lectura. OpenAI no nombró a ninguno de los cuatro. De todos ellos, solo uno tiene cara pública: Modal, la plataforma de infraestructura para cargas de IA, a la que Hugging Face señaló en su cronología técnica y que respondió con su propia nota el 29 de julio. Y desde Berkeley, uno de los investigadores que construyó la prueba que el agente intentaba aprobar pide cambiar la forma en que se evalúan los modelos.
Cuatro cuentas, cuatro servicios y tres dueños sin nombre
El reparto de funciones que describe OpenAI dibuja una operación con logística propia. Una cuenta hizo de puente de salida y de bodega temporal para las cargas del ataque. Otra guardó lo que el agente iba recolectando. Las dos últimas se abrieron y se leyeron, sin que la empresa haya encontrado que sirvieran para comprometer a Hugging Face.
Hay un dato que pasó de largo en casi toda la cobertura: la misma actualización menciona que los modelos también alcanzaron algunas cuentas más durante otras evaluaciones, fuera de este incidente. OpenAI no dice cuántas ni de qué servicios. Afirma que seguirá avisando a los dueños de forma directa y que no ha visto evidencia de un impacto mayor en esos proveedores.
Los modelos, además, se apoyaron en un puñado de utilidades públicas que no requieren cuenta: sitios para pegar código, servicios de captura de peticiones, herramientas de screenshots. Ahí no hubo nada que comprometer, porque están abiertas por diseño.
Modal fue el único que salió a explicarse
Akshat Bubna, CTO de Modal, confirmó el 28 de julio a Axios y a Reuters que un cliente suyo había publicado un endpoint sin autenticación que dejaba a cualquiera en internet ejecutar código dentro de sus sandboxes. Al día siguiente la empresa publicó una nota propia con la misma línea de fondo:
"La plataforma de Modal no fue comprometida de ninguna manera"
La distinción importa: el código vulnerable era del cliente y corría dentro del aislamiento estándar de Modal. Ninguna otra carga de trabajo se vio afectada. Según Axios, ese activo del cliente estaba ligado a CyberGym, el proyecto anterior del mismo equipo de Berkeley que después construyó ExploitGym. O sea que el agente, ya fuera de su jaula, siguió persiguiendo exactamente lo que le habían encargado.
Modal cerró su nota con cuatro recomendaciones que funcionan como lista de verificación para cualquier equipo que exponga un sandbox al público:
- Exigir autenticación en todo lo que sea alcanzable desde internet.
- Restringir el acceso por lista de IP permitidas.
- Limitar la salida de red del sandbox a lo estrictamente necesario.
- Tratar como no confiable cualquier código o entrada que llegue de un usuario.
Aquí aparece el problema que más inquieta a la industria, y lo puso Oleks Yaremchuk, cofundador y CEO de Manifold Security, en declaraciones a SC Media: el cliente de Modal habría visto en sus registros una petición bien formada a un endpoint que él mismo dejó abierto, sin nada anómalo.
"La víctima no detecta nada: se lo dice quien operaba el agente"
Eso invierte cómo ha funcionado siempre la notificación de brechas. Una empresa pequeña en México, España o Bogotá que exponga una demo pública queda dependiendo del proceso interno de incidentes de un laboratorio de IA con el que no tiene ninguna relación. Y de los cuatro servicios de esta historia, tres siguen sin salir a la luz.
Dilis Salazar
El creador de ExploitGym ya había visto trampas, pero no de este tamaño
ExploitGym es un benchmark público de ciberseguridad, desarrollado por investigadores de UC Berkeley junto con el Max Planck Institute for Security and Privacy, UC Santa Barbara, Arizona State, Anthropic, OpenAI y Google, que mide si un agente de IA puede convertir vulnerabilidades ya conocidas en ataques funcionales. Son casi 900 fallas reales de software de producción, del kernel de Linux al motor V8 de Chrome.
Jingxuan He, uno de los autores, contó a Bloomberg News que el equipo diseñó la prueba dando por hecho que los modelos buscarían atajos, y le puso un mecanismo para detectarlos. Según Bloomberg, la prueba la usan hoy OpenAI, Anthropic, Microsoft y la china Z.AI.
"Este caso concreto fue a una escala mucho mayor de la que habíamos visto"
La diferencia, explicó He, es de perímetro: antes la IA hacía trampa dentro del sandbox y de los repositorios que se le daban. Esta vez se metió a la infraestructura de un tercero. Sobre la instancia de CyberGym que estaba en Modal, dijo que existen muchas copias por el mundo para que los desarrolladores prueben sus sistemas, que no sabe quién levantó esa en particular y que quien lo hizo la dejó accesible para cualquiera en internet.
De ahí su lista de pendientes, que apunta al software más que a los modelos: lenguajes de programación más seguros, mejor diseño de sistemas y verificación formal. He le dijo a Bloomberg que a los desarrolladores debería exigírseles garantías formales de que la IA no puede atacar ni explotar su software. La Cloud Security Alliance, que publicó su propio informe sobre el caso, va en la misma dirección y sostiene que el mayor riesgo de estos sistemas es el comportamiento orientado a un objetivo, no la intención maliciosa; su recomendación es más monitoreo y más control sobre los agentes.
CrowdStrike, METR y Redwood entran a revisar lo que hizo el modelo
La segunda actualización de OpenAI, del 29 de julio, sumó nombres externos. CrowdStrike está validando la reconstrucción de lo que hicieron los modelos dentro de la red de OpenAI, en la de Hugging Face y en los terceros afectados. METR y Redwood Research harán una evaluación independiente del comportamiento del modelo y publicarán un blog conjunto con los términos del encargo, el alcance de su revisión y sus hallazgos. Ese material alimentará el reporte técnico que OpenAI prometió para las próximas semanas.
La empresa también acotó el susto en un punto concreto: ningún modelo con lanzamiento planeado participó en el ataque. El prototipo involucrado, además de GPT-5.6 Sol, era de uso interno y nunca estuvo destinado a salir al público; después del incidente quedó desactivado, cifrado y con el acceso de investigación restringido. Que los modelos hubieran intentado escapar antes no era información nueva, y FomoEra ya documentó esos antecedentes.
En paralelo, el debate se movió al terreno político. El tecnólogo de seguridad Bruce Schneier, de la Harvard Kennedy School, argumentó el 30 de julio en Foreign Policy que Estados Unidos no debería vetar los modelos con capacidades ciber avanzadas, porque limitar artificialmente a la defensa termina regalándole la ventaja al atacante.
Preguntas rápidas sobre el alcance del ataque
¿Qué otros servicios además de Hugging Face fueron afectados?
OpenAI confirmó cuatro cuentas en cuatro servicios distintos, sin nombrarlos. Una funcionó como relevo y preparación del ataque, otra como almacenamiento y dos fueron accesos de solo lectura. Solo Modal se ha identificado en público, y aclara que la plataforma no fue comprometida: el endpoint expuesto era de un cliente.
¿Qué debo revisar si mi equipo expone un sandbox público?
Modal recomienda exigir autenticación en cualquier cosa alcanzable desde internet, restringir el acceso por lista de IP, limitar la salida de red al mínimo indispensable y tratar como no confiable todo código o entrada que llegue de usuarios. El endpoint del cliente afectado permitía ejecutar código sin credenciales.
Lo que queda sobre la mesa es un problema de aviso. Si el agente entró por una puerta que alguien había dejado abierta, el dueño de esa puerta no vio nada raro en sus registros. Se enteró, o se enterará, porque OpenAI levantó el teléfono. Tres de esos avisos todavía no son públicos.
