Northflank le dijo a todos sus clientes algo que ningún proveedor de nube quiere admitir en público: asuman que les robaron las claves. La brecha de Northflank, confirmada el 30 de octubre de 2026, obligó a la plataforma a pedir la rotación inmediata de cada variable de entorno, cada secreto y cada credencial almacenada en su infraestructura.
El aviso llegó en cuatro actualizaciones consecutivas de la página de estado de la empresa, con un detalle que agrava todo: varios usuarios ya confirmaron que sus claves de API de inteligencia artificial fueron usadas por terceros.
TL;DR
- Northflank confirma brecha el 30 de octubre de 2026: rotá ya todas tus variables de entorno y credenciales.- Wiz alertó el acceso a las 11:43 UTC; Northflank parchó su red a las 12:02 y 12:50 UTC.- Varios clientes confirman que sus claves de API de IA ya fueron usadas por atacantes.- Red, certificados, servicios, addons, jobs, builds y logs quedaron en outage mayor a la vez.- La plataforma activó rotación automática de secretos en addons de Postgres y MongoDB.
Qué es Northflank
Northflank es una plataforma como servicio (PaaS) que permite desplegar aplicaciones, bases de datos y jobs en contenedores sobre su propia nube o la de terceros, sin que el equipo de desarrollo tenga que administrar Kubernetes a mano. La brecha de Northflank del 30 de octubre afectó justamente esa capa de infraestructura compartida.
Startups, equipos internos de empresas medianas y desarrolladores independientes usan Northflank para desplegar APIs, workers y bases de datos administradas (Postgres, MongoDB, Redis) sin pagar los precios de AWS o GCP directamente ni mantener un clúster propio.
Wiz detectó la actividad anómala que disparó la respuesta de Northflank a las 11:43 UTC.
Qué pasó
Todo arrancó con una alerta automática. A las 11:43 UTC del 30 de octubre, la firma de seguridad en la nube Wiz notificó actividad anómala en la infraestructura de Northflank. Un minuto después, a las 11:44 UTC, los ingenieros de la plataforma ya estaban revisando la alerta, según el registro público del incidente.
La respuesta técnica fue rápida, pero no alcanzó para contener el acceso. Northflank aplicó un primer parche de política de red a las 12:02 UTC, uno adicional a las 12:50 UTC y dos más a las 13:05 UTC. A las 13:00 UTC pidió soporte al equipo de respuesta a incidentes (CIRT) de Wiz, señal de que el alcance superaba lo que su propio equipo podía contener solo.
sequenceDiagram
participant W as Wiz
participant N as Northflank
participant C as Clientes
W->>N: alerta de amenaza (11:43 UTC)
N->>N: parches de red (12:02 y 12:50 UTC)
N->>W: solicita soporte CIRT (13:00 UTC)
N->>C: aviso de rotar variables de entorno (13:40 UTC)
Note over N,C: rotacion forzada en Postgres y MongoDB (15:12 UTC)
A las 13:40 UTC, Northflank publicó su primera instrucción pública: rotar las variables de entorno de inmediato. Dieciocho minutos después, a las 13:58 UTC, subió el nivel de alarma: había que asumir que todas las variables de entorno estaban descifradas y desactivar o rotar cada clave. La recomendación pasó de precaución a obligación en menos de media hora.
La actualización de las 15:12 UTC confirmó lo peor. Northflank activó rotación forzada de secretos en los addons de Postgres y MongoDB para todos los usuarios, sin dejarlo opcional, y recomendó desactivar el acceso público de esos addons. La misma nota reveló que varios clientes ya habían confirmado el uso indebido de sus claves de API de proveedores de inteligencia artificial, lo que sugiere que el atacante no solo copió datos, también los usó.
A las 19:28 UTC, siete horas y 45 minutos después de la alerta inicial, la investigación seguía abierta. Northflank repitió la instrucción de asumir comprometidas todas las variables de entorno, extendió la advertencia a secret groups y global secrets, y pidió desactivar el acceso público a los addons donde estuviera habilitado. A esa hora no había, en público, una causa raíz confirmada.
Contexto e historia
Northflank compite en el segmento de plataformas que prometen simplificar lo que Kubernetes hace complicado: desplegar contenedores, bases de datos administradas y jobs programados detrás de una sola interfaz y una sola API. Railway, Render y Fly.io atacan el mismo problema desde ángulos distintos, pero los tres cargan con el mismo dilema de diseño: para administrar secretos de miles de cuentas, en algún punto del sistema esos secretos tienen que existir en texto plano, aunque sea por microsegundos.
Ese dilema no es nuevo ni exclusivo de Northflank. A lo largo de 2026, tanto Railway como Vercel atravesaron incidentes de seguridad propios que terminaron en el mismo consejo: rotar credenciales. La diferencia acá es la escala de la respuesta: Northflank no aisló el aviso a un componente puntual, sino que pidió asumir comprometida toda variable de entorno de la plataforma, sin excepción de plan ni de región.
Siete de los once componentes de Northflank seguían en outage mayor horas después del hallazgo.
Detalles técnicos: el mecanismo detrás de la brecha de Northflank
La pregunta que más repiten los clientes es por qué Northflank no dio una lista acotada de cuentas afectadas. La respuesta tiene que ver con cómo funciona el almacenamiento de secretos en una plataforma multi-tenant: las variables de entorno de cada servicio se guardan cifradas en una base compartida, pero se descifran en memoria cada vez que un workload arranca o se reconstruye. Si un atacante compromete la capa que hace ese descifrado, en teoría puede ver cualquier secreto que pase por ahí, no solo el de una cuenta.
Eso explica el salto de tono entre las 13:40 UTC (\"rotá por si acaso\") y las 13:58 UTC (\"asumí que ya está descifrado\"). Northflank no tenía, a esa hora, forma de acotar el radio de impacto a un subconjunto de usuarios: la alerta de Wiz apuntaba a la capa de red y de políticas que comparten todos los workloads, según el propio reporte de la página de estado, no a un servicio aislado.
No hay forma directa de verificar desde afuera si una cuenta puntual fue accedida: Northflank no publicó logs de acceso por cliente ni una herramienta de autodiagnóstico en su panel. La única señal disponible para un usuario es comparar la fecha de creación de sus claves actuales contra el 30 de octubre de 2026; si no las rotó después de esa fecha, debe asumir que están expuestas.
⚠️ Ojo: la recomendación de Northflank cubre tres capas distintas: secretos de workloads, secret groups y global secrets. Rotar solo la primera deja expuestas las otras dos.
Impacto y análisis
El outage no fue cosmético. Siete de los once componentes listados en el tablero de estado de Northflank (red, certificados, servicios, addons, jobs, builds y logs) cayeron en estado de outage mayor al mismo tiempo. Solo el panel web, la API pública, el sitio de marketing y la documentación siguieron operativos, lo que le permitió a Northflank seguir comunicando el incidente mientras el resto de la plataforma quedaba, en la práctica, inutilizable para desplegar nada nuevo.
ComponenteEstado durante el incidenteQué significa para el usuarioRed (Networking)Outage mayorRutas y balanceo de tráfico entre servicios fallabanCertificadosOutage mayorEmisión y renovación de TLS detenidaServiciosOutage mayorDespliegues de apps no arrancaban con normalidadAddons (bases de datos)Outage mayorPostgres y MongoDB con rotación forzada de secretosJobsOutage mayorTareas programadas y cron jobs sin ejecutarBuildsOutage mayorCompilaciones de imágenes bloqueadasLogs y métricasOutage mayorSin visibilidad para diagnosticar el propio incidenteApp, API, sitio y docsOperativoEl panel y la documentación seguían accesibles
La brecha de Northflank golpeó justo donde más duele para una plataforma de despliegue: si Builds y Services están caídos, un cliente no puede ni sacar una corrección de emergencia. Y si Logs and Metrics también falla, ese mismo cliente queda además a ciegas para entender qué le está pasando a su propia aplicación.
La plataforma mantiene, según su propio historial de 90 días, un 99,65% de uptime agregado. Un incidente de esta magnitud puede consumir buena parte de ese margen: siete componentes en outage mayor durante varias horas representan, en la práctica, una caída de disponibilidad considerable para los clientes activos ese día.
Qué sigue
Northflank no publicó, hasta la actualización de las 19:28 UTC, una causa raíz confirmada. La empresa dijo que \"la investigación sigue en curso\" y que no tenía \"hallazgos confirmados adicionales para compartir en este momento\", la fórmula habitual antes de un post-mortem técnico completo.
Lo que sí queda claro es la lista de tareas para cualquier cliente de Northflank: rotar secretos de workloads, secret groups y global secrets; desactivar el acceso público de los addons donde esté habilitado; y revisar si alguna clave de proveedor de IA fue usada desde una IP que el cliente no reconoce. Varios usuarios ya confirmaron, en el propio canal de estado, cargos o uso indebido de esas claves.
📖 Resumen en Telegram: Ver resumen
Probalo vos: entrá hoy mismo al panel de Northflank, abrí Secret Groups y Global Secrets, y rotá cualquier clave que no hayas tocado desde antes del 30 de octubre de 2026.
Preguntas frecuentes
¿Qué es Northflank y para qué se usa?
Northflank es una plataforma como servicio que permite desplegar aplicaciones, bases de datos administradas y jobs en contenedores, pensada para equipos que no quieren operar Kubernetes directamente.
¿Qué tipo de datos quedaron expuestos en el incidente de ciberseguridad de Northflank?
La propia empresa pidió asumir comprometidas todas las variables de entorno: credenciales de bases de datos, tokens de APIs externas y claves de proveedores de inteligencia artificial almacenadas en workloads, secret groups y global secrets.
¿Cómo se rotan las claves afectadas por la filtración de credenciales de Northflank?
Desde el panel de Northflank, en las secciones de secretos de cada workload, en Secret Groups y en Global Secrets; además, hay que desactivar el acceso público de los addons donde esté habilitado.
¿Northflank confirmó quién atacó la plataforma de despliegue en la nube?
No. Hasta la actualización de las 19:28 UTC del 30 de octubre de 2026, la empresa solo confirmó que la investigación seguía abierta, sin atribuir el ataque a un grupo ni publicar una causa raíz.
¿Qué componentes de Northflank seguían caídos tras el hallazgo del proveedor PaaS?
Red, certificados, servicios, addons, jobs, builds y logs y métricas quedaron en outage mayor a la vez, mientras el panel web, la API pública, el sitio de marketing y la documentación siguieron operativos.
¿Debo preocuparme si uso addons de Postgres o MongoDB en Northflank?
Sí: Northflank forzó la rotación de secretos en esos addons para todos los usuarios y recomendó explícitamente desactivar el acceso público donde estuviera habilitado.
Referencias
- Northflank Status: página oficial de estado con el registro completo del incidente, sus actualizaciones y los componentes afectados.- Northflank: sitio oficial de la plataforma como servicio afectada por la brecha.- Wiz: la firma de seguridad en la nube cuya alerta disparó la respuesta de Northflank al incidente.- Plataforma como servicio (Wikipedia): contexto general sobre el modelo PaaS en el que opera Northflank.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)