Railway pausa los despliegues e invalida todos sus tokens de API tras un acceso no autorizado a variables de entorno de clientes

Railway, una plataforma en la nube que usan desarrolladores para desplegar aplicaciones y bases de datos sin administrar servidores, informó el miércoles 21 de octubre que detectó actividad anómala en los sistemas donde guarda las variables de entorno de sus clientes. Según el aviso publicado en su blog, la investigación indica hasta ahora que un tercero no autorizado pudo acceder a variables de entorno cifradas y, en el caso de algunas, obtener su contenido descifrado. Como respuesta, la empresa pausó todos los despliegues, invalidó todos los tokens de su API pública y recomendó a todos sus usuarios rotar de inmediato cualquier secreto almacenado en la plataforma.

La gravedad del incidente se explica por lo que suele vivir en esas variables. En plataformas de este tipo, las variables de entorno son el lugar habitual para guardar claves de API, credenciales de bases de datos, llaves de servicios en la nube y contraseñas de registros privados de contenedores, es decir, los secretos que una aplicación necesita para funcionar. Railway lo reconoce en su aviso y pide a los usuarios cambiar todas las variables de entorno, incluidas las claves de API y las credenciales de registros privados, y revisar los registros de esos servicios en busca de actividad inusual. Aunque su análisis inicial sugiere que el impacto podría limitarse a un subconjunto de usuarios, la empresa hace la recomendación a todos como precaución mientras completa la revisión, y dice que contactará por correo a las cuentas que confirme como afectadas.

Railway enmarca el incidente en un patrón más amplio. La empresa afirma que cree que forma parte de una serie de ataques dirigidos recientemente a empresas de plataformas con el objetivo de comprometer a proveedores de inferencia de IA, y que notificó a esos proveedores para que revoquen todas las claves de forma preventiva. No identificó a los atacantes ni a las otras empresas afectadas. Entre las guías que publicó después hay instrucciones para detectar uso inesperado de cuentas de OpenAI, Anthropic, OpenRouter y Grok, además de Stripe, GitHub, AWS y Google Cloud, y para rotar credenciales de bases de datos PostgreSQL, MySQL, MongoDB y Redis. En las de AWS y Google Cloud, Railway recuerda que las claves de acceso de larga duración siguen funcionando hasta que se desactivan, y recomienda desactivarlas, emitir otras nuevas y revisar los registros de auditoría de cada proveedor durante el periodo de exposición.

Las medidas de contención tuvieron un costo operativo visible para los clientes. Mientras los despliegues estuvieron pausados, no era posible publicar nuevas versiones de las aplicaciones, lo que también impedía completar los pasos de las guías que requieren volver a desplegar un servicio con las credenciales nuevas. La página de estado de Railway muestra que la empresa rotó todas las credenciales de sus buckets de almacenamiento y que fue restableciendo las compilaciones por niveles: primero para los espacios de trabajo Enterprise, luego para Pro, con Hobby, Free y Trial pendientes en sus últimas actualizaciones del 22 de octubre. Esas mismas actualizaciones describen colas de despliegues más largas de lo normal y una tasa elevada de compilaciones fallidas, y piden a los usuarios no lanzar varias veces el mismo despliegue.

Como análisis, el incidente ilustra el riesgo de concentración que asumen las plataformas que guardan secretos de miles de clientes: un acceso a esos sistemas expone a la vez credenciales de servicios de terceros, y la contención obliga a medidas que afectan a toda la base de usuarios, como invalidar tokens o detener despliegues. Railway no ha dicho cómo entró el atacante, cuántas cuentas resultaron afectadas ni durante cuánto tiempo tuvo acceso, y ha prometido nuevas actualizaciones en su blog y en su página de estado a medida que acote el alcance.