Una foto de iPhone abrió el mono repo de OpenAI: la cadena de ataque que costó menos que un MacBook

Qué pasó, en una frase

Una foto subida a un foro de internet logró lo que parecía imposible: abrió una puerta dentro de los sistemas internos de OpenAI. No por magia ni por un error gigante, sino encadenando tres fallos pequeños que nadie había conectado. Y gran parte del trabajo lo hizo una inteligencia artificial.

Primero, los tres conceptos que necesitas

Para seguir la historia solo hacen falta tres ideas:

• El formato de las fotos. Cuando tomas una foto con un iPhone, el archivo no es un JPG de toda la vida: es un formato llamado HEIC, más eficiente pero menos compatible. Muchos servidores web no saben qué hacer con él.
• El registro de fallos (CVE). Cuando se descubre un error de seguridad en un programa, lo ideal es que se publique en un catálogo público llamado CVE, como el parte policial del fallo. Así, quienes administramos servidores sabemos qué tenemos que actualizar urgente. Si un arreglo existe pero nunca se publicó en ese catálogo, para el mundo ese arreglo no existe: seguimos corriendo el programa vulnerable sin saberlo.
• Un repositorio (o "repo"). Es donde una empresa guarda todo su código, el conjunto de "recetas" con las que funcionan sus productos. El mono repo de OpenAI es el depósito único donde vive todo. Entrar ahí es como llegar a la cocina donde se cocina ChatGPT.

La cadena, paso a paso

1. La entrada — una foto común y corriente. El foro público de ayuda de OpenAI funciona con un programa llamado Discourse, muy popular para comunidades. Cuando alguien sube una foto HEIC, el procesador habitual del foro no entiende ese formato y se la pasa a un componente antiguo llamado ImageMagick, que a su vez se la pasa a otro llamado libheif. Ahí, adentro de ese viejo procesador de imágenes, vivía el error.
2. El error — escribir fuera del cuaderno. El fallo era un heap buffer overflow: imagina que un programa anota datos en un cuaderno de 100 líneas y, por el error, alguien puede escribir más allá de la línea 100, pisando lo que hay en las páginas siguientes. En una computadora, esas páginas siguientes pueden contener instrucciones que el servidor va a ejecutar. Quien controla lo que se escribe, controla la máquina. Este error ya estaba arreglado en el código original desde hacía meses… pero el arreglo nunca se registró como CVE. Nadie supo que necesitaba actualizar. El foro de OpenAI seguía corriendo la versión vulnerable.
3. La inteligencia artificial entra al juego. Los investigadores, una firma llamada Hacktron, le pidieron ayuda a Claude, el modelo de Anthropic. La versión disponible (Opus 4.8) encontró el error y explicó cómo explotarlo, pero tropezó con una defensa del sistema operativo llamada ASLR —una medida que "baraja" cada noche las direcciones de memoria para que el atacante no sepa en qué página escribir— y no logró un ataque confiable. Esa misma noche del 24 de julio salió Opus 5; a la mañana siguiente, ~10 a.m., ya había un ataque funcionando y los investigadores controlaban el servidor del foro. Eso se llama ejecución remota de código: escribirle órdenes a una máquina que no es tuya.
4. El segundo error — el de verdad. Aquí viene lo importante: el foro era solo la entrada. Los investigadores descubrieron que la sesión iniciada en el foro servía también para ChatGPT y Codex, la herramienta de programación de OpenAI. Es el clásico "inicia sesión una sola vez y entra a todo" (SSO, inicio de sesión único), cómodo para los usuarios pero peligroso si una parte es débil: es como usar la misma llave para la reja, la puerta principal y la caja fuerte. Y este problema estaba en la infraestructura de cuentas de OpenAI, no en el foro.
5. El toque final. Con la sesión de un empleado —cuya herramienta Codex estaba conectada a la cuenta de GitHub de la empresa—, los investigadores le escribieron a ese Codex una orden: "abre una solicitud de cambio en el repositorio interno". Lo hizo. Esa solicitud era la prueba de que habían llegado hasta la cocina. No abrieron ni un archivo sensible: demostraron el camino y pararon ahí.

OpenAI corrigió el problema de sesiones en ~14 horas y Discourse parcheó y aisló su procesador de imágenes en días. OpenAI pagó US$6,500 de recompensa.

El detalle que debería inquietarte: la IA se negó… hasta que cambiaron la etiqueta

