Las claves de acceso a servicios de inteligencia artificial robadas de Railway generaron un gasto no autorizado estimado en 740.000 dólares, según la investigación publicada por la plataforma el 10 de noviembre. Railway afirma que asumirá los cargos que los proveedores no reembolsen, aunque las condiciones varían según cada servicio.
La intrusión afectó a la infraestructura que Railway utiliza para compilar aplicaciones y almacenar secretos de sus clientes, como claves API y credenciales de bases de datos. La empresa calcula que el atacante llegó a descifrar variables de entorno de, como máximo, el 1,85 % de los espacios de trabajo: unos 100.000. Esa cifra es un límite superior, no el recuento de clientes cuya información se confirmó como robada.
El ataque empezó el 20 de octubre y el intruso fue expulsado de los sistemas de Railway el día 21, según el informe actualizado. La empresa no ha establecido quién operaba al atacante ni cómo calculó el gasto total de 740.000 dólares. Sí sostiene que las consultas del intruso buscaron específicamente credenciales de proveedores de IA y que el consumo fraudulento incluyó desde solicitudes de agentes de programación hasta tareas vinculadas al entrenamiento de modelos.
De una máquina de compilación a las claves de clientes
Railway detectó actividad anómala el 20 de octubre. El primer acceso, sin embargo, se había producido antes: a las 07:28 UTC, el atacante aprovechó un fallo hasta entonces desconocido en la infraestructura de compilación para escapar parcialmente del aislamiento del sistema de archivos. Pudo leer algunos ficheros de la máquina virtual anfitriona y obtener una credencial usada por los servidores de compilación para enviar imágenes y acceder a determinados sistemas internos.
La credencial debía servir para completar tareas de compilación, pero el clúster interno de Temporal —el sistema que Railway utilizaba para organizar parte de esos procesos— la aceptaba como la de un cliente de confianza. A través de sus API, el intruso consultó una parte de los historiales guardados de otros trabajos, que podían incluir variables y secretos proporcionados durante la compilación.
El informe de Railway contabiliza 353 historiales de compilación leídos entre las 13:50 y las 15:30 UTC del 20 de octubre. También indica que el atacante consiguió una copia del monorepositorio interno de la compañía: su base de código común para desplegar muchos de sus servicios. Los registros no muestran que descargara repositorios de clientes.
Con el código de Railway, el atacante buscó otras vías de acceso. Encontró una configuración incorrecta en un vínculo OIDC de uno de los entornos en la nube de la compañía y, a las 03:26 UTC del 21 de octubre, la aprovechó para conseguir una credencial temporal de ese entorno. Después obtuvo otras dos credenciales internas: una permitía leer variables cifradas en una base de datos si se utilizaba desde la red interna; la otra era una clave SSH.
La clave SSH abrió el acceso a una máquina que ejecutaba tareas de orquestación para la flota de Railway. En ella había una credencial de mayor duración que podía descifrar variables de clientes, necesaria para poner en marcha sus cargas de trabajo. Entre las 04:07 y las 05:21 UTC, el atacante extrajo de la base de datos variables cifradas; entre las 04:42 y las 05:14, y de nuevo entre las 06:36 y las 07:15, descifró algunas mediante el servicio de gestión de claves.
Los registros de la base de datos muestran que las consultas seleccionaban variables cuyos nombres coincidían con expresiones proporcionadas por el atacante. Railway afirma que esas búsquedas priorizaban claves de proveedores de IA y clientes con muchas variables almacenadas. También hubo consultas que coincidían con credenciales de servicios en la nube, bases de datos y pagos, pero la investigación no encontró indicios de acceso a bases de datos de clientes.
El informe preliminar, publicado el 22 de octubre, situaba el descifrado después de las 05:27 UTC. La investigación posterior corrigió esa secuencia: Railway determinó que comenzó a las 04:42. También precisó que el atacante había empezado a crear cuentas de prueba el 18 de octubre, aunque esos primeros intentos no tuvieron éxito.
Claves de IA y tokens de 1.852 usuarios
Railway calcula que las variables potencialmente descifradas pertenecían a un máximo del 1,85 % de los espacios de trabajo, aproximadamente 100.000. La cifra se basa en los entornos que aparecen en sus registros, no en variables concretas: por eso la compañía la presenta como un techo posible. A partir de sus análisis forenses, envió correos a los clientes que consideró de mayor riesgo.
Entre los datos descifrados también había tokens de cuentas vinculadas de 1.852 usuarios, incluidos tokens OAuth de GitHub y claves de agentes BYOK. Railway dice que restableció todos esos tokens y avisó a cada usuario. No encontró inicios de sesión en cuentas de Railway realizados con credenciales sustraídas durante el incidente.
La compañía desactivó la credencial que permitía descifrar variables. Según Railway, los datos que el intruso hubiera copiado en formato cifrado, pero no descifrado, ya no pueden recuperarse con esa credencial. Además, pidió a varios proveedores revocar claves potencialmente expuestas antes de poder determinar cuáles habían sido afectadas. Por precaución, compartió con algunos proveedores todas las claves de sus servicios que tenía almacenadas, una medida que generó solicitudes de restablecimiento a más de 100.000 usuarios. Recibir un aviso de revocación, por tanto, no demuestra por sí solo que una clave concreta estuviera expuesta.
Railway cree que las credenciales robadas se destinaron a servicios que revenden o distribuyen acceso a modelos para utilizarlos en destilación. Los ejemplos de uso fraudulento que recibió de clientes incluyen solicitudes de agentes de programación, evaluaciones del comportamiento de agentes y comprobaciones de tareas de entrenamiento y sus sistemas de puntuación. La compañía no ha averiguado si el atacante original gestionaba esos servicios o entregó las claves a terceros.
“This was not a single breach followed by a single fix. The attacker probed many potential routes, in parallel, with Railway similarly hardening the routes in parallel.”
— Railway
Railway describe la respuesta como una competición por la velocidad de los agentes y, citando a Wiz, afirma que el atacante empleó modelos de IA modificados para eliminar sus restricciones y un entorno de ejecución similar a ARTEX. No publicó indicadores de compromiso: dijo que los comparte de forma privada y que prevé hacerlos públicos cuando las autoridades lo permitan.
La empresa encuadra el incidente en una serie de ataques contra plataformas de desarrollo que almacenan claves de IA. En su análisis de “Black October”, Wiz enumeró incidentes divulgados durante octubre por al menos nueve plataformas de desarrollo de IA. BleepingComputer también citó ataques contra Northflank, OpenCode, Warp y Lightning AI. Railway relacionó el suyo con casos comunicados entre el 6 y el 23 de octubre, pero señaló que no hay una vulnerabilidad o dependencia de software común que conecte los ataques.
Quién tramita los reembolsos
El coste final para cada cliente depende del proveedor que procesó el consumo. AWS Bedrock y Google Gemini aplican políticas de reembolso por fraude y sus equipos ya habían empezado a tramitar devoluciones, según Railway. OpenAI y SpaceXSI revisan las reclamaciones caso por caso. Para OpenAI, el cliente debe presentar una reclamación y enviar después su número de caso al equipo de soporte de Railway; las solicitudes relativas a SpaceXSI se presentan a ese mismo equipo.
Las conversaciones con Anthropic seguían abiertas cuando Railway publicó el informe, por lo que la plataforma dijo que cubriría entretanto los cargos de claves de Anthropic afectadas. OpenRouter mantiene en sus condiciones una política de no reembolso; Railway se comprometió a asumir todos los costes de OpenRouter relacionados con la intrusión. La compañía pide que los usuarios denuncien los cargos que no reconocen mediante su formulario de reclamación y afirma que puede escalar las solicitudes ante los proveedores.
El compromiso de cubrir los importes que los proveedores rechacen contrasta con el mensaje inicial que Railway envió el 26 de octubre: entonces indicó que no podía devolver directamente el gasto realizado con claves comprometidas y pidió a los clientes que contactaran primero con los proveedores. La empresa no ha publicado un límite para su cobertura ni una fecha límite para presentar reclamaciones. Tampoco ha especificado si los clientes deben pagar los cargos discutidos mientras se revisa cada caso.
El cálculo de 740.000 dólares se presenta como una estimación de uso no autorizado. Railway no ha explicado en el informe qué método utilizó para calcularla ni qué periodo abarca. La cifra se refiere al consumo cargado a las claves robadas, no a un importe confirmado como reembolsado.
Compilaciones pausadas y sistemas reforzados
La intrusión no apagó las aplicaciones que ya estaban en funcionamiento, pero Railway detuvo nuevas compilaciones en dos ocasiones: a las 17:03 UTC del 20 de octubre y a las 07:22 UTC del día siguiente. La interrupción afectó a las compilaciones y despliegues nuevos; durante la respuesta también hubo periodos de indisponibilidad del panel, la API, la interfaz de línea de comandos y las herramientas de soporte.
Railway desactivó credenciales internas y sesiones, y restableció las compilaciones para todos los planes el 22 de octubre a las 22:49 UTC, tras reforzar la infraestructura. La compañía dijo que expulsó por completo al atacante el 21 de octubre a las 09:24 UTC; el informe indica que, desde las 09:25, ya no tenía acceso a datos de clientes. Esas marcas describen momentos distintos de la respuesta: la expulsión y la validación posterior de que no quedaba acceso.
La plataforma cambió también su sistema de compilación. Antes, varias compilaciones podían ejecutarse aisladas entre sí en una misma máquina virtual. El nuevo diseño asigna a cada compilación una máquina virtual de corta duración, además del aislamiento existente, y limita la credencial de cada trabajo a subir una imagen específica. Railway afirma que su propio equipo de endurecimiento logró construir un segundo exploit modificando el ataque original menos de una hora después de aplicar el parche. Esa prueba aceleró la migración de todos los usuarios al nuevo sistema.
Railway asegura que cerró todas las debilidades utilizadas, rotó credenciales y reconstruyó herramientas internas a partir de código validado. También presentó una denuncia ante el IC3 del FBI y trabaja con una firma especializada en análisis forense; la investigación continúa. La compañía prevé publicar los indicadores de compromiso cuando las fuerzas del orden lo autoricen.
Para los clientes, Railway recomienda revocar y sustituir las variables sensibles guardadas antes del 21 de octubre. El trámite de cargos no invalida una clave: debe revocarse o rotarse directamente con el proveedor que la emitió. La compañía también aconseja retirar el acceso público a las bases de datos y revisar los registros de auditoría de GitHub y de registros de contenedores, como Docker Hub.
Fuentes: The Hacker News, BleepingComputer, Railway Blog, Railway Blog, TechCrunch, iTnews
