En septiembre escribí que la llave de API de IA es el botín, y que el error de siempre era dejarla donde no debía. En el código del frontend. En una app móvil. En un contenedor público.

Esta semana se robaron las que estaban bien guardadas.

OpenCode, Zeabur y Railway son plataformas donde los equipos de desarrollo guardan sus llaves como se recomienda, en variables de entorno del servidor y fuera del código. Las tres reportaron intrusiones en ocho días, entre el 14 y el 22 de octubre. Y en las tres el atacante iba por lo mismo, llaves de Anthropic, OpenAI, Google y OpenRouter.

Así que tu plan para proteger las llaves de IA tiene que partir de otro supuesto. El lugar donde las guardas también puede caer. Ese día te protege lo que hiciste antes: cuánto puede gastar cada llave, quién más la tiene y cuánto tardas en cambiarla.

Tres plataformas en ocho días

Plataforma	Cuándo	Qué se llevaron
Zeabur	14 y 15 de octubre	3.218.965 registros de variables de entorno y datos de 321.810 cuentas
OpenCode	desde el 17 de octubre	llaves de proveedores guardadas en la consola web por el 1,4% de sus usuarios
Railway	del 20 al 22 de octubre	variables de entorno cifradas, una parte ya descifrada, en hasta el 1,85% de los espacios de trabajo

Railway lo dijo sin rodeos en su informe preliminar. El ataque “was attempting to obtain AI provider API keys to perform distillation attacks” (buscaba llaves de proveedores de IA para hacer ataques de destilación). Destilar es usar las respuestas de un modelo caro para entrenar uno propio. Con llaves ajenas, la cuenta la paga otro.

Zeabur cuenta en su reporte del incidente que el atacante buscaba sobre todo llaves que pudiera usar directamente, “especially keys for AI services” (en especial de servicios de IA). Intentó llamar a Amazon Bedrock con las llaves de AWS de la propia Zeabur. Falló.

En OpenCode sí hubo cobros. Según TechCrunch, a varios usuarios les saltaron de noche las alertas de gasto de OpenAI, Anthropic y Google, con cargos de cientos de dólares por cuenta y algunos por encima de mil. Anthropic y Google bloquearon las llaves expuestas, y OpenAI trabajó con OpenCode en reembolsos.

Lo que cuenta Zeabur

Zeabur publicó el reporte más detallado de los tres, y es incómodo de leer. Zeabur se atribuye la culpa a sí misma: “long-lived admin credentials were stored in plaintext” (credenciales de administrador de larga duración guardadas en texto plano). Los tokens no vencían y no se habían rotado desde enero de 2024. Venían de una primera intrusión en agosto, y después de esa Zeabur no los cambió todos.

Hay un detalle que me parece el más útil para cualquier empresa que automatiza procesos. En el cluster compartido el atacante ejecutó comandos dentro de 736 instancias de n8n. De 607 que Zeabur revisó, 602 tenían su llave de cifrado guardada en una variable de entorno.

Es una caja fuerte con la combinación pegada en la puerta. Cada credencial que esas empresas conectaron a n8n (su CRM, su correo, su base de datos) quedó tan expuesta como la variable.

Zeabur cierra el 31 de diciembre.

PHP, Node.js y Python en la misma semana

Lo que más me cambia la forma de pensar esto es la velocidad. En OpenCode los cargos aparecieron en una noche. Y los lenguajes en los que corre casi todo el software de una empresa tuvieron una semana igual de pesada.

Empiezo por PHP. El 21 de octubre salieron los parches de PHP2Shell, dos fallas críticas en el núcleo de PHP que permiten ejecutar código en un servidor sin autenticarse. Wiz cuenta en su análisis que las encontró con Gemini 4 Argon y GPT-5.6 Sol, y que un solo investigador hizo en una semana lo que antes le habría tomado meses a un equipo de primer nivel.

Amazon registró un intento de explotación el 17 de octubre, cuatro días antes de que existiera el parche, según The Hacker News. CJ Moses, CISO de Amazon, lo resumió así: “The time from patch to working exploit is shrinking for structural reasons” (el tiempo entre el parche y un ataque que funciona se está acortando por razones estructurales).

Ese mismo 21 de octubre, Node.js publicó parches para diez vulnerabilidades en sus tres versiones activas, 22.23.4, 24.22.1 y 26.12.1. La más grave está en el descompresor Brotli. Según Node.js, si tu aplicación descomprime datos Brotli que le manda otro, un atacante puede corromper la memoria del proceso y llegar a ejecutar código. Uno de los créditos del reporte es de OpenAI Codex Security. Este sitio corre en Node, y hoy en la mañana subimos la versión a 22.23.4.

Y Python. El 20 de octubre pidió actualizar pip de inmediato, después de que se comprometieran las llaves privadas de ocho certificados intermedios de eMudhra. pip trae su propio paquete de certificados, así que actualizar el sistema operativo no alcanza. Christian Heimes lo dijo en el foro: “Updating pip is the only reliable fix” (actualizar pip es la única solución confiable). Además, Pillow, la librería de imágenes de Python, sacó la versión 13.0.0 con tres fallas críticas, y una de ellas la encontró Anthropic usando Claude, según The Hacker News.

La IA encuentra fallas. De los dos lados.

Qué haría el lunes

La lista de septiembre sigue valiendo. Esta semana le agrega cinco cosas.

Actualiza esta semana los entornos de ejecución. PHP con el parche del 21 de octubre, Node.js a 22.23.4 o superior, pip a 26.2.2 y Pillow a 13.0.0. Y reconstruye las imágenes de contenedor, porque una imagen vieja sigue trayendo el pip viejo.

Escribe quién más tiene tus llaves. El hosting, la plataforma de automatización, la herramienta de código que usa tu equipo, el agente que conectaste el mes pasado. Hoy revisé nuestros proyectos y ninguno corre en Railway ni en Zeabur, pero esa respuesta la tuve porque fui a buscarla.

Ponle a cada llave un límite de gasto en el proveedor. Cuando la plataforma cae, el límite es lo único que sigue funcionando sin que muevas un dedo. Y usa una llave por plataforma, para que el día que Railway te pida rotar, rotes la de Railway y no la que también usa tu app móvil.

Ensaya la rotación antes de necesitarla. Railway pidió cambiar todas las variables mientras tenía los despliegues pausados, o sea que la llave nueva no podía llegar al servicio que estaba corriendo. Si en tu empresa cambiar una llave depende de la única persona que sabe dónde está, ya encontraste tu riesgo.

Y si usas n8n, saca la llave de cifrado de las variables comunes.

En IQ Source, cuando revisamos el código y la infraestructura de una empresa con IA en producción, las llaves son lo primero que buscamos. Dónde están, quién más las tiene y qué pasa si una se filtra un sábado a las tres de la mañana. Lo que viene después del escáner lo escribí en seguridad de código con IA.

Empieza el lunes con esa lista de terceros. Si tiene más de tres nombres y ninguna llave tiene límite de gasto, ya sabes por dónde ir.

Revisemos quién tiene tus llaves de IA