Railway : une faille de build permet à un attaquant de déchiffrer des secrets de clients et de dépenser environ 740 000 $ avec des clés d'IA volées

Comment c'est arrivé

Railway indique que l'attaquant a exploité une vulnérabilité jusque-là inconnue de son infrastructure de build multi-locataire pour sortir en partie de l'isolation du système de fichiers. Il a ainsi obtenu un identifiant que les serveurs de build utilisent pour joindre certains systèmes internes, et que son instance interne Temporal a accepté comme client de confiance. L'attaquant a ensuite profité d'une liaison OIDC mal définie dans l'un de ses environnements cloud pour obtenir un identifiant cloud de courte durée, puis d'un identifiant de longue durée et d'une clé SSH pour déchiffrer des variables via le service de gestion des clés.[1] Vérifié le 11 nov. 2026

Ce qui a été volé

Une copie du monorepo interne de Railway, l'historique de 353 builds avec leurs variables scellées, les variables d'environnement déchiffrées d'au plus environ 100 000 espaces de travail, et les jetons de comptes liés (jetons OAuth GitHub et clés d'agents d'IA fournies par les clients) de 1 852 utilisateurs. Railway indique que les clés de fournisseurs d'IA étaient la cible principale ; d'autres requêtes visaient aussi des identifiants de cloud, de bases de données et de services de paiement. Elle dit que l'analyse forensique ne montre pas d'accès aux bases de données des clients et qu'elle n'a aucun signe de téléchargement de dépôts de clients.[1][3] Vérifié le 11 nov. 2026

Qui est touché

Les clients de Railway : au plus 1,85 % des espaces de travail, environ 100 000, ont pu voir des variables d'environnement déchiffrées ; Railway parle d'un maximum. 1 852 utilisateurs ont eu des jetons de comptes liés exposés, tous réinitialisés. Railway dit n'avoir trouvé aucune connexion à des comptes Railway avec des identifiants pris pendant l'incident.[1][3] Vérifié le 11 nov. 2026

Acteur

Non attribué

Chronologie

1. 18 oct. 2026Railway indique que l'attaquant commence à créer des comptes factices ; les premières tentatives échouent. [1]
2. 20 oct. 2026À 06:50 UTC, l'attaquant commence à sonder l'infrastructure de build, puis à 07:28 UTC exploite une vulnérabilité inconnue pour sortir en partie de l'isolation du système de fichiers. L'équipe d'astreinte de Railway est alertée à 13:58 UTC. Les builds sont arrêtés à 17:03 UTC et l'identifiant de build est remplacé à 17:28 UTC. [1]
3. 21 oct. 2026À 03:26 UTC, l'attaquant obtient un identifiant cloud de courte durée grâce à une liaison OIDC mal définie, puis déchiffre des variables via le service de gestion des clés entre 04:42 et 07:15 UTC. Railway désactive les identifiants cloud et le service de déchiffrement à 07:14 UTC et dit que l'attaquant est entièrement expulsé à 09:24 UTC. Les fournisseurs d'IA reçoivent à 09:25 UTC la liste des clés potentiellement exposées, et toutes les sessions et jetons des utilisateurs sont invalidés à 20:19 UTC. [1]
4. 22 oct. 2026Railway publie un rapport préliminaire : au plus 1,85 % des espaces de travail, environ 100 000, ont peut-être eu des variables d'environnement compromises. Elle demande aux clients de renouveler leurs variables sensibles et de retirer l'accès réseau public à leurs bases de données, et indique que l'attaquant disposait de modèles « abliterated », sans garde-fous. Les builds sont rétablis dans la journée, en commençant par les clients Enterprise. [2]
5. 10 nov. 2026Railway publie son rapport d'incident complet. Elle estime à environ 740 000 $ les dépenses non autorisées faites avec les clés volées, dit travailler avec les fournisseurs pour les rembourser et prendre en charge ce qu'ils refuseront, et indique que chaque build tourne désormais dans sa propre machine virtuelle éphémère. Elle cite les travaux de Wiz sur « Black October », une vague d'attaques contre les plateformes qui détiennent des clés d'IA, sans attribuer elle-même l'incident au même opérateur. [1][3]