Volver al blog
Cloud

Incidente de seguridad en Railway: qué ha pasado y qué hacer ahora con tus credenciales

Hugo Laguna
Incidente de seguridad en Railway: qué ha pasado y qué hacer ahora con tus credenciales

Railway confirma un acceso no autorizado a variables de entorno de clientes, algunas descifradas. Qué sabemos, qué rotar ahora mismo y qué vigilar en los próximos días.

El 21 de octubre de 2026, Railway, la plataforma de despliegue (PaaS) que usamos en parte de nuestro stack, publicó un aviso de seguridad. Había detectado actividad anómala en los sistemas donde guarda las variables de entorno de sus clientes: el lugar donde normalmente viven las claves de API, las contraseñas de bases de datos y otros secretos de una aplicación.

En resumen: si tienes servicios en Railway, trata como comprometido cualquier secreto que guardaras en sus variables de entorno. Rótalo en el proveedor que lo emite, revoca el anterior, actualiza el valor en Railway, vuelve a desplegar y revisa los logs.

Qué ha pasado

Según Railway, un tercero no autorizado pudo acceder a variables de entorno cifradas y, en algunos casos, obtener su contenido descifrado. Esas variables pueden incluir claves de API y credenciales de bases de datos y de registros privados de imágenes.

Railway cree que el ataque forma parte de una serie de ataques recientes contra empresas de plataforma, cuyo objetivo final es comprometer a proveedores de inferencia de IA. Ha avisado a esos proveedores para que revoquen claves de forma preventiva.

Como medida de contención, Railway pausó todos los builds y despliegues durante horas, invalidó todos sus tokens de API, rotó las credenciales de todos los storage buckets y cerró sesiones de usuarios. Ya se pueden desplegar con normalidad en todos los planes, aunque los registros de cuentas nuevas siguen pausados.

¿Han robado las credenciales? Lo que está confirmado y lo que no

Conviene ser precisos, porque circulan titulares de todo tipo:

  • Confirmado por Railway: hubo acceso no autorizado a sus sistemas de variables de entorno, y para una parte de ellas el atacante pudo obtener el contenido descifrado. Recomienda a todos los usuarios rotar sus secretos, no solo a los afectados.
  • Todavía sin aclarar: cuántas cuentas están afectadas, cómo entró el atacante y quién es. Railway está enviando emails a los clientes con alta probabilidad de impacto y prevé publicar un informe preliminar.
  • Reportado por terceros, sin confirmar por Railway: la investigadora de seguridad Taylor Monahan calcula unos 371.000 $ vaciados de carteras de criptomonedas cuyas claves privadas estaban en Railway. Railway no ha confirmado esa relación.

Dicho de otra forma: no sabemos si tus credenciales concretas se han filtrado, pero Railway no puede descartarlo y pide actuar como si así fuera. Es lo prudente.

Cronología (hora UTC)

  • 21 oct, 07:24: Railway abre una incidencia y empieza a investigar problemas en la plataforma.
  • 21 oct, 11:33: el dashboard, la API y la CLI no están disponibles y los builds quedan pausados en todas las regiones.
  • 21 oct, tarde: publica el aviso de seguridad y pide rotar todas las variables de entorno. A las 22:10 empieza a rotar todas las credenciales de storage buckets.
  • 22 oct, 01:22: publica guías paso a paso para rotar credenciales y revisar servicios conectados.
  • 22 oct, 04:17: invalida todos los tokens de API de Railway.
  • 22 oct, durante el día: reactiva los builds por fases (Enterprise, Pro, Hobby y, a las 22:49, Free y Trial).
  • 23 oct: sigue enviando emails a clientes afectados y prevé publicar su informe preliminar hacia el mediodía (hora del este de EE. UU.).

Qué hacer ahora mismo

