Una foto, Claude y el camino hacia OpenAI

La historia no empezó con una IA “rebelde”. Empezó con una foto.

Entre el 23 y el 25 de julio, tres investigadores de Hacktron AI encontraron una cadena de fallas que les permitió demostrar acceso a cuentas de empleados de OpenAI y proponer un cambio inocuo en un repositorio interno. La investigación se divulgó en septiembre y OpenAI confirmó que corrigió su parte, además de pagar una recompensa de 6,500 dólares.

El titular de “hackearon OpenAI con Claude” funciona muy bien para redes. También simplifica demasiado lo que pasó.

Claude fue una herramienta importante para acelerar la creación y ajuste de un exploit. Pero no eligió el objetivo, no inventó por sí solo toda la cadena y tampoco operó sin personas. Hubo investigadores, un entorno autorizado de bug bounty, decisiones técnicas y una divulgación responsable. Lo que sí cambió fue el tiempo necesario para convertir una sospecha técnica en una demostración de impacto.

Qué ocurrió realmente

La puerta de entrada estaba en el foro público de OpenAI, montado sobre Discourse. Al procesar ciertos formatos de imagen como HEIC o HEIF, el sistema recurría a componentes auxiliares para convertirlos. Uno de esos componentes, libheif, contenía un problema de memoria que podía aprovecharse bajo condiciones específicas.

Ese fallo no era, por sí mismo, “acceso a OpenAI”. Era una primera grieta en un servicio público.

La segunda parte fue más delicada: una mala configuración en el flujo de inicio de sesión único, conocido como SSO. La combinación permitió que el acceso al foro escalara a cuentas de ChatGPT y Codex de empleados. Desde una de esas cuentas conectadas, los investigadores demostraron que podían abrir una solicitud de cambio dentro del repositorio interno.

Según el reporte técnico publicado por Hacktron, no leyeron código ni exploraron servicios como correo o chat corporativo. Dejaron una prueba controlada, pararon la prueba y reportaron el hallazgo.

Claude aceleró el exploit; no reemplazó el ataque

Este es el punto que vale la pena discutir sin humo.

Los investigadores probaron primero con Claude Opus 4.8 y no consiguieron un exploit funcional. Con una versión posterior del modelo, lograron avanzar mucho más rápido. Claude ayudó a analizar el comportamiento del fallo, proponer ajustes y generar material para la demostración.

Eso no significa que cualquiera pueda escribir “hackea OpenAI” en una ventana de chat y obtener acceso.

El equipo ya entendía el problema, tenía un objetivo permitido, podía validar los resultados y sabía cuándo detenerse. La IA redujo el costo de iterar: probar una idea, fallar, corregir y volver a intentar. En seguridad, esa reducción de tiempo sí es una diferencia brutal.

SecurityWeek reportó un matiz importante: la vulnerabilidad de la librería y la forma exacta de su explotación requieren cuidado al describirse. El aprendizaje sólido no depende de repetir el detalle ofensivo. Depende de entender que una dependencia olvidada y una identidad sobreconfiada se vuelven críticas cuando se conectan.

El riesgo real estaba en la cadena de confianza

Una aplicación moderna rara vez es una sola aplicación.

Un usuario inicia sesión en un servicio. Esa cuenta habilita un agente. El agente puede ver documentos, repositorios, correo o tareas. El servicio procesa archivos con librerías de terceros. Cada pieza puede ser razonable por separado.

El problema aparece cuando una falla pequeña salta de contexto.

Antes, comprometer un foro podía significar manipular publicaciones o robar datos de usuarios. Ahora podría servir para llegar a una sesión corporativa, activar un agente con acceso a código y obtener una acción válida dentro de herramientas internas. El atacante ya no necesita romper cada puerta: busca una puerta que tenga demasiadas llaves.

No es un argumento para desconectar todo ni para dejar de usar IA. Sería una respuesta cómoda y poco práctica. Es una llamada de atención para diseñar permisos con la misma seriedad con la que diseñamos infraestructura.

Lo que deberían revisar los equipos

• Separar de verdad las identidades de comunidad, clientes y empleados.
• Aplicar permisos mínimos a agentes y conectores.
• Tratar repositorios, correo y almacenamiento como capacidades sensibles, incluso cuando el acceso llega “desde una cuenta confiable”.
• Inventariar las dependencias que procesan archivos subidos por usuarios.
• Revocar sesiones y credenciales cuando un servicio periférico sufre un incidente.
• Exigir confirmación humana para acciones sensibles de agentes, como crear cambios o acceder a información privada.
• Probar rutas de escalamiento, no sólo vulnerabilidades aisladas.

La pregunta correcta ya no es “¿mi chatbot es seguro?”. Es “¿qué puede hacer una cuenta comprometida después de que mi chatbot, agente o conector recibe sus permisos?”.

Lo que me llevo

Claude no fue el villano ni el protagonista único. Fue el acelerador.

La historia relevante es que un equipo pequeño pasó de un fallo en una imagen a una prueba de impacto interno en menos de 72 horas. Una combinación de componentes viejos, permisos conectados y automatización redujo una investigación que antes podía costar semanas.

También hay una buena noticia: los investigadores reportaron, OpenAI corrigió y hubo una recompensa. Así debería operar la investigación de seguridad. El problema es que un atacante real tendría los mismos incentivos técnicos, pero no el mismo límite ético.

Conclusión

La IA está abaratando la exploración ofensiva y defensiva al mismo tiempo. Los equipos que sólo vean la parte de productividad llegarán tarde a la conversación.

Tu superficie de ataque ya no termina en tu aplicación pública. Incluye cada archivo que procesas, cada dependencia que no actualizas, cada inicio de sesión compartido y cada agente al que le das permisos “porque es más cómodo”.

Las herramientas se vuelven más capaces. La disciplina de permisos tiene que volverse más aburrida, más estricta y mucho mejor hecha.