Railway pagará 740.000 dólares por claves de IA robadas

Railway cifró el 10 de noviembre de 2026 en unos 740.000 dólares el consumo fraudulento que un atacante hizo con claves de proveedores de inteligencia artificial robadas a sus clientes. La cifra aparece en el informe de Railway sobre el incidente de octubre que la plataforma publicó ese día, y llega con una promesa poco habitual en este tipo de brechas: la empresa pagará de su bolsillo lo que los proveedores no devuelvan. No es una auditoría ni una liquidación cerrada, sino una estimación de parte que la compañía no explica cómo calculó.

Railway vende una plataforma para desplegar aplicaciones sin montar servidores, y en ella los equipos guardan sus variables de entorno: cadenas de conexión, contraseñas y claves de API de terceros. Quien lee esas variables no obtiene datos de una empresa, sino la tarjeta de cientos.

El asalto empezó en el sistema de compilación, el que construye las aplicaciones antes de publicarlas, y ese es el punto que conviene mirar con lupa. De ahí salieron credenciales internas, historiales de otras compilaciones y claves con las que terceros facturaron a clientes de Railway. La plataforma sostiene que no hay pruebas de acceso a bases de datos de clientes ni de descarga de repositorios, y que lo copiado sin descifrar ya no se puede abrir.

¿Qué pasó entre el 20 y el 21 de octubre?

A las 06:50 UTC del 20 de octubre el atacante sondeaba la infraestructura de compilación. A las 07:28 explotó un fallo desconocido, escapó en parte del aislamiento de ficheros y leyó archivos del anfitrión. De ahí salió la credencial que empuja imágenes al registro interno.

El fallo no fue el final del camino, sino la puerta. La instancia interna de Temporal, el sistema que orquesta tareas asíncronas, aceptó esa credencial de compilación como cliente de confianza, y por ahí el atacante leyó historiales de otras compilaciones con sus variables y secretos incluidos. Es el mismo tipo de salto que describen los análisis de escapes de invitado a anfitrión: una barrera que cede en un punto y expone todo lo que comparte la misma máquina.

Con ese acceso recuperó además una copia del monorepo interno, porque una de las compilaciones leídas correspondía al panel de soporte que Railway despliega sobre sí misma. El informe lo dice sin rodeos: el atacante tuvo una vista privilegiada del funcionamiento de la plataforma y la usó para buscar rutas nuevas con rapidez. La alerta saltó a las 13:58 UTC por llamadas anómalas a la API del registro, y la expulsión completa llegó a las 09:24 UTC del 21 de octubre.

En medio, Railway paró las compilaciones en dos tandas, rotó credenciales internas y reconstruyó herramientas desde código validado. Los despliegues que ya estaban en marcha siguieron funcionando durante el corte, aunque nadie podía publicar cambios.

Un gasto no autorizado

El dinero es la parte que más se ha movido desde el informe preliminar. El documento reconoce que el gasto no autorizado con las claves robadas se estima en 740.000 dólares y que la empresa negocia devoluciones con los proveedores mientras adelanta el dinero de los que se niegan. La cifra no tiene desglose público: el informe no dice qué periodo cubre ni cómo la calculó.

Hay un cambio de postura que conviene registrar. El 26 de octubre, cuando los clientes empezaron a preguntar por los cargos, Railway respondió que no podía devolver el gasto hecho con claves comprometidas y les animó a reclamar a cada proveedor. El informe del 10 de noviembre invierte esa respuesta y convierte a la plataforma en pagador de última instancia. La compañía no explica el giro, aunque el resultado es más favorable para quien se encontró con la factura.

Las diferencias entre filas marcan cuánto tarda un cliente en recuperar el dinero y quién asume el riesgo de una reclamación a medias. Además, el formulario de cargos no revoca ninguna clave, y es el cauce que el informe indica para reclamar.

El alcance real del evento

