Le 20 octobre, une alerte a réveillé un ingénieur de Railway à cause d'appels API vers un registre interne qui n'auraient pas dû exister. Seize heures plus tard, l'entreprise avait arrêté deux fois les builds de ses clients, fait tourner tous ses identifiants et demandé à neuf fournisseurs d'IA de révoquer des clés dont elle ne pouvait pas encore prouver le vol.
Le bilan du rapport d'incident publié le 10 novembre : des variables clients déchiffrées dans 1,85 % des workspaces au maximum, environ 100 000. Des jetons de comptes liés réinitialisés pour 1 852 utilisateurs. Des dépenses non autorisées sur les clés volées estimées à environ 740 000 dollars, que Railway rembourse ou couvre sur son propre bilan.
Et le point sur lequel il faut s'arrêter : personne n'a phishé un directeur financier. Personne n'a déployé de rançongiciel. L'attaquant visait des clés API de fournisseurs d'IA, et le marché qui a rendu cela digne d'un week-end de travail, c'est nous tous qui l'avons construit.
L'intrusion, dans l'ordre où elle s'est produite
La chronologie complète figure dans le rapport de Railway et se lit comme une histoire d'horreur racontée en horodatages UTC.
- 18 octobre, avant tout le reste : l'attaquant commence à créer des comptes factices sur la plateforme. Les défenses automatiques bloquent chaque tentative à ce stade.
- 07:28 UTC, 20 octobre : il exploite une faille inconnue dans l'infrastructure de build multi-locataires pour s'échapper partiellement de l'isolation du système de fichiers et lire des fichiers sur la VM hôte. Il en tire un identifiant que les serveurs de build utilisent pour pousser des images dans un registre.
- 13:58 UTC : des appels API anormaux au registre alertent l'ingénieur d'astreinte. La cause racine est trouvée en moins d'une heure. Correctif fusionné, builds arrêtés, attaquant isolé.
- Le pivot : cet identifiant ne devait autoriser que les push vers le registre. Mais le cluster Temporal interne qui orchestre les builds l'acceptait comme client de confiance, donc l'attaquant pouvait appeler ses API et lire les historiques de build, dont les variables injectées dans les builds des autres. L'un de ces snapshots était le monorepo interne. La plateforme de support de Railway se déploie depuis lui, sur Railway même.
- 03:26 UTC, 21 octobre : en scannant ce code, l'attaquant trouve un binding OIDC mal configuré dans un environnement cloud et y vole des identifiants de production à durée courte.
- 04:07 à 05:21 UTC : avec un identifiant plus durable posé sur une machine d'orchestration, il se connecte à la base de production qui stocke les variables d'environnement chiffrées et en extrait les enveloppes. Les logs montrent qu'il sélectionnait les lignes dont le nom de variable correspondait à des expressions régulières fournies par l'attaquant pour les clés de fournisseurs d'IA, en priorisant les clients à nombreuses variables.
- 04:42 à 07:15 UTC : il utilise l'identifiant de déchiffrement trouvé sur la même machine pour ouvrir les enveloppes via le service de gestion des clés.
- 07:14 UTC : Railway désactive tous les identifiants cloud actifs, révoque les statiques, tue le service de déchiffrement et coupe des pans entiers de la plateforme. Les builds repassent au noir.
- 09:24 UTC : l'attaquant est totalement expulsé.
Trois choix de conception qui ont transformé un bug en braquage
Retirez le drame et le schéma d'échec est familier, et c'est précisément pour cela qu'il compte.
1. Un identifiant étroit auquel trop de services faisaient confiance. Rien dans sa conception ne disait « lis les variables de build des autres locataires ». L'architecture l'acceptait simplement comme client ailleurs. Le rayon d'action ne se définit pas par ce qu'une clé est censée faire, mais par chaque service qui l'accepte.
2. Des snapshots en cache que personne ne comptait comme secrets. Le cache de build contenait des copies de l'état du dépôt. Cela offrait à l'attaquant une carte privilégiée de l'entreprise et, pire, un catalogue de toutes les routes à tester ensuite.
3. Des secrets durables à côté des données qu'ils déchiffrent. L'envelope encryption est une bonne conception. Une envelope encryption où la machine qui lit le chiffré stocke aussi la clé qui l'ouvre, c'est une porte fermée à clé avec la clé dans la serrure. Ajoutez un binding OIDC mal configuré et toute la chaîne s'effondre.
L'attaquant n'a plus eu besoin de zero-day après les dix premières minutes. Tout le reste était de la configuration.
Pourquoi vos clés IA, précisément
La forensique de Railway conclut que les clés de fournisseurs d'IA étaient la cible principale. Les clés volées ont été transmises à ce que le rapport appelle des stations de transfert distribuées, le terme poli pour des opérations de revente qui monétisent les crédits d'inférence des autres. L'usage le plus probable, selon le rapport : la distillation, générer des données d'entraînement et des scores à partir d'un modèle de pointe aux frais de quelqu'un d'autre.
Le rapport corrige aussi l'idée d'un cas isolé. OpenCode, Warp, Fireworks AI et plusieurs autres ont révélé des vols similaires entre le 6 et le 23 octobre. Wiz a documenté le motif sous le nom de « Black October for AI developer platforms ». Les propres clients de Railway ont vu les clés volées servir à des requêtes d'agents de code, à des revues de comportement d'agents pour produire des données d'entraînement, et à des contrôles de pipelines d'entraînement et de leurs systèmes de scoring.
Autrement dit : une filière illégale complète existe désormais pour l'inférence. Les clés sont la monnaie, la dépense est la perte, et les victimes sont souvent les clients dont les variables vivaient dans la base de données de quelqu'un d'autre.
L'attaquant était un essaim d'agents, la défense aussi
Deux détails devraient changer votre vision des délais de réponse à incident.
Premièrement, la course qui s'est jouée le premier jour a été décrite comme une course de vitesse entre agents, Wiz notant l'usage de modèles abliterated et d'un harness d'agents proche d'ARTEX. Trente-six heures, des dizaines de routes de sondage en parallèle, des centaines de comptes de test.
Deuxièmement, la contre-mesure de Railway était tout aussi mécanique : observation 24/7 de l'attaquant via les logs d'audit et les traces, durcissement parallèle des routes sondées et forensique interne distribuée en continu.
Votre runbook de réponse à incident suppose probablement des humains en passerelle à lire Slack. Ce n'est plus le rythme d'en face.
Ce que nous ferions cette semaine
Pour quiconque dans le Golfe fait tourner des fonctions IA, des agents ou des pipelines fintech sur la plateforme d'un autre, cinq gestes :
- Inventoriez chaque clé IA et nommez un propriétaire. OpenAI, Anthropic, OpenRouter, Gemini, Fireworks, les clés BYOK de vos agents. Une clé sans propriétaire ni date de rotation doit être traitée comme exposée.
- Plafonnez et alertez sur la dépense, pas seulement sur les échecs. 740 000 dollars d'inférence non autorisée, c'est une occasion de détection. Budgets par clé, alertes de pic, et une revue hebdomadaire des clés qui ne font que dépenser sans jamais déployer.
- Tuez les identifiants de longue durée. Échanges OIDC courts, une audience par service, et un audit permanent de chaque binding jamais configuré. La chaîne Railway a commencé par un binding simplement faux.
- Partez du principe que la base de données de la plateforme est lisible par quelqu'un. Lesquelles de vos variables contiennent quelque chose qui vaut d'être volé ? Faites tourner les clés IA, les jetons de paiement et les autorisations OAuth GitHub stockés dans n'importe quelle plateforme, et préférez les clés révocables en un clic chez le fournisseur.
- Mettez la divulgation et la révocation dans le contrat. Railway a demandé aux fournisseurs de révoquer des clés par hash avant même de savoir ce qui avait fuité. Demandez dès aujourd'hui à vos fournisseurs : pouvez-vous produire une liste de hash et une voie de révocation en quatre heures après un incident ?
La phrase à retenir
Il faut créditer Railway d'un rapport inconfortable et inhabituellement détaillé. Une note préliminaire a été publiée pendant que la reprise tournait encore, puis le récit forensique complet trois semaines plus tard, y compris le fait que les clés de ses propres clients ont coûté plus que le budget annuel d'une petite entreprise.
Mais la leçon n'est pas qu'une plateforme a perdu. C'est que la chose la plus précieuse de votre compte cloud n'est plus la donnée, c'est le calcul. Vos clés IA sont de l'argent désormais, et elles traînent dans une douzaine de panneaux de variables d'environnement sur une douzaine de tableaux de bord, chacune chiffrée avec une clé que le serveur de build de quelqu'un d'autre peut lire.
Traitez-les comme les comptes bancaires qu'elles sont devenues en silence. Rotation, périmètre, plafond, surveillance. Ce trimestre, pas le suivant.