Incidente de seguridad en Railway: variables de entorno expuestas. Guía práctica para rotar secretos

Qué pasó en Railway

Railway es una plataforma como servicio en la que las aplicaciones leen su configuración, incluidas claves de API y contraseñas de bases de datos, de variables de entorno que Railway guarda cifradas. El informe preliminar de Railway describe el ataque:

• Una probable escalada de privilegios en su infraestructura de compilación.
• Acceso a credenciales de la CI, con las que el atacante descifró artefactos que daban más acceso a otras API.
• Una consulta no autorizada de variables de entorno cifradas, de las que una parte se descifró con las credenciales comprometidas.

Railway no ha publicado cómo entró el atacante al principio, y la investigación forense sigue abierta. Las horas son UTC.

Los servicios en marcha siguieron funcionando. Solo se pararon las compilaciones y los despliegues.

Qué quedó expuesto y quién corre riesgo

• Alcance: «como mucho el 1,85 % de todos los espacios de trabajo tuvo alguna variable de entorno potencialmente comprometida», unos 100.000. Como las variables usan cifrado de sobre, Railway no puede identificar exactamente qué claves se descifraron.
• Mayor riesgo: los espacios de trabajo con muchísimas variables de entorno y los entornos con muchas claves de proveedores de IA.
• El objetivo: claves de proveedores de IA para hacer ataques de destilación de modelos, según Railway. También lo enmarca en una serie de ataques contra empresas de plataformas.
• No afectadas: las cuentas de usuario de Railway, según Railway. No descarta el acceso al código fuente de los clientes y lo confirmará en su informe final.
• El resto: Railway escribió a los espacios con impacto confirmado o de alto riesgo, pero dice que los demás «no están confirmados como a salvo».

Railway no ha publicado indicadores de compromiso y no ha confirmado usos indebidos de los secretos robados. The Hacker News recoge la afirmación de un tercero sobre carteras de criptomonedas vaciadas cuyas claves privadas estaban en Railway. Railway no la ha confirmado.

Qué hizo Railway

• Paró las compilaciones, apagó las herramientas internas que podían estar comprometidas y las reconstruyó desde código validado.
• Cambió dos veces todas sus claves internas y rotó las credenciales de todos los buckets de almacenamiento.
• Invalidó todos los tokens de API y de proyecto y todas las sesiones de usuario, y renovó todas las instalaciones de su GitHub App.
• Pasó las compilaciones a máquinas de un solo cliente.
• Pidió a GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Stripe, Google y otros que revocaran claves. Entregó a GitHub y SpaceXSI todas las claves presentes en la plataforma, así que un aviso de revocación de un proveedor no significa por sí solo que tu clave se descifrara.

Cómo rotar tus secretos, en orden

La petición de Railway es amplia: revocar y sustituir todas las variables sensibles guardadas antes del 21 de octubre, incluidas las credenciales de registros privados, y volver a desplegar. Con decenas de secretos, el orden importa. Empieza por lo que un atacante convierte antes en dinero o en más acceso.

1. Haz el inventario

Exporta los nombres de las variables de cada proyecto y entorno (desde el panel de Railway o con railway variables y un token nuevo). Anota en cada una su proveedor, qué permite y quién puede rotarla. Las variables compartidas y las de referencia también cuentan.

2. Rota en este orden

3. Rota sin cortes de servicio

1. Crea la credencial nueva en el proveedor, con el alcance mínimo y con caducidad o límite de gasto si el proveedor lo permite.
2. Guárdala en Railway (o pásala a un gestor de secretos) y vuelve a desplegar. Railway invalidó los tokens de API antiguos, así que crea uno nuevo para la CLI y para la CI.
3. Comprueba que el servicio funciona con el valor nuevo: chequeos de salud, una petición de prueba, la marca de «último uso» del proveedor.
4. Revoca la credencial antigua en el proveedor. Un secreto sustituido pero no revocado sigue sirviendo a quien lo robó.
5. Apunta qué rotaste y cuándo. Lo necesitarás para leer los registros y para responder a Railway o a tus propios clientes.

Cómo detectar usos indebidos

• Proveedores de IA: paneles de consumo y coste desde el 20 de octubre. Busca picos, modelos que no usas y peticiones desde direcciones IP o regiones desconocidas. Railway ha publicado comprobaciones para el consumo de OpenAI, Anthropic, OpenRouter y Grok.
• AWS y GCP: CloudTrail y Cloud Audit Logs para llamadas hechas con tus claves desde fuera de tu infraestructura. Empieza por GetCallerIdentity, usuarios, claves o roles IAM nuevos y regiones inesperadas.
• GitHub y GitLab: el registro de auditoría de la organización, en busca de tokens, claves de despliegue, autorizaciones de OAuth o de GitHub Apps y clonados de repositorios nuevos. Revisa también qué aplicaciones tienen acceso.
• Registros de paquetes e imágenes: los registros de auditoría de Docker Hub, npm y PyPI, en busca de subidas o publicaciones que no hiciste tú.
• Stripe y proveedores de pago: registros de peticiones a la API y eventos, en busca de reembolsos, pagos, webhooks o claves creados después del incidente.
• Bases de datos: conexiones desde direcciones desconocidas, usuarios nuevos y exportaciones grandes, sobre todo en bases de datos con acceso público por red.