El alcance real es más pequeño de lo que sugiere el titular y más grande de lo que tranquiliza. Los registros permiten afirmar que, como máximo, el 1,85% de los espacios de trabajo, unos 100.000, pudo tener variables descifradas. El informe insiste en que es un techo: los registros identifican entornos, no variables sueltas, así que no hay forma de saber cuántas claves quedaron expuestas.

Los tokens ligados a cuentas sí están contados. Fueron 1.852 usuarios con claves BYOK de agentes y tokens OAuth de GitHub, todos reseteados y notificados. La empresa dice no haber detectado inicios de sesión en cuentas de Railway con credenciales del incidente, y tampoco pruebas de acceso a bases de datos de clientes ni de descarga de repositorios. Lo que no se descifró ya no se puede descifrar, porque la credencial que lo permitía está desactivada.

Queda la duda razonable de siempre: si el atacante copió variables y no llegó a abrirlas, no hay registro que lo demuestre. Railway apoya esa parte del relato en la desactivación de la credencial y en sus propios registros.

El consejo operativo del informe es el mismo que repiten los equipos de seguridad desde hace años: revocar y rotar cualquier secreto guardado en la plataforma antes del 21 de octubre, y hacerlo en el proveedor que emitió la clave. Un episodio del 10 de noviembre lo ilustra: las credenciales de Claude Code filtradas en 1.122 repositorios públicos muestran lo rápido que una clave en texto plano pasa de descuido a problema de facturación.

La ola de octubre que nadie estaba mirando

Railway no fue un caso aislado, y su informe lo admite al hablar de una serie de ataques contra plataformas que guardan claves de IA. El recuento de Wiz es más amplio: al menos nueve plataformas de desarrollo con IA reconocieron incidentes entre el 6 y el 30 de octubre, y el análisis de la firma de seguridad los agrupa bajo la etiqueta de LLMJacking, el robo de capacidad de cómputo ajena para revenderla o para destilar modelos.

El patrón se repite en casi todos los comunicados: acceso a credenciales, búsqueda deliberada de variables de entorno y salida rápida por un mercado que compra tokens ajenos. La demanda de datos para entrenar y la existencia de intermediarios que revenden acceso explican por qué alguien dedica una semana a encadenar exploits en lugar de cifrar un disco y pedir un rescate. El botín se gasta en tokens, no se negocia.

Para el cliente de una plataforma PaaS, la lección incómoda es que el aislamiento del proveedor es una capa más, no una garantía. El hosting ya había mostrado esa cadena en incidentes como el de cPGuard y su canal de actualizaciones.

Lo que sigue abierto en el caso

Quedan cabos que el informe deja sin atar. Railway presentó una denuncia ante el IC3 del FBI, contrató a una firma forense externa y cerró las altas hasta el 2 de noviembre, después de pausarlas el 22 de octubre. La compañía también dice haber obtenido acceso a Project Glasswing con aprobación del Tesoro estadounidense, un programa del que no da detalles y que no aclara cómo afecta a quienes reclaman por los cargos.

Tampoco hay tope por cliente ni plazo para reclamar, y el informe no responde si hay que pagar la factura mientras la reclamación se revisa. Mientras eso siga así, la cifra de 740.000 dólares funciona como lo que es: una estimación de parte, sin auditoría, que puede subir si aparecen más cargos o bajar si los proveedores aceptan más devoluciones.

La pelota, en cualquier caso, sigue en el tejado de cada cliente. Railway puede pagar la factura y hasta reintegrarla, pero no puede rotar por nadie las claves que emitieron AWS, Google u OpenAI.

La factura de octubre dice menos sobre un atacante concreto que sobre la economía construida alrededor de las claves de IA. Mientras un token robado sea dinero instantáneo, cada plataforma que guarde secretos ajenos será un objetivo rentable, y la rotación seguirá siendo la tarea que nadie hace el mismo día en que debería.