Un incident de sécurité majeur touche Railway, la plateforme cloud utilisée par des développeurs pour déployer leurs applications. Le 21 octobre 2026, l’entreprise a détecté une activité anormale sur les systèmes chargés de stocker les variables d’environnement de ses clients. Railway reconnaît qu’un tiers non autorisé pourrait avoir accédé à des variables chiffrées et, pour certaines d’entre elles, obtenu leur contenu en clair.
Le problème dépasse largement la fuite de simples paramètres techniques. Les variables d’environnement servent précisément à conserver les secrets d’une application : clés API OpenAI ou Anthropic, mots de passe de bases de données, identifiants AWS ou Google Cloud, clés Stripe, accès aux registres privés ou tokens GitHub. Railway recommande donc à tous ses utilisateurs de les considérer comme potentiellement compromis et de les remplacer immédiatement.
An urgent notice from the Railway team
https://t.co/niUAhTAQJM
— Railway (@Railway) October 21, 2026
Des secrets chiffrés ont pu être récupérés en clair
Railway explique que l’activité suspecte concernait directement les systèmes stockant les variables d’environnement de ses clients. L’enquête indique qu’un attaquant a pu consulter des données chiffrées et déchiffrer au moins une partie des valeurs.
Ce point est particulièrement important. Le chiffrement au repos protège normalement un secret en cas de simple copie du stockage, mais une plateforme cloud doit forcément être capable de déchiffrer ces valeurs lorsqu’elle démarre une application ou construit un conteneur. Une compromission suffisamment profonde du système chargé de cette opération peut donc contourner cette protection sans qu’il soit nécessaire de casser cryptographiquement le chiffrement.
Railway ne précise pas encore le mécanisme utilisé par l’attaquant, ni si les clés maîtresses de chiffrement ont été compromises. Le scénario technique exact reste donc inconnu.
Railway demande de changer absolument toutes les variables sensibles
Alors que l’entreprise estime que seul un sous-ensemble de clients pourrait avoir réellement été touché, elle recommande néanmoins à tous les utilisateurs de révoquer et recréer les secrets enregistrés sur la plateforme.
La consigne concerne aussi bien les clés d’API que les mots de passe de bases de données et les identifiants permettant de télécharger des images depuis des registres privés.
Railway indique qu’elle contactera directement par email les comptes dont l’exposition pourra être confirmée au fur et à mesure de l’enquête.
OpenAI, Anthropic, Grok et OpenRouter parmi les accès à surveiller
Le lendemain de l’annonce, Railway a publié une série exceptionnelle de guides consacrés spécifiquement aux conséquences possibles de l’incident. Plusieurs concernent les fournisseurs d’intelligence artificielle : OpenAI, Anthropic, xAI avec Grok et OpenRouter.
Pour chacun d’eux, Railway recommande de révoquer la clé API, analyser l’utilisation et les factures puis rechercher des requêtes qui ne correspondent pas à l’activité habituelle du client.
Une clé API volée peut permettre à un attaquant de générer des quantités massives de requêtes à un modèle d’intelligence artificielle. Les coûts sont alors facturés au véritable propriétaire de la clé, tandis que son quota peut être épuisé ou son compte suspendu en cas d’activité considérée comme abusive.
Railway soupçonne une campagne visant les fournisseurs d’IA
L’entreprise avance elle-même une hypothèse particulièrement intéressante : l’attaque ferait partie d’une série d’opérations visant des plateformes techniques afin de compromettre, par ricochet, des fournisseurs d’inférence IA.
Railway indique avoir prévenu les fournisseurs concernés afin que les clés potentiellement exposées puissent être révoquées de manière proactive.
Cette déclaration intervient quelques jours après l’attaque contre OpenCode. Le 17 octobre, le projet avait confirmé l’exposition de clés API de certains utilisateurs dans ce qu’il qualifiait d’attaque de distillation à grande échelle. L’incident concernait notamment des clés OpenAI, Anthropic et Google.
Plusieurs victimes d’OpenCode avaient alors signalé des centaines voire plus de 1 000 dollars de consommation non autorisée, tandis que certains projets Google Cloud auraient été suspendus après détection d’une activité abusive. Aucun élément public ne permet cependant d’affirmer que les deux incidents ont été réalisés par les mêmes attaquants.
Les bases PostgreSQL, MySQL, MongoDB et Redis peuvent aussi être concernées
Limiter l’incident aux clés d’intelligence artificielle serait une erreur. Railway a également publié des procédures spécifiques pour PostgreSQL, MySQL, MongoDB et Redis.
Sur Railway, les chaînes de connexion et mots de passe de ces bases sont généralement stockés sous forme de variables comme DATABASE_URL, MYSQL_URL, MONGO_URL ou REDIS_URL. Si une telle valeur a été récupérée en clair, elle peut donner directement accès à la base lorsque celle-ci est exposée publiquement sur Internet.
Les conséquences dépendent alors des permissions du compte : lecture ou modification de données clients, suppression de tables, récupération de sessions, création de comptes supplémentaires ou extraction complète d’une base.
Railway recommande de régénérer les mots de passe et de vérifier les connexions, rôles, extensions ou modifications inhabituelles. Pour Redis, l’entreprise souligne également qu’un attaquant ayant eu accès au stockage de sessions pourrait avoir récupéré des tokens d’authentification toujours valides.
Des clés AWS et Google Cloud pourraient ouvrir bien plus qu’une application Railway
Une autre conséquence potentiellement beaucoup plus large concerne les identifiants de fournisseurs cloud externes. Railway consacre des procédures distinctes aux clés AWS et aux identifiants Google Cloud susceptibles d’avoir été enregistrés dans ses variables.
Une clé AWS suffisamment privilégiée peut permettre de lire des buckets S3, démarrer des machines virtuelles, accéder à des bases, créer de nouveaux utilisateurs IAM ou engager des dépenses importantes. Les attaquants cherchent fréquemment à maintenir leur accès en créant une nouvelle clé ou un nouveau rôle avant que le secret initial ne soit désactivé.
Railway recommande donc de rechercher les appels inhabituels dans CloudTrail, les ressources créées dans des régions normalement inutilisées et toute hausse inexpliquée de la facture cloud.
Stripe : des clés de paiement potentiellement concernées
Railway invite également les clients ayant stocké des clés secrètes Stripe à les renouveler immédiatement.
Selon le niveau de permission associé à une clé, un attaquant peut potentiellement interagir avec des clients, remboursements, paiements, transferts ou comptes connectés. Railway conseille donc de contrôler non seulement les requêtes API mais aussi les remboursements, versements et opérations financières inhabituelles.
Railway a révoqué elle-même les accès à ses buckets
Pour certains secrets, l’entreprise n’a pas attendu ses clients. Dans la nuit, Railway a invalidé puis régénéré les identifiants S3 de tous les buckets de stockage hébergés sur sa plateforme.
Les anciennes clés ne fonctionnent donc plus. Les applications qui utilisaient ces identifiants doivent être redéployées afin de récupérer les nouvelles valeurs.
Railway conseille néanmoins aux administrateurs d’inspecter leurs buckets à la recherche de fichiers inconnus ou de suppressions qu’ils n’auraient pas effectuées. La documentation publiée après l’incident précise notamment que ces buckets ne disposent pas automatiquement d’une sauvegarde, ce qui rend une éventuelle suppression particulièrement problématique.
Les tokens GitHub ont également été invalidés
Les connexions GitHub stockées directement par Railway ont elles aussi été réinitialisées. Les utilisateurs doivent désormais reconnecter leurs comptes GitHub pour retrouver le déploiement automatique de leurs dépôts.
La situation est légèrement différente pour les tokens personnels enregistrés afin d’accéder à des images privées sur GitHub Container Registry. Railway les a supprimés de sa plateforme mais précise que ces tokens peuvent toujours fonctionner côté GitHub tant que leur propriétaire ne les révoque pas lui-même.
Un token GitHub exposé peut, selon ses permissions, permettre d’accéder à du code privé, des packages, des dépôts ou différentes ressources d’une organisation.
Une fuite de secrets qui peut provoquer une compromission en cascade
C’est probablement la principale conséquence de l’incident Railway. Une plateforme de déploiement constitue un endroit particulièrement stratégique car une seule application peut y stocker les clés permettant d’accéder à tous les autres services dont elle dépend.
Une variable compromise sur Railway peut ainsi donner accès à une base PostgreSQL. Cette base peut contenir des utilisateurs et sessions. Une autre variable peut ouvrir un bucket AWS, une troisième un dépôt GitHub et une quatrième un compte Stripe.
L’incident initial peut donc se transformer en chaîne de compromissions chez des prestataires qui n’ont eux-mêmes subi aucune faille. C’est précisément pour cette raison que Railway demande de renouveler tous les secrets plutôt que les seules clés dont l’utilisation abusive a déjà été constatée.
L’incident a aussi paralysé les déploiements pendant des heures
La réponse de Railway a provoqué un second impact majeur : les builds et déploiements ont été suspendus dans toutes les régions pendant l’enquête.
Le tableau de bord, l’API, la ligne de commande et même la plateforme de support ont été indisponibles ou partiellement perturbés pendant plusieurs heures. Railway a également invalidé certaines sessions OAuth, forçant des utilisateurs à se reconnecter.
Cette coupure crée une situation particulièrement délicate : les clients doivent changer leurs secrets au plus vite, mais une nouvelle clé enregistrée dans Railway n’est utilisée par l’application qu’après un nouveau déploiement. Pendant une partie de l’incident, ces redéploiements étaient justement impossibles.
Dans la nuit du 21 au 22 octobre, Railway a commencé à rétablir les builds progressivement, d’abord pour les comptes Enterprise, avant les offres Pro, Hobby, Free et Trial.
On ne sait toujours pas combien de clients sont réellement touchés
Plusieurs informations essentielles restent inconnues. Railway n’a communiqué ni le nombre de comptes concernés, ni le nombre de secrets récupérés, ni la durée pendant laquelle l’attaquant a disposé de cet accès.
L’entreprise affirme seulement que son analyse initiale laisse penser que l’incident pourrait être limité à un sous-ensemble d’utilisateurs. Elle n’a pas non plus rendu public le point d’entrée initial ou détaillé la manière dont certaines variables chiffrées ont pu être obtenues en clair.
Il n’existe donc actuellement aucune preuve que toutes les variables hébergées sur Railway aient été récupérées. La recommandation de tout renouveler constitue une mesure de précaution maximale pendant que l’enquête détermine le véritable périmètre.
La facture pourrait apparaître bien après la fermeture de la faille
Le danger ne disparaît pas simplement lorsque Railway corrige son propre système. Un secret copié reste valable chez le service tiers jusqu’à sa révocation.
Une clé AWS, OpenAI, Stripe ou GitHub volée pendant quelques secondes peut donc continuer à être utilisée plusieurs jours ou semaines plus tard si son propriétaire ne la remplace pas.
Pour les clients de Railway, l’incident doit donc être traité comme une potentielle compromission de l’ensemble des secrets enregistrés dans leurs projets : rotation des clés, analyse des factures, consultation des journaux d’accès et recherche d’éventuels comptes, ressources ou opérations créés par un tiers.
Railway continue son enquête et prévoit d’informer individuellement les clients dont l’exposition pourra être confirmée. Le point le plus important reste désormais de savoir combien de variables ont réellement été déchiffrées et si elles ont déjà été utilisées en dehors de la plateforme.