La filtración de variables de entorno de Railway: lo que Railway confirmó, y lo que cambia en un servidor que es tuyo
El 21 de octubre de 2026, Railway publicó una divulgación de seguridad: una parte no autorizada obtuvo acceso a los sistemas que almacenan las variables de entorno de los clientes, y para algunos clientes, obtuvo los valores descifrados de esas variables. Railway pausó todos los despliegues en toda la plataforma, revocó sus propios tokens de acceso, y pidió a cada cliente que rotara cada secreto almacenado en la plataforma. Esto es lo que Railway mismo confirmó, lo que sigue siendo de segunda mano, y la verdadera razón arquitectónica por la que un modelo donde tú posees el servidor cambia la forma de este riesgo específico, no todo el riesgo, la forma de ese en particular.
Lo que Railway mismo divulgó
Railway publicó dos documentos que importan aquí: una divulgación de seguridad el mismo día, 21 de octubre, y un informe preliminar de incidente más extenso unos días después. Ambos siguen en línea en el blog de Railway, y son la fuente principal de todo lo que sigue.
Según el informe preliminar de Railway, el ataque ocurrió entre el 20 de octubre, 13:58 UTC, y el 22 de octubre, 03:32 UTC — la segunda marca de tiempo señala el momento en que Railway confirmó que el atacante ya no tenía acceso a ningún sistema interno. La primera señal fue mundana: una alerta de monitoreo al ingeniero de guardia por latencia elevada. La investigación convirtió eso en algo más, rápido. Para las 14:03 UTC del día 20, el equipo de Railway ya había identificado un intento de escalada de privilegios en su infraestructura de build y detuvo los pipelines de build. A las 19:53 UTC ese mismo día, nueva evidencia mostró que el atacante podía escalar su acceso “a mayor escala, a través de múltiples partes del sistema de Railway, en paralelo” — en ese punto Railway lo trató como una campaña sostenida y dirigida, no un error aislado. Para el 21 de octubre a las 07:25 UTC, el análisis forense mostró que el atacante había llegado al entorno de CI de Railway y descifrado artefactos con credenciales de API.
El propio relato de Railway sobre la motivación del atacante es específico: el informe dice que el atacante “intentaba obtener claves API de proveedores de IA para realizar ataques de destilación”, y que la evidencia temprana sugería que el atacante tenía acceso a “modelos abliterated y recursos de cómputo sustanciales” que permitieron una explotación inusualmente sofisticada de la infraestructura de Railway. Que esa atribución se sostenga o no conforme avance la investigación, es la propia caracterización de Railway, no una suposición de la cobertura externa.
La parte que llega directamente a los clientes: el atacante accedió a los sistemas internos de Railway y descifró variables de entorno almacenadas para un subconjunto de espacios de trabajo de clientes. Las propias cifras de Railway, publicadas en el informe preliminar: como máximo el 1.85% de todos los espacios de trabajo tuvieron algunas variables de entorno potencialmente comprometidas, unos 100,000 espacios de trabajo, según el conteo de Railway. Railway dice que esa cifra se mantuvo porque sus sistemas están “construidos de modo que si un conjunto de claves se compromete, no debería comprometer todo el sistema” — es decir, el radio de impacto se contuvo por diseño, no por suerte. Por separado, Railway notificó directamente a un número mayor (no especificado) de espacios de trabajo que juzgó de alto riesgo según el análisis forense de lo que el atacante realmente estaba buscando, sobre todo espacios de trabajo con claves de proveedores de IA de alto valor. Las cuentas individuales de usuarios de Railway en sí no fueron accedidas ni comprometidas; esto fue sobre las variables de entorno ligadas a los espacios de trabajo, no sobre una toma de cuentas.
La respuesta de Railway, en sus propias palabras: todos los despliegues se pausaron en toda la plataforma durante el triage (los despliegues ya existentes siguieron en línea; lo que se detuvo fueron los nuevos builds y nuevos despliegues saliendo). Railway revocó todos sus propios tokens de acceso “por exceso de precaución”. Notificó a proveedores aliados — GitHub, GitLab y proveedores de IA entre otros — para que pudieran revocar proactivamente las credenciales expuestas, completado a las 09:25 UTC del 21 de octubre. Sus acciones recomendadas para cada cliente: rotar cada variable de entorno y clave API almacenada en Railway, renovar las credenciales de registro privado, eliminar el acceso de red pública a bases de datos donde existiera, y revisar los registros de auditoría de GitHub y de registros Docker en busca de algo inusual. Los despliegues se restauraron gradualmente a partir del 22 de octubre, con restauración completa más tarde ese mismo día.
¿Por qué se expusieron las variables de entorno de Railway?
Según lo que Railway ha publicado, el camino fue: escalada de privilegios dentro de la infraestructura de build de Railway, que le dio al atacante un punto de apoyo en el entorno de CI, el cual contenía artefactos descifrados con credenciales de API — y desde ahí, el acceso se extendió a los sistemas que almacenan las variables de entorno de los clientes, permitiendo al atacante descifrar un subconjunto de ellas. La versión corta: un solo sistema interno comprometido (build/CI) bastó para llegar a un sistema distinto (el almacén de secretos cifrados) que, por sí solo, debería haber sido un blanco más difícil. Ese encadenamiento es la verdadera lección, más que cualquier paso aislado.
Lo que sigue siendo de segunda mano, no palabras de Railway
Algunos detalles que circularon ampliamente desde la divulgación no vinieron del propio blog de Railway, y deberían leerse como reportados, no confirmados. La investigadora de blockchain Taylor Monahan y varios medios de la industria cripto reportaron que claves privadas de wallets almacenadas como variables de entorno en Railway fueron vaciadas por una sola dirección, con pérdidas reportadas de alrededor de $371,000 en más de 500 transacciones, en más de 19 cadenas EVM, y un primer robo con marca de tiempo aproximadamente dos horas antes del aviso público de Railway. Los propios materiales publicados de Railway no mencionan una cifra de robo en cripto, una dirección de wallet del atacante específica, ni esa comparación de tiempos — ese encuadre viene enteramente de investigadores externos y los medios que los cubren. Es plausible, encaja con el tipo de espacio de trabajo que el atacante parecía priorizar, pero no es algo que este artículo pueda verificar más allá de “varios medios lo reportaron, Railway no confirmó ni negó la cifra específica en sus propias publicaciones hasta el momento de escribir esto.”
Por qué un modelo BYO-server cambia la forma del riesgo, honestamente
Sería fácil escribir esta sección como “Railyard no tiene este problema.” Eso no es exacto, y vale la pena ser precisos sobre por qué.
El plano de control de Railyard también almacena las variables de entorno de los clientes de forma centralizada, cifradas en reposo, en su propia base de datos, usando el mismo enfoque general (cifrado en reposo con una clave en poder del servidor) que cualquier plataforma que almacena secretos de clientes, Railway incluida. Si la propia base de datos del plano de control de Railyard y su clave de cifrado estuvieran ambas comprometidas, la misma clase general de exposición que Railway describió es estructuralmente posible aquí también. Ser dueño de tu propio servidor no cambia el hecho de que un panel central tiene que guardar tus variables en algún lugar antes de poder entregarlas a un servidor — alguien tiene que custodiar el secreto entre el momento en que lo escribes y el momento en que tu app lo lee.
Lo que sí cambia es qué pasa después de eso: dónde termina viviendo la copia descifrada, y qué tiene que vulnerar un atacante para llegar a un secreto vivo, descifrado, realmente en uso. En el caso de Railway, el camino real que tomó el atacante pasó por infraestructura de build y un entorno de CI que son parte del propio entorno operativo compartido y multiinquilino de Railway — los mismos sistemas que construyen y ejecutan las aplicaciones de todos. Un error de escalada de privilegios en esa infraestructura compartida puso al atacante en posición de alcanzar secretos de espacios de trabajo que no tenían nada que ver con la vulnerabilidad original. La infraestructura de build, el plano de control, y el cómputo que ejecuta el código del cliente están todos dentro del perímetro interno de una sola empresa, así que una grieta en cualquiera de ellos es potencialmente una grieta en todos.
En un modelo BYO-server, el plano de control igual tiene que descifrar las variables de un cliente en algún momento, pero lo hace para entregarlas, una vez, en el momento del despliegue, a un servidor que está en la propia cuenta de nube de ese cliente específico, no a una flota de cómputo compartida que opera la plataforma. La copia viva y descifrada del entorno de una aplicación —la que un atacante realmente quiere, porque es la que está en la memoria de un proceso en ejecución— existe en una infraestructura a la que los propios ingenieros de la plataforma no tienen acceso permanente fuera de ese único paso de entrega. Un error en el propio pipeline de build de la plataforma es un riesgo real para los datos del plano de control de la plataforma (igual que en cualquier lugar), pero no le da a un atacante una flota de cómputo compartida por la cual pivotar hacia los secretos vivos de otros clientes, porque no existe tal flota — el entorno “vivo” de cada cliente es una máquina distinta, en una cuenta distinta.
Esa es una afirmación más estrecha que “esto no puede pasar”, y debería serlo: es específicamente sobre el radio de impacto a través del cómputo compartido, no una afirmación de que el cifrado de Railyard sea criptográficamente más fuerte que el de Railway. El encuadre honesto es que un modelo BYO-server elimina un camino específico hacia el peor resultado —un atacante pivotando de un error del lado de la plataforma directamente hacia los secretos vivos de muchos clientes no relacionados vía infraestructura de ejecución compartida— sin eliminar todos los demás caminos, incluyendo una brecha en la propia base de datos del plano de control y su material de claves, que sigue siendo un riesgo que cualquier panel centralizado carga, sin importar dónde viva el cómputo.
Qué significa esto para ti, sin importar la plataforma
Algunas conclusiones prácticas aplican sin importar si estás en Railway, Railyard, o cualquier otra cosa que guarde secretos en un panel:
- Rota todo lo que pase por el panel de cualquier plataforma según un calendario regular, no solo después de una divulgación de brecha — claves API estáticas y de larga duración sentadas en un almacén centralizado son un pasivo permanente, independiente de cualquier incidente específico.
- Limita estrictamente el alcance de las credenciales. Una credencial de base de datos que solo puede llegar a una sola base de datos, o una clave API con los permisos mínimos que necesita, limita lo que realmente vale una copia robada.
- Prefiere los roles IAM nativos de tu proveedor de nube o credenciales de corta duración por encima de secretos estáticos, donde el proveedor lo permita — una opción que existe precisamente porque, en un modelo BYO-server, el cómputo está en tu propia cuenta, así que el sistema de identidad nativo de tu propia nube es una opción en primer lugar.
- Pregunta, para cualquier plataforma que uses, qué tiene que comprometerse para llegar a un secreto descifrado realmente en uso — no solo si la base de datos está cifrada en reposo. El cifrado en reposo es lo mínimo esperado; la pregunta real es cuántos sistemas hay entre un error en una parte no relacionada de la plataforma y los secretos reales de tu aplicación en ejecución.
Mira la comparación completa: Railyard contra Railway, y el modelo de variables de entorno en sí: Variables y secretos. Si estás migrando de Railway específicamente: Migrar desde Railway.
Preguntas frecuentes
¿Por qué se expusieron las variables de entorno de Railway? Según el propio informe preliminar de Railway, un atacante escaló privilegios dentro de la infraestructura de build de Railway, llegó a su entorno de CI, y desde ahí accedió a los sistemas que almacenan variables de entorno de clientes, descifrando un subconjunto de ellas. Railway no ha divulgado la vulnerabilidad técnica específica que permitió la escalada inicial.
¿Cuántos clientes de Railway fueron afectados? La propia cifra de Railway es como máximo el 1.85% de todos los espacios de trabajo, unos 100,000, con algunas variables de entorno potencialmente comprometidas. Un número mayor y no especificado de espacios de trabajo juzgados de alto riesgo fueron notificados directamente por separado.
¿Railway confirmó el robo de cripto reportado? No. La cifra de aproximadamente $371,000, la dirección de wallet específica, y la comparación de tiempos con el aviso público de Railway vienen todas de investigadores externos de blockchain y medios especializados en cripto, no de la divulgación publicada ni del informe preliminar de Railway mismo.
¿Alojar en tu propio servidor hace esto imposible? No. La base de datos del plano de control de una plataforma igual tiene que guardar tus secretos en algún lugar antes de desplegarlos, y ese almacén sigue siendo un blanco sin importar la arquitectura. Lo que cambia es que la copia viva y descifrada corriendo en tu aplicación vive en tu propio servidor en vez de en la flota de cómputo compartida de la plataforma, lo cual elimina un camino específico —un error del lado de la plataforma convirtiéndose en una ruta hacia los secretos vivos de otros clientes— sin eliminar todo riesgo.
Fuentes
- Security Disclosure: Wednesday October 21st — blog propio de Railway
- Preliminary Report: Oct 21st Security Incident — blog propio de Railway
- Railway discloses breach of encrypted environment variables, pauses all deployments — cobertura secundaria
- Railway Security Flaw Puts Customer Funds in Crypto at Risk, Deployments Halted — cobertura secundaria, las cifras de robo en cripto reportadas aquí no están confirmadas por Railway