La regla de oro: rota en el origen, no solo en Railway. Cambiar el valor de una variable en Railway no sirve de nada si la clave antigua sigue activa en Stripe, AWS u OpenAI: quien la tenga podrá seguir usándola.

  1. Haz inventario. Lista todas las variables de entorno de cada proyecto y de cada entorno (producción, staging, entornos de PR). Marca cuáles son secretos y quién los emite.
  2. Rota cada clave de API en su proveedor. Genera una nueva, revoca la antigua y actualiza la variable en Railway. Empieza por las de mayor impacto: pagos (Stripe), nube (AWS, GCP), GitHub y proveedores de IA.
  3. Cambia las credenciales de tus bases de datos (PostgreSQL, MySQL, MongoDB, Redis). Railway tiene una guía para cada una.
  4. Crea tokens nuevos de Railway. Los tokens de API y de proyecto anteriores al incidente están invalidados. Si tu CI/CD o tus scripts usan la API pública o la CLI con token, fallarán hasta que los actualices.
  5. Redespliega los servicios que usan storage buckets para que recojan las credenciales nuevas que generó Railway, y vuelve a conectar GitHub si te lo pide.
  6. Rota las credenciales de registros privados de imágenes (Docker Hub, GHCR u otros).
  7. Revisa el consumo en tus proveedores de IA (OpenAI, Anthropic, OpenRouter, Grok…). Son el objetivo declarado de esta campaña: busca picos de uso, modelos que no usas o gastos inesperados.
  8. Busca accesos anómalos en AWS, GCP, GitHub y Stripe: usuarios o claves nuevas, cambios de permisos o de facturación, webhooks que no reconoces.
  9. Si guardabas claves privadas de carteras cripto o de firma, da por perdido su secreto: genera claves nuevas desde un entorno limpio y mueve los fondos o activos cuanto antes.
  10. Revisa los logs de tus servicios y, si encuentras indicios de abuso, guarda las evidencias antes de borrar nada.
  11. Revisa tu email. Railway está contactando directamente con las cuentas que confirma como afectadas.

Qué tener en cuenta para lo que viene

Sigue el incidente de cerca. El alcance todavía puede cambiar. Railway publica las novedades en su página de estado, status.railway.com, donde puedes suscribirte para recibir avisos. Lee también el informe preliminar cuando se publique: puede traer nuevas recomendaciones.

No es un caso aislado. Railway lo enmarca en una campaña contra plataformas, y esta misma semana la herramienta OpenCode informó del robo de claves de API de parte de sus clientes. Los proveedores donde guardamos secretos son ahora un objetivo en sí mismos.

Algunas prácticas que reducen el daño la próxima vez:

  • Menos secretos estáticos. Donde se pueda, usa identidades federadas (OIDC) o credenciales de corta duración en lugar de claves fijas de AWS o GCP en variables de entorno.
  • Mínimo privilegio. Una clave por servicio y por entorno, con solo los permisos que necesita. Si una se filtra, el daño queda acotado.
  • Límites de gasto y alertas. Configura topes de consumo en proveedores de IA y de nube, y alertas de facturación que te avisen de un uso anormal en horas, no a final de mes.
  • Un plan de rotación ensayado. Saber dónde se usa cada secreto y poder rotarlo en minutos. Si este incidente te ha costado horas solo hacer el inventario, es el momento de documentarlo.
  • Un plan B de despliegue. Durante horas no se podía desplegar en Railway, ni siquiera para aplicar las credenciales nuevas. Ten claro cómo desplegarías un servicio crítico en otra plataforma si hiciera falta.

¿Necesitas ayuda? En Experimentality Labs te acompañamos

Si tienes servicios en Railway, o en cualquier otra plataforma, y no sabes por dónde empezar, en Experimentality Labs podemos ayudarte a inventariar tus secretos, rotarlos de forma ordenada sin tirar producción, revisar accesos sospechosos y dejar preparado un plan para la próxima vez. Escríbenos y lo revisamos contigo.

Fuentes

railwayseguridadcredencialessecretosclouddevopsincidente