Que no haya alertas prueba poco. Muchos proveedores guardan los registros detallados poco tiempo, así que expórtalos ya.

Deja de guardar claves de larga duración

Rotar arregla este incidente. Las credenciales de corta duración hacen más pequeño el siguiente:

• Usa federación de identidad de cargas de trabajo (OIDC) en lugar de claves de acceso a la nube. GitHub Actions, GitLab CI y muchas plataformas pueden cambiar un token de identidad firmado por credenciales temporales de AWS, GCP o Azure que caducan en minutos, así que no hay ninguna clave que robar de una variable de entorno.
• Guarda los secretos en un gestor de secretos con credenciales dinámicas (como Vault o el almacén de secretos de tu nube). La aplicación pide credenciales de base de datos que caducan, en lugar de llevar una contraseña durante años.
• Limita el alcance y el gasto de las claves de API. Usa una clave por servicio y entorno, con solo los permisos que necesita, límites de gasto y listas de IP permitidas cuando el proveedor lo admita, y con un responsable y una fecha de caducidad.
• Haz de la rotación una rutina. Un servicio que no puede rotar un secreto sin cortes lo dejará para más tarde en pleno incidente. Ensáyalo.

Dónde encaja OpenWAF

Un WAF no protege los secretos guardados dentro de una plataforma de alojamiento, ni puede impedir que un atacante use una clave de API robada directamente contra el proveedor. Lo que sí puede hacer es limitar lo que un secreto robado de tu aplicación permite por la puerta principal, y evitar que alguien llegue a tu origen rodeándola:

• Un origen que solo responde a OpenWAF. Con la autenticación del borde ante el origen (mTLS), el borde de OpenWAF presenta un certificado de cliente y tu servidor puede rechazar cualquier conexión que no pase por OpenWAF. Quien descubra la dirección de tu origen en una configuración filtrada sigue sin poder saltarse tus reglas del WAF, tus límites de peticiones ni tu puerta de acceso. La CA de cliente es común a toda la plataforma: prueba que la conexión viene del borde de OpenWAF, no que sea para tu zona, así que sigue comprobando también el Host.
• Una puerta de acceso que no depende de los secretos de la aplicación. Si se filtró un secreto de sesión o de firma de JWT, un atacante puede falsificar una sesión de administrador con aspecto válido. La puerta de acceso retiene en el borde rutas de administración como /admin o /wp-admin hasta que la persona introduce un código de un solo uso enviado a un correo autorizado. Una cookie falsificada no basta.
• Límites de peticiones y reglas de IP en el inicio de sesión, el restablecimiento de contraseña y las rutas de API frenan a quien pruebe credenciales robadas (límites de peticiones, reglas de IP y país).
• Rota también tu token de OpenWAF. Si entre tus variables de Railway había un token de API de OpenWAF, revócalo en el panel y crea otro. Los tokens pueden ser de solo lectura o estar limitados a un cliente o a un dominio, y cada cambio hecho con un token queda versionado y en el registro de auditoría.

OpenWAF protege el tráfico HTTP y HTTPS. No se pone delante de los puertos de las bases de datos, así que cerrar su acceso público, como recomienda Railway, sigue siendo cosa tuya.

Lista de comprobación

1. Exporta los nombres de todas las variables de Railway, de cada proyecto y entorno, creadas antes del 21 de octubre de 2026.
2. Rota primero las claves de proveedores de IA, las credenciales de nube y las claves de carteras; después pagos, control de código y registros, bases de datos, secretos de la aplicación y otras claves de SaaS.
3. Con cada una: crea la nueva, despliégala, compruébala y revoca la antigua en el proveedor.
4. Crea tokens nuevos de API y de proyecto de Railway y actualiza la CI y los scripts.
5. Quita el acceso público por red a las bases de datos que no lo necesiten.
6. Revisa el consumo en los proveedores, CloudTrail o Cloud Audit Logs, GitHub, los registros de imágenes, Stripe y las bases de datos desde el 20 de octubre, y exporta esos registros antes de que caduquen.
7. Sustituye las claves de nube de larga duración por federación OIDC y credenciales de corta duración, y pon límites de gasto y caducidad a las claves de API.
8. Limita tus orígenes a tu WAF con mTLS y pon las zonas de administración detrás de una puerta de acceso que no dependa de los secretos de la aplicación.

Preguntas frecuentes

Fuentes

• Security Disclosure: Wednesday, October 21st Railway, 21 oct 2026
• Preliminary report: October security incident Railway, 22 oct 2026
• Railway Platform Outage (incident QH8L8B3E) Railway Status, 21 oct 2026
• Security Disclosure Recommendation: Check for Anomalous AWS Access Railway, 22 oct 2026
• Security Disclosure Recommendation: Check for Unexpected OpenAI Usage Railway
• Railway says intruder may have accessed customer environment variables The Hacker News, 22 oct 2026