A las 13:58 UTC del 30 de octubre de 2026, la plataforma de despliegue Northflank movió su incidente de «Investigating» a «Identified» y en el hueco de la descripción escribió esto: «Assume all environment variables have been decrypted. Disable/rotate all keys.» Dos frases. Ninguna matiza a la otra.
Empieza por el cronómetro, no por la noticia
Antes de mirar si usas Northflank, haz el ejercicio que convierte esa frase en un número tuyo. Coge un solo secreto de producción, el que menos miedo dé, y rótalo de principio a fin: emite la credencial nueva en el proveedor que la expide, despliégala, verifica que el servicio sigue vivo y revoca la antigua. Con un cronómetro corriendo.
Salen tres cifras. La primera es el tiempo: multiplícalo por el total de secretos vivos y ya sabes cuánto dura tu propio «rotadlo todo». La segunda aparece al intentar multiplicar, y es donde se atasca casi todo el mundo: el inventario. Si nadie sabe cuántos secretos hay ni quién los emitió, entonces no hay plan de rotación, hay una buena intención y un jueves libre. La tercera es el radio: apunta qué se rompió al cambiar esa única clave y qué otras cosas la estaban usando sin que nadie lo recordara. El consumidor olvidado es lo que convierte una rotación de emergencia en una caída.
Y el orden importa más de lo que parece cuando hay prisa: rotar la credencial en tu plataforma no la invalida ante el proveedor que la emitió. Mientras no la revoques en origen, la clave vieja sigue sirviendo a quien la tenga. Hay una excepción honesta que conviene anotar antes de empezar: algunos servicios solo admiten una credencial activa a la vez, y ahí el paso de verificación cae dentro de una ventana de corte. Esos son justamente los que no quieres descubrir durante un incidente.
Por qué ese número importa esta semana
El reloj de Northflank es corto. A las 11:43 UTC la empresa de seguridad cloud Wiz les avisó; sus ingenieros revisaron el aviso un minuto después. A las 12:02, 12:50 y 13:05 desplegaron parches de política de red. A las 13:40 ya pedían públicamente rotar las variables de entorno, y a las 13:58 llegó la frase del titular. Poco más de dos horas desde un aviso externo hasta una instrucción pública inequívoca es una respuesta rápida, y decir «asume que todo» en lugar de administrar el pánico a plazos es más honesto de lo que se acostumbra.
Lo que vino después explica por qué el post empieza por el cronómetro. A las 15:12 habilitaron la rotación de secretos para Postgres y MongoDB y recogieron que varios usuarios están confirmando que sus claves de IA se han usado. Northflank no confirmó nada por su cuenta ese día: a las 19:28 seguía diciendo «Our investigation is ongoing. We have no further confirmed findings to share at this time», y hasta las 23:38 no publicó que los usuarios habían reportado uso no autorizado de claves de API de IA. Al día siguiente habilitaron rotación también para MySQL, Redis, Minio y RabbitMQ, y activaron registros de auditoría para todos los clientes, incluidas las cuentas gratuitas. A fecha de publicación seguían sin comunicar cómo se produjo el acceso, cuántos clientes resultaron afectados ni si se abusó de credenciales distintas de las de IA.
Dicho de otro modo: durante casi diez horas, la única información accionable que tuvo un cliente fue «asúmelo todo». Si tu respuesta a eso depende de un inventario que no existe, la ventana se te va en construirlo.
Al menos nueve plataformas en treinta y un días
El informe Black October de Wiz recoge al menos nueve incidentes revelados durante octubre de 2026 en plataformas de desarrollo e IA. Entre los nombrados: Fireworks AI, Zeabur, Lightning AI, OpenCode, Railway —que publicó su informe preliminar el 21 de octubre—, Warp, CommandCode y el propio Northflank.
Conviene no estirar ese dato más de lo que da. Wiz dice expresamente que no atribuye los nueve a un mismo actor y que no encontró una vulnerabilidad ni una dependencia compartida que los conecte; lo trata como una concentración de incidentes. El denominador común que sí describe es más modesto y más útil: todos los informes públicos describen búsqueda dirigida de variables de entorno almacenadas, con preferencia por las que dan acceso a servicios de IA. Que nueve plataformas del mismo tipo aparezcan el mismo mes buscando lo mismo, a nosotros nos parece selección de objetivo; esa lectura es nuestra, y Wiz se queda en llamarlo concentración.
La razón por la que las claves de IA encabezan la lista es económica y no necesita teorías. Una contraseña de base de datos robada hay que saber usarla: pide acceso a la red, algo de valor dentro y alguien que lo compre. Una clave de API de un proveedor de IA se gasta directamente, porque el consumo se factura a quien la emitió. El informe de Wiz, en la cobertura que hemos podido consultar, pone números al fenómeno —lo llaman LLMJacking—: un caso de unas 800.000 peticiones a Amazon Bedrock en 30 horas, con alrededor del 90 % completadas, y otro de cerca de 1,7 millones de peticiones en 13 horas, de las que más de un millón prosperaron. El coste combinado que estima el informe supera los 100.000 dólares a precio de tarifa.
1,7 millones de peticiones en 13 horas es, literalmente, «la misma tarde». Por eso, si usas claves de API de proveedores de IA, añade al ejercicio una cuarta tarea, y esta la firma el administrador antes que el de seguridad: comprueba que tienes límite de gasto y alerta de consumo en cada proveedor. Es el único control que acota el daño cuando la clave ya está fuera, y sigue trabajando mientras duermes. Es la versión con IA de el canario del gasto que ya contamos a propósito de las claves de AWS filtradas, y la conclusión no ha cambiado: el techo lo pones antes, o no lo pones.
El sistema que te protege es el que tiene que descifrar
La primera reacción de mucha gente al leer la noticia es preguntar si la plataforma cifraba los secretos. Northflank no ha explicado cómo se descifraron, y no vamos a deducirlo del verbo que eligió. Quien sí lo documentó es Railway, en su informe preliminar del 21 de octubre: el atacante se llevó los secretos cifrados y al principio no pudo abrirlos; después obtuvo credenciales del entorno de integración continua y, con ellas, «an unauthorized query of encrypted environment variables, of which a subset were decrypted utilizing a combination of the compromised credentials».
Ahí está el mecanismo, por escrito y firmado por el proveedor. Cualquier plataforma que ejecute tu código tiene que poder descifrar tus variables de entorno en el momento de arrancar el proceso. Si no, tu aplicación no arranca. El cifrado en reposo protege del robo del disco; no te protege si alguien compromete precisamente el sistema cuyo trabajo es descifrar.
Pregúntale a cualquier proveedor si cifra y te dirá que sí. La pregunta que nadie contesta por escrito es cuántos sitios distintos pueden descifrar hoy tus secretos, y si esa lista existe en algún lado. En una empresa de software mediana la respuesta suele incluir el proveedor de despliegue, el sistema de integración continua, el gestor de secretos, dos o tres herramientas SaaS con integración, el portátil de alguien y un repositorio privado con un fichero de ejemplo que dejó de ser de ejemplo. Es la misma cuestión que planteábamos cuando contamos que en el registro no sale el agente, sale quien le prestó el token, un piso más abajo: allí era el agente que usa la credencial, aquí la plataforma que la guarda.
Dónde nos deja esto a nosotros
Sería fácil cerrar esto con un «por eso, infraestructura propia», y no es verdad. Nosotros también tenemos secretos en sitios que ejecutan nuestro código. Usamos n8n autoalojado para automatizaciones internas, y guarda credenciales como las guarda cualquiera; lo que hacemos con él es tratarlo como un servicio de producción y no como una herramienta de andar por casa: está inventariado, tiene un responsable y tiene ventana de actualización. Eso no evita un incidente del proveedor. Lo que consigue es que, el día que llegue una frase como la de Northflank, la lista ya exista.
La decisión que sí es arquitectónica, y la que discutimos con los clientes cuando montamos infraestructura y cloud, resulta bastante más aburrida que elegir proveedor: cuántas plataformas distintas necesitan de verdad poder descifrar tus credenciales, y si cada una aporta lo suficiente como para justificar que esté ahí. Acortar esa lista rinde más que endurecer cada elemento de ella, y es lo primero que miramos en una revisión de ciberseguridad.
Si haces la prueba del cronómetro y el número que sale te incomoda, o si te atascas antes, en el inventario, escríbenos. Media tarde de trabajo y una cifra propia valen más que cualquier informe sobre el incidente de otro.
Nota de fuentes. La cronología del incidente (aviso de Wiz a las 11:43 UTC del 30-10-2026, parches de política de red a las 12:02, 12:50 y 13:05, aviso de rotación a las 13:40, cambio a «Identified» con la frase citada a las 13:58, rotación para Postgres y MongoDB más los reportes de usuarios a las 15:12, la nota de las 19:28 y la publicación de los reportes de uso no autorizado a las 23:38) procede de la página de estado de Northflank, complementada con la cobertura de BleepingComputer del 31-10-2026. Las frases entrecomilladas de Northflank y de Railway son literales de sus respectivas publicaciones; la de Railway, de su informe preliminar del 21-10-2026. El recuento de al menos nueve incidentes de octubre, los nombres de las plataformas, el denominador común, el término LLMJacking y las cifras de peticiones a Amazon Bedrock y de coste estimado proceden del informe Black October de Wiz a través de la cobertura que hemos podido consultar; no hemos leído el informe directamente, y lo señalamos porque las cifras de coste son estimaciones a precio de tarifa, no facturas verificadas. La lectura de que esto es selección de objetivo es nuestra y está marcada como tal en el texto. No somos clientes de ninguna de las plataformas citadas ni hemos participado en la respuesta a ninguno de estos incidentes.
Microsoft 365
ES 
CAT 
EN