Cuando los investigadores quisieron que la IA atacara directamente un servidor en producción, Claude se negó: sus reglas le impedían escribir ataques contra sistemas ajenos. La salida, según The Register, fue poner un servidor propio detrás de una dirección disfrazada de "reto de práctica" (capture the flag, un juego de hacking). Con esa etiqueta, la negativa desapareció y la IA ejecutó el ataque sola.

Piénsalo así: la capacidad estaba ahí todo el tiempo. Lo que cambió no fue la habilidad de la IA, sino el nombre que le pusieron al objetivo. Si una medida de seguridad de un modelo de última generación cae ante un cambio de redacción, ¿qué nos protege de alguien con malas intenciones que use el mismo truco?

La noticia de verdad: funcionó en todas partes

Hacktron adaptó la misma técnica —le pusieron nombre propio: "HEIF Heist"— a otras empresas en uno o dos días por caso: Slack, Meta, GitHub Enterprise, Rails, Next.js. ¿Adivina cuántas se dieron cuenta? Una. Shopify, y por la vía más ruidosa: el procesador de imágenes se caía una y otra vez mientras miles de fotos de prueba pasaban por él. Nadie más notó nada.

Un experto en seguridad resumió el nuevo panorama: por unos US$200 al mes en suscripciones de modelos de IA, cualquier persona puede intentar hoy lo que hizo Hacktron.

Qué puedes revisar hoy en tus propios servicios

Si administras un servidor casero, un foro o cualquier servicio propio, esta historia es tu lista de tareas. Cada punto toma minutos:

• Mira qué programas procesan tus imágenes. ImageMagick y libheif están instalados en millones de servidores sin que nadie lo recuerde (Rails, Node.js, foros). En Linux basta un comando para listarlos: dpkg -l | grep -E 'imagemagick|libheif'. Los procesadores de imágenes viejos son de los objetivos más atractivos para atacantes, precisamente porque todos dan por hecho que "una imagen es solo una imagen".
• Desconfía de los arreglos sin CVE. El error ya estaba corregido desde hacía meses y el servidor seguía vulnerable porque nadie lo sabía. Que tu sistema diga "todo actualizado" no significa que esté seguro.
• Revisa los caminos alternativos. Si tu servicio manda ciertos tipos de archivo a un procesador distinto al habitual (un "fallback"), ese camino alternativo es exactamente por donde entraron en OpenAI.
• No uses la misma llave para todo. Si iniciar sesión en un servicio pequeño te abre la puerta de servicios importantes, un fallo chico se convierte en un desastre grande. Sesiones que caduquen pronto y permisos mínimos entre servicios.
• Trata los fallos como señales. La única empresa que se dio cuenta, se dio cuenta porque su sistema se cayó. Si algo en tu servidor empieza a fallar sin explicación, no lo reinicies y olvides: puede ser la evidencia de un intento de intrusión.

La cifra que más dice: US$6,500

Hay un epílogo incómodo. OpenAI pagó US$6,500 por una cadena de ataques que llegó hasta su código interno — y además aclaró que el foro donde empezó todo estaba fuera de las reglas de su programa de recompensas. O sea: casi ni siquiera calificaba como reporte. Que la empresa líder en IA valore en cinco cifras bajas una ruta completa hasta su propia cocina dice algo del mercado: hacer estos ataques se volvió baratísimo, pero nadie los está pagando como lo que valen. Esa diferencia no puede durar, y la corrección probablemente llegue por el lado malo antes que por el de las recompensas.

Lo que me llevo

• Los ataques no empiezan donde miras: empiezan en el programita olvidado que heredaste sin darte cuenta.
• Un arreglo que no se publica es un arreglo que no existe para quienes operamos sistemas. El proceso de divulgación es parte de la seguridad, no papeleo.
• Las barras de seguridad de la IA actuales son etiquetas, no candados. El truco del "reto de práctica" no fue un hackeo sofisticado: fue redacción.
• "Entra una sola vez" es cómodo para usuarios y un multiplicador de riesgos para quien administra.
• De todas las empresas atacadas, solo una notó algo. La detección — no la prevención — es donde todos estamos invirtiendo menos.

Sigo midiendo estas cosas desde mi homelab en Perú. Si después de leer esto revisaste tus propios servicios y encontraste alguna sorpresa, me encantaría leerla.

Fuentes: Quartz, The Register (vía AI Edge Briefing), VentureBeat (vía EveryDev), Wall Street Journal (vía AI Chat Daily). Relato técnico original de Hacktron. Las cifras atribuidas a Hacktron provienen de su propio relato.