En bref. Le 10 novembre 2026, Railway, une plateforme d'hébergement d'applications (PaaS, Platform as a Service), a publié le rapport détaillé de l'attaque subie les 20 et 21 octobre. L'attaquant a enchaîné une évasion partielle de l'isolation des builds, un identifiant interne trop largement accepté, puis une liaison OIDC mal définie dans le cloud, jusqu'à déchiffrer une partie des variables d'environnement des clients. Sa cible principale, selon Railway, était les clés d'API des fournisseurs d'IA ; la consommation frauduleuse est estimée à environ 740 000 $. Pour vous, la leçon tient en deux points : une clé d'IA confiée à une plateforme doit être bornée et surveillée, et une chaîne de build se protège identifiant par identifiant.
Ce qui s'est passé
Le rapport de Railway, signé par quatre membres de l'équipe et mis à jour le 10 novembre 2026, retrace l'attaque. Les heures sont en temps universel (UTC).
Premier point d'entrée : les builds. Le 20 octobre à 6 h 50, l'attaquant commence à sonder l'infrastructure de build. À l'époque, plusieurs builds de clients différents pouvaient s'exécuter sur la même machine virtuelle, isolés les uns des autres. À 7 h 28, il exploite une vulnérabilité inconnue jusque-là pour échapper partiellement à l'isolation du système de fichiers. Il lit des fichiers de la machine hôte et récupère un identifiant que les serveurs de build utilisent pour s'authentifier auprès de certains systèmes internes, notamment pour pousser les images une fois le build terminé.
L'alerte. À 13 h 58, une alerte sur des appels d'API anormaux vers le registre d'artefacts déclenche l'appel de l'ingénieur d'astreinte. Il remonte jusqu'à l'identifiant compromis, puis jusqu'au build d'où l'attaquant s'est échappé.
Ce que l'identifiant ouvrait. Railway orchestre ses builds avec Temporal, un moteur de tâches asynchrones, auto-hébergé. Les tâches contenaient un jeton GitHub en lecture seule limité à un dépôt, les variables et secrets transmis au build, et des métadonnées. L'identifiant volé ne devait servir qu'à finir les builds, mais l'instance Temporal l'acceptait comme un client de confiance. L'attaquant a ainsi lu l'historique de 353 builds entre 13 h 50 et 15 h 30, variables scellées comprises. Comme l'identifiant donnait aussi accès aux instantanés de dépôts utilisés pour le cache, il a récupéré une copie du monodépôt interne de Railway. Railway révoque l'identifiant à 17 h 28.
Second point d'entrée : le CI/CD. Avec le code source en main, l'attaquant cherche d'autres chemins. Il trouve une liaison OIDC (OpenID Connect, le protocole qui permet à un pipeline d'obtenir des identifiants cloud temporaires sans secret stocké) « définie par erreur » dans l'un des environnements cloud. Le 21 octobre à 3 h 26, il obtient par ce biais un identifiant cloud de courte durée. Il s'en sert pour récupérer deux secrets internes : un identifiant de longue durée et une clé privée SSH. Il se connecte en SSH à une machine d'orchestration qui conservait sur disque un identifiant permettant de déchiffrer les variables des clients.
Le déchiffrement. Les variables sont protégées par chiffrement d'enveloppe : chaque environnement a sa propre clé de chiffrement des données, elle-même chiffrée par une clé racine conservée dans le service de gestion de clés (KMS, Key Management Service) d'un fournisseur cloud. Entre 4 h 07 et 5 h 21, l'attaquant extrait des enveloppes chiffrées de la base de données. Les journaux montrent des requêtes filtrant les noms de variables par expressions régulières pour viser les clés de fournisseurs d'IA, et une préférence pour les clients ayant beaucoup de variables. Il déchiffre une partie de ces enveloppes entre 4 h 42 et 7 h 14. À 7 h 14, Railway désactive tous les identifiants cloud actifs et révoque les identifiants statiques. Selon le rapport, l'attaquant n'a plus eu accès à des données clients après 9 h 25.
L'impact chiffré par Railway
- Au plus 1,85 % des espaces de travail, soit environ 100 000, ont pu voir des variables déchiffrées. Railway précise que c'est une borne haute : ses journaux identifient des environnements, pas des variables individuelles.
- 1 852 utilisateurs avaient des jetons de comptes liés déchiffrés (clés d'agents en BYOK, Bring Your Own Key, et jetons OAuth GitHub). Tous ont été réinitialisés.
- Environ 740 000 $ de consommation non autorisée estimée sur les clés volées. Railway indique négocier les remboursements avec les fournisseurs et couvrir lui-même les pertes quand un fournisseur refuse.
- Dès 9 h 25 le 21 octobre, Railway a demandé à GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google et Stripe de révoquer les clés potentiellement compromises, en leur fournissant les empreintes (hachages) de toutes les clés détenues.
Railway estime que les clés ont été transmises à des services de relais pour servir à la distillation de modèles, sans avoir établi si l'attaquant exploitait lui-même ces services. Le rapport cite des vols similaires déclarés entre le 6 et le 23 octobre par OpenCode, Warp, Fireworks AI et d'autres, et renvoie à l'enquête « Black October » de Wiz sur la revente d'identifiants d'IA volés, en précisant qu'elle n'attribue pas l'incident Railway.
Qui est concerné
- Les clients Railway : le rapport invite chacun à signaler les frais qu'il n'a pas engagés via le formulaire prévu, et précise la politique de remboursement de chaque fournisseur à la date de publication.
- Toute organisation qui stocke des clés d'IA dans une plateforme tierce (PaaS, outil de CI, plateforme d'agents). Le schéma décrit ici, où une faille d'isolation mène aux secrets de nombreux clients, peut se reproduire ailleurs.
- Les équipes qui exploitent leur propre chaîne de build multi-locataire, y compris en interne : chaque maillon franchi par l'attaquant correspond à un contrôle courant.
Ce que vous pouvez faire côté client
Les mesures suivantes sont des bonnes pratiques de gestion des secrets, déduites du scénario décrit par Railway.
1. Une clé par usage, avec un plafond. Créez une clé distincte par application et par environnement, avec une limite de dépense proche de la consommation réelle. Une clé volée ne doit pas pouvoir générer en quelques jours l'équivalent de plusieurs mois de budget.
2. Une alerte sur la consommation. Un pic de dépense ou un volume de requêtes hors de vos heures d'activité peut être le premier signal visible. Vérifiez que l'alerte arrive à une personne d'astreinte, pas dans une boîte partagée.
3. Un inventaire des endroits où chaque clé est copiée. Savoir en quelques minutes quelles clés vivent chez quel prestataire raccourcit la rotation.
4. Une procédure de rotation testée. Plusieurs clients n'ont pas pu redéployer leurs services avec une nouvelle clé tant que les builds étaient suspendus. Prévoyez une rotation qui ne dépend pas uniquement de la plateforme compromise.
Ce que l'incident enseigne aux équipes qui opèrent une chaîne de build
Railway liste les corrections apportées. Elles dessinent une méthode applicable à toute plateforme qui exécute du code de tiers.
Isoler chaque build sur sa propre machine. Chaque build dispose désormais d'une machine virtuelle éphémère dédiée, en plus de l'isolation d'origine. L'attaquant doit franchir deux couches au lieu d'une.
Donner à chaque identifiant le strict nécessaire. Le nouvel identifiant de build ne peut que pousser une image OCI précise vers le registre de Railway. Dans l'incident, l'identifiant de build était accepté par Temporal comme un client de confiance : c'est ce décalage entre l'usage prévu et l'usage accepté qui a ouvert l'historique des autres builds. Méthode de vérification : pour chaque identifiant de service, listez les systèmes qui l'acceptent, pas seulement ceux qui l'utilisent.
Contrôler les liaisons OIDC. Une seule liaison mal définie a suffi à obtenir un identifiant cloud. Une bonne pratique consiste à vérifier, pour chaque relation de confiance entre votre CI et votre cloud, que les conditions limitent l'accès au dépôt et à la branche prévus, et à relire ces configurations à chaque modification.
Ne pas laisser de clé de déchiffrement sur disque. La machine d'orchestration conservait un identifiant de longue durée capable de déchiffrer les variables. Railway indique que désormais seul le service de secrets accède aux clés qui déchiffrent les clés de données, que chaque service appelant ne peut déchiffrer que les secrets dont il a besoin, et que toutes les opérations de chiffrement et de déchiffrement sont journalisées de façon centralisée.
Durcir le CI lui-même. Les systèmes de CI ont été reconstruits avec un contrôle d'accès fin, une validation par second facteur et biométrie pour les zones sensibles, un réseau isolé et une journalisation envoyée au SIEM (le système central de collecte et d'analyse des journaux de sécurité).
Décider à l'avance du moment de la notification. Railway explique avoir prévenu les fournisseurs d'IA avant ses utilisateurs, pour faire révoquer les clés au plus vite, puis avoir retardé la communication large le temps de qualifier l'impact. L'entreprise annonce qu'elle fixera désormais une durée maximale d'analyse, au-delà de laquelle une notification large partira quoi qu'il arrive. Inscrire ce délai dans votre propre procédure évite d'en débattre en pleine crise.
Une attaque à la vitesse des agents
Le rapport décrit un attaquant qui a sondé de nombreuses routes en parallèle, et une défense qui fermait ces routes en parallèle. Railway parle d'une « course de vitesse entre agents » et indique que l'attaquant utilisait des modèles dont les garde-fous avaient été retirés. Une heure après le correctif de la première évasion, une équipe interne chargée de durcir l'ancien système de build a trouvé une variante de l'exploit, ce qui a conduit Railway à basculer tous les clients vers la nouvelle infrastructure de build plus tôt que prévu.
Les contrôles qui ne dépendent pas d'une réaction humaine (périmètre des identifiants, durée de vie courte, journalisation des déchiffrements) prennent d'autant plus de poids.
FAQ
Mes clés étaient stockées sur Railway : que faire ?
Révoquez et remplacez les clés d'IA, de cloud, de base de données et de paiement stockées dans vos variables, vérifiez la consommation sur vos comptes fournisseurs depuis le 18 octobre 2026, et signalez à Railway toute dépense que vous n'avez pas engagée.
Le chiffrement des variables n'a-t-il pas protégé les clés ?
Selon Railway, le stockage est conçu pour qu'une clé compromise n'expose pas toute la plateforme, et au plus 1,85 % des espaces de travail ont pu voir des variables déchiffrées. Il n'a pas suffi parce que l'attaquant a obtenu un identifiant autorisé à utiliser le service de gestion de clés.
Qu'est-ce que le vol de clés d'IA rapporte à un attaquant ?
Railway estime que les clés ont été transmises à des services de relais pour la distillation de modèles. Les usages observés par ses clients vont d'agents de codage à des pipelines d'entraînement.
Un plafond de dépense suffit-il ?
Non, il limite la perte financière mais pas l'accès. Il se combine avec une clé par usage, une alerte sur la consommation et une rotation rapide.
Sources
- Railway, Incident Report: October 21st Security Attack, mis à jour le 10 novembre 2026 : https://blog.railway.com/p/incident-report-october-security-incident
- The Hacker News, Railway Says Stolen Customer AI Keys Led to $740,000 in Estimated Unauthorized Usage Charges, 11 novembre 2026 : https://thehackernews.com/2026/11/railway-says-stolen-customer-ai-keys.html
Pour revoir la gestion des secrets et la configuration OIDC de votre chaîne CI/CD, WeeSec accompagne les équipes sur le DevSecOps.