Toda aplicación necesita secretos para funcionar: la contraseña de su base de datos, la llave que le permite cobrar con tarjeta, el token con el que envía correos o consulta un modelo de IA. La mayoría de esos secretos terminan guardados con quien aloja la aplicación. En octubre, uno de esos proveedores descubrió cómo se ve esa concentración desde el lado del atacante.
Qué pasó
El informe preliminar de Railway, actualizado el 26 de octubre, ofrece una línea de tiempo inusualmente detallada, y se lee más como un asedio que como una sola intrusión.
En la tarde del 20 de octubre, el monitoreo alertó a los ingenieros de guardia de Railway por una latencia anormal. En pocas horas encontraron un intento de escalamiento de privilegios en la infraestructura de compilación y detuvieron los pipelines de build. Para esa noche, Railway había concluido que enfrentaba, en sus palabras, "una campaña sostenida y dirigida". Durante la madrugada encontró más rutas de acceso y volvió a detener las compilaciones.
En las primeras horas del 21 de octubre, el atacante extrajo las variables de entorno cifradas, pero no pudo leerlas. Unas dos horas después obtuvo credenciales del entorno de CI de Railway, y aproximadamente entre las 07:25 y las 09:18 UTC ejecutó una consulta no autorizada sobre las variables cifradas y descifró una parte "utilizando una combinación de las credenciales comprometidas".
A partir de ahí la respuesta fue rápida. A las 09:25 UTC, Railway pidió a proveedores como GitHub, GitLab, Anthropic, OpenAI, OpenRouter y Stripe que revocaran las llaves de sus clientes desde su lado. Esa noche invalidó las sesiones de usuario, revocó todos los tokens de acceso de Railway, rotó las credenciales de todos los buckets de almacenamiento de la plataforma y pidió a sus clientes rotar todo. Los sistemas se reconstruyeron con credenciales nuevas durante la madrugada, y el servicio completo volvió a lo largo del 22 de octubre. Los registros de usuarios nuevos seguían pausados en la actualización del 26 de octubre.
Hay tres cosas que todavía no se saben. Railway no ha revelado la causa raíz; solo dice que encontró un "posible escalamiento de privilegios" en su infraestructura de compilación, seguido de "rutas de acceso posteriores". No ha descartado que el atacante accediera al código fuente de los clientes. Y no sabe qué secretos individuales se descifraron, porque la consulta que encontró "por sí sola no puede identificar específicamente qué llaves" quedaron expuestas. Promete un informe forense final.
El cifrado funcionó, hasta que el atacante tuvo las llaves
Railway guardaba los secretos de sus clientes con cifrado de sobre (envelope encryption), un diseño estándar y razonable en el que cada secreto se cifra y las llaves que lo descifran se protegen a su vez por separado. Funcionó como estaba diseñado durante un rato: el primer botín de variables cifradas no le sirvió de nada al atacante.
Dejó de importar cuando llegó a las credenciales de CI. El cifrado en reposo protege los datos de alguien que roba un disco o un respaldo de la base de datos. Hace mucho menos contra alguien que ya está dentro de los sistemas autorizados para descifrar, porque desde el punto de vista de la plataforma esa solicitud parece legítima.
Nada de esto es una crítica exclusiva de Railway; la mayoría de las plataformas funcionan así. Pero vale la pena ser precisos sobre lo que significa "tus secretos están cifrados" cuando un proveedor lo dice. Significa que una copia robada de la base de datos no basta. No significa que nadie que llegue lo suficientemente adentro pueda leerlos.
Por qué llaves de IA
El informe de Railway es directo sobre el motivo. Cree que el atacante estaba "intentando obtener llaves de API de proveedores de IA para realizar ataques de destilación", es decir, quería enviar volúmenes enormes de consultas a modelos de IA comerciales, con la cuenta de otra persona, para entrenar o mejorar un modelo propio. Railway dice que el actor tenía acceso a "modelos sin restricciones y recursos de cómputo considerables".
Eso cambia lo que vale una llave robada. Una contraseña de base de datos filtrada es valiosa si el atacante quiere esa base de datos. Una llave de IA filtrada es valiosa para casi cualquiera, de inmediato, y su costo lo paga el titular de la cuenta. Railway dijo que no puede reembolsar el gasto hecho con llaves comprometidas y remitió a sus clientes a los proveedores de IA.
Railway no fue la única. Wiz contó nueve plataformas de desarrollo e IA que reportaron incidentes durante octubre: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode y Northflank. No encontró una vulnerabilidad ni un actor único que las conecte, pero sí documentó qué pasa con las llaves después de filtrarse. En dos casos que investigó, llaves rastreadas a un proveedor comprometido no identificado se usaron para unas 2.5 millones de llamadas no autorizadas a Amazon Bedrock, con un costo estimado a precio de lista de más de 100,000 dólares. Esos casos no están vinculados a Railway, pero muestran la escala que alcanza este tipo de abuso.
La brecha de Zeabur, unos días antes que la de Railway, es el ejemplo más sombrío. Fue la segunda brecha de esa plataforma en dos meses: un atacante usó credenciales internas filtradas para entrar a su clúster compartido y expuso unas 321,810 cuentas y más de 3.2 millones de registros de variables de entorno. Los tokens administrativos involucrados nunca expiraban y no se habían rotado desde que se crearon en enero de 2024. Zeabur anunció que cerrará a más tardar el 31 de diciembre.
No es solo un problema de desarrolladores
Es tentador leer esto como una historia para equipos de software. La mayoría de nuestros clientes no publica código en Railway y nunca ha oído hablar de ella.
Pero muchos tienen un sitio web, un sistema de reservas, un portal de clientes o una herramienta interna que alguien les construyó, y ese alguien eligió dónde alojarlo. La aplicación casi seguro guarda llaves: del procesador de pagos, del servicio de correo, del CRM y, cada vez más, de un servicio de IA. Pregunta quién tiene esas llaves y dónde están guardadas, y la respuesta honesta muchas veces es que nadie en la empresa lo sabe.
Esa es la exposición real. No que una plataforma en particular haya sido vulnerada, sino que una empresa puede tener sus credenciales de pago o de IA en una infraestructura que no eligió, que no puede ver y que no pensaría en revisar cuando aparece un titular como este.
Qué hacer en concreto
Averigua dónde viven tus llaves. Pregúntale a quien construyó o mantiene cada una de tus aplicaciones algo simple: ¿qué plataformas guardan nuestras llaves de API y contraseñas, y cuáles son? Anota la respuesta. Si algo tuyo corría en Railway antes del 21 de octubre, el propio consejo de Railway es rotar todas las variables guardadas, incluidas las credenciales de registros privados, y revisar los registros de actividad.
Pon límites de gasto y alertas en cada cuenta de IA. Donde el proveedor permita límites estrictos, úsalos, y configura una alerta de facturación en un nivel que notarías. Una llave que puede gastar sin límite es una tarjeta de crédito olvidada en el mostrador. Una factura inesperada suele ser la primera señal de que una llave se filtró, así que asegúrate de que alguien realmente lea esas alertas.
Dale a cada aplicación su propia llave con permisos acotados. Una llave por aplicación, solo con los permisos que necesita, significa que una filtración en un lugar puede revocarse sin romper todo lo demás, y que los registros de uso te dicen de dónde salió la filtración.
Rota las llaves con calendario, no solo después de un incidente. Los tokens de Zeabur llevaban más de dos años sin rotarse. Una llave que cambia cada pocos meses vale mucho menos para quien la roba.
Pregunta a tus proveedores cómo aíslan a sus clientes. Como parte de su respuesta, Railway está moviendo sus compilaciones de una infraestructura compartida multiinquilino a entornos de un solo inquilino. Es una pregunta justa para cualquier plataforma que guarde tus secretos, junto con qué tan rápido podría decirte cuáles de tus llaves quedaron expuestas si la vulneran.
El resumen
Railway hizo muchas cosas bien una vez que se dio cuenta: contención rápida, revocación de llaves del lado de los proveedores, una línea de tiempo pública con horas exactas. Aun así, la brecha expuso secretos de hasta 100,000 workspaces, porque una plataforma que guarda las llaves de todos vale el tiempo de un atacante decidido como ningún cliente individual lo vale.
Una empresa no puede resolver esa concentración, pero sí puede decidir cuánto vale una llave robada. Sabe dónde están tus llaves, limita lo que cada una puede hacer y gastar, y rótalas antes de que alguien más las use.
Fuentes
- Preliminary Report: Oct 21st Security Incident — Railway
- Security Disclosure: Wednesday October 21st — Railway
- Developer platform Railway urges 'all users' to revoke secret keys after cyberattack — TechCrunch
- Railway warns devs to rotate secrets after potential breach — BleepingComputer
- Railway says intruder may have accessed customer secrets — The Hacker News
- Black October for AI developer platforms — Wiz
- Zeabur shutting down after second security breach in two months — BleepingComputer
