La brecha de Railway dejó claves de IA robadas y un gasto ajeno cercano a US$740.000. La plataforma de alojamiento en la nube publicó el 10 de noviembre su informe final del ataque de octubre: un intruso pudo descifrar variables de entorno de hasta 100.000 espacios de trabajo, el 1,85 % del total, y ese tope es una cota máxima, no una cifra confirmada de víctimas.
Railway es un servicio donde miles de desarrolladores despliegan aplicaciones sin montar sus propios servidores. Cada proyecto guarda allí sus variables de entorno, el cajón con los secretos de la aplicación: claves de proveedores de inteligencia artificial y contraseñas de bases de datos.
El dato nuevo está en el detalle. El aviso inicial de octubre contó una intrusión y pidió rotar secretos; el informe final reconstruye la cadena completa, con horas exactas, dos vías de entrada y una factura que la empresa promete cubrir cuando el proveedor de turno se niegue a devolver el dinero.
Todo arrancó el 20 de octubre a las 07:28 UTC. El atacante aprovechó una falla desconocida en la infraestructura de compilación, el sistema que construye las aplicaciones de los clientes, y escapó en parte del aislamiento entre proyectos que comparten una misma máquina virtual.
Ese escape le entregó una credencial interna pensada solo para publicar imágenes tras cada compilación. Con ella leyó historiales guardados en Temporal, la herramienta que ordena las tareas del sistema de compilación, y revisó 353 historiales con variables selladas dentro.
Uno de esos historiales era de un servicio propio de Railway. El intruso copió el código interno completo de la empresa, su monorrepo, y probó rutas viejas que llevaban semanas sin uso.
La segunda puerta: un error de confianza en la nube
La ruta decisiva apareció en ese código robado. Una configuración de OIDC, el mecanismo OpenID Connect que entrega credenciales cortas a los sistemas de despliegue, estaba definida con un error en uno de los entornos de nube de Railway.
El 21 de octubre a las 03:26 UTC el atacante canjeó esa confianza mal puesta por una credencial breve de nube. Con ella sacó dos piezas guardadas en el entorno: una llave SSH privada y una credencial larga capaz de descifrar variables cifradas.
La llave SSH le abrió una máquina de orquestación, el equipo que coordina dónde corre cada carga de los clientes. Esa máquina guardaba la credencial de descifrado y tenía acceso a la red interna donde vive la base de datos de variables.
Entre las 04:07 y las 05:21 UTC consultó esa base buscando con expresiones regulares los nombres de variables de claves de IA. Priorizó a clientes con muchas variables. El descifrado de claves por entorno corrió en dos ventanas, de 04:42 a 05:14 y de 06:36 a 07:15 UTC.
Railway cortó el acceso a las 07:14 UTC: apagó las credenciales de nube activas, revocó las estáticas y cerró el servicio de descifrado. A las 09:24 UTC dio al atacante por expulsado por completo, unas 26 horas después del primer escape.
El botín incluyó credenciales vinculadas de 1.852 usuarios: llaves propias que cada cliente conecta con su cuenta y credenciales OAuth de GitHub. Railway restableció todas esas credenciales y avisó a cada usuario; la empresa afirma que no detectó inicios de sesión en cuentas con material robado en este incidente.
BleepingComputer contó la misma cifra de gasto, unos US$740.000 en uso fraudulento de modelos, y recordó el aviso inicial del 22 de octubre. Ese uso ajeno tiene nombre en el sector: LLMjacking, gastar la cuota de IA pagada por otro, a menudo para revender acceso o destilar modelos.
El caso encaja en la serie que el sector llamó claves de IA robadas en el Black October, con nueve plataformas tocadas en un mes. Railway aporta una diferencia: su informe admite que el atacante trabajó con modelos sin salvaguardas y un armazón parecido a ARTEX, datos de Wiz incluidos en el propio texto de la empresa.
Compilaciones en máquinas propias y secretos bajo llave central
La respuesta cambió la arquitectura, no solo las contraseñas. Railway detuvo las compilaciones dos veces, invalidó todas las sesiones y credenciales de usuario el 21 de octubre a las 20:19 UTC y restauró el servicio por planes hasta el 22 de octubre a las 22:49 UTC.
Cada compilación corre ahora en una máquina virtual efímera y dedicada, con una credencial que solo puede publicar su propia imagen. Los sistemas compartidos que el atacante aprovechó quedaron fuera de servicio, y los nuevos registros tardaron porque la empresa tuvo que aprovisionar una flota entera a toda prisa.
El almacenamiento de secretos también cambió de forma. Todas las operaciones de cifrado y descifrado quedan registradas en un registro central de auditoría, y ningún servicio fuera del servicio de secretos puede pedir las llaves que abren las credenciales de cada entorno.
Para el dinero, la empresa puso un formulario donde cada cliente reporta cargos que no reconoce. AWS Bedrock y Google Gemini devuelven el gasto fraudulento, OpenAI revisa caso por caso, OpenRouter se negó a devolver y Railway pagará esa parte.
Quien tenga un proyecto alojado allí y no haya rotado sus secretos tras el aviso de octubre conserva una tarea pendiente con fecha vieja: cambiar cada clave guardada como variable, empezando por las de proveedores de IA, porque fueron las que el atacante buscó por nombre, una por una, dentro de la base de datos.
Fuente: Railway
