Tres Horas, No Tres Meses
El 23 de julio, tres investigadores de seguridad de Hacktron miraban un desbordamiento de búfer en libheif, la biblioteca que decodifica fotos HEIC y HEIF. Tenían una teoría. El propio foro comunitario de OpenAI, community.openai.com, funcionaba sobre Discourse. La canalización de subida de Discourse entregaba formatos de imagen no reconocidos directamente a ImageMagick, que dependía de esa misma libheif vulnerable. Claude Opus 4.8 pasó varias sesiones intentando convertir la teoría en un exploit funcional y no logró superar la aleatorización del espacio de direcciones. Los investigadores aparcaron el intento.
Entonces, la noche del 24 de julio, Anthropic publicó Claude Opus 5. El equipo le dio al nuevo modelo el mismo problema. En tres horas tenía un exploit ARM64 funcional para un Mac local, y lo portó por su cuenta al entorno de producción x86-64 y jemalloc de Discourse. A las 06:00 UTC del 25 de julio, el exploit funcionaba contra un objetivo local. A las 10:00 UTC, funcionaba contra el foro en vivo de OpenAI.
El Fallo Que Nadie Tuvo Que Parchear de Verdad
El fallo de libheif no era un descubrimiento. Ya se había corregido río arriba, en silencio, sin que se le asignara un número de CVE. Sin CVE no llegó ninguna alerta al equipo de seguridad de Debian, así que Debian 12, la imagen base de Discourse, jamás incorporó el parche. Discourse heredó el fallo a través de ImageMagick. El foro de OpenAI lo heredó a través de Discourse. Tres organizaciones, tres decisiones separadas de no actuar, ninguna equivocada por sí sola.
La brecha del foro por sí sola habría quedado contenida. Lo que la convirtió en un incidente de OpenAI fue un inicio de sesión único que enlazaba el foro con las cuentas de ChatGPT y Codex de los empleados. Comprometer una cuenta del foro dio a los investigadores una sesión que llegaba hasta Codex. Codex estaba conectado a GitHub. GitHub albergaba el monorepositorio openai/openai. Nueve componentes, nueve equipos distintos, un camino continuo desde una biblioteca de fotos sin parchear hasta el código fuente.
La Velocidad Real Con La Que Se Cerró La Cadena
Hacktron publicó su propia cronología al minuto. Puesta en orden, la distancia entre un modelo que no lograba terminar la tarea y un modelo que atravesó directamente la frontera de identidad de OpenAI fue de un solo lanzamiento de producto.
| Hora (UTC) | Suceso | Agente |
|---|---|---|
| 23 jul, 05:00-06:00 | Desbordamiento en libheif identificado; Opus 4.8 no logra un exploit fiable | Humano + Opus 4.8 |
| 24 jul, noche | Se publica Claude Opus 5; recibe el mismo objetivo | Anthropic |
| 25 jul, 06:00 | Exploit ARM64 funcional confirmado en un Mac local | Opus 5 |
| 25 jul, 10:00 | Ejecución remota de código lograda en Discourse Cloud, se lee /etc/hosts | Opus 5, dirigido por humanos |
| 25 jul, 13:30-15:30 | Cuenta de un empleado en ChatGPT y Codex alcanzada; acceso demostrado, pruebas detenidas | Investigadores humanos |
| 25 jul, 22:49 | OpenAI confirma que el parche está desplegado | OpenAI |
| 1 sep | OpenAI paga una recompensa de 6.500 dólares solo por el hallazgo de SSO | OpenAI |
La construcción del exploit en tres horas es el titular. La parte que merece atención son las 22 horas y 49 minutos entre el momento en que los investigadores alcanzaron una cuenta de empleado y el momento en que OpenAI confirmó el parche. Ese fue el tiempo de respuesta real contra el que se puso a prueba la cadena. Aguantó.
Por Qué Importa a Cualquier Operador de la UE, No Solo a los Laboratorios de IA
La conclusión de Hacktron es directa: la seguridad llevaba mucho tiempo apoyándose en la complejidad como foso, en la idea de que desarrollar un exploit exige un equipo bien dotado y meses de tiempo. Ese foso es justo lo que Opus 5 eliminó en este fallo. Los investigadores escribieron que un trabajo que antes requería mano de obra especializada y escasa ahora puede comprimirse en cómputo. Añadieron que el salto de Opus 5 al siguiente modelo ya era visible en sus propias pruebas.
Para una empresa sujeta a NIS2, esa compresión recae sobre el reloj, no solo sobre el presupuesto. Las entidades esenciales e importantes deben notificar un incidente significativo en 24 horas desde que tienen conocimiento de él y presentar un informe completo en 72 horas. La cadena de Hacktron, del exploit funcional al repositorio interno comprometido, se cerró dentro de esa misma ventana de 72 horas. El reloj de notificación y el reloj del atacante ya no corren a velocidades distintas. Un proceso de detección pensado en días, no en horas, está construido para el adversario equivocado.
La Conclusión
Nadie en esta historia actuó de forma temeraria. OpenAI mantenía un programa de recompensas y pagó en cuestión de días. Hacktron reveló el fallo de forma responsable y se detuvo en el momento en que el acceso quedó demostrado. Discourse publicó un parche en 48 horas tras el aviso. El sistema funcionó exactamente como estaba diseñado. Un modelo de IA igualmente alcanzó el código fuente de un laboratorio de IA de primera línea, partiendo de un fallo de subida de fotos que ya se había corregido en otra parte de internet.
Las propias condiciones del programa de OpenAI excluían las pruebas contra Discourse en sí, así que el pago de 6.500 dólares cubrió solo el fallo de la frontera de identidad, no el exploit que abrió la puerta a los investigadores. Esa brecha entre lo que cubre un programa de recompensas y lo que realmente necesita un atacante merece su propia auditoría, con o sin ayuda de un modelo.
Leer a continuación: Su modelo de amenazas NIS2 asumió al atacante equivocado | Las mejores herramientas de hacking con IA ahora son solo por invitación
