Fuite · · 4 min de lecture
Railway dit que certaines variables d’environnement de clients ont pu être lues
L’entreprise dit qu’au plus 1,85 % des espaces de travail étaient à portée, environ 100 000, et elle demande quand même à chacun de faire tourner ses secrets.
Le 21 octobre 2026, Railway a dit à ses clients qu’un tiers a peut-être lu des variables d’environnement stockées sur la plateforme, et que pour certaines de ces variables le tiers a obtenu la valeur déchiffrée. Les variables d’environnement sont l’endroit où beaucoup de projets gardent des clés d’API, des mots de passe de base de données et des identifiants de registre. Si vous n’avez pas de projet Railway, cela ne vous concerne pas.
Ce que Railway a publié
La première divulgation (en anglais) disait que l’enquête de l’entreprise indiquait jusqu’ici un accès non autorisé à des variables d’environnement chiffrées et, pour certaines, au contenu déchiffré. Railway disait croire que l’intrusion faisait partie d’une série d’attaques contre des plateformes d’hébergement, visant des fournisseurs d’inférence d’IA. Elle a suspendu les déploiements et a dit à chaque utilisateur de faire tourner les variables d’environnement, les clés d’API et les identifiants de registre privé, et de vérifier les journaux des fournisseurs, même si elle pensait que seul un sous-ensemble d’utilisateurs était touché.
Un rapport préliminaire publié ensuite est plus précis, et il dit que l’analyse n’est pas terminée. Dans ce récit, l’attaquant a d’abord tiré des secrets sous forme chiffrée et ne pouvait pas encore les déchiffrer. Il a ensuite atteint des identifiants de l’environnement d’intégration continue de Railway et s’en est servi pour déchiffrer des artefacts. Railway a ensuite trouvé une requête sur des variables d’environnement chiffrées, dont un sous-ensemble a été déchiffré. Comme les valeurs étaient chiffrées par enveloppe, Railway dit que cette requête ne montre pas quelles clés individuelles, dans un projet touché, ont été déchiffrées.
Le plafond que donne Railway est d’au plus 1,85 % des espaces de travail, ce qu’elle dit représenter environ 100 000 espaces. Elle dit aussi avoir demandé aux fournisseurs en amont de révoquer un ensemble de clés plus large, donc plus de 100 000 utilisateurs peuvent voir une réinitialisation du côté du fournisseur même si leur espace était hors des 1,85 %. L’entreprise dit que l’attaquant cherchait des identifiants d’IA, que les espaces avec beaucoup de variables ou beaucoup de clés d’IA étaient le risque plus élevé, et que les comptes d’utilisateurs Railway n’ont pas été consultés. Elle dit écrire aux clients dont l’impact est certain et à d’autres qu’elle considère à risque élevé.
Le 22 octobre, Railway a dit avoir elle-même réinitialisé les identifiants des compartiments de stockage, et avoir invalidé les jetons GitHub qu’elle détenait. Ces jetons GitHub peuvent encore fonctionner du côté de GitHub tant que vous ne les révoquez pas. Railway ne peut pas en créer un nouveau. Vous reconnectez GitHub vous-même. Les services prennent les nouveaux identifiants de compartiment au prochain déploiement.
Si vous utilisez Railway
- Faites tourner les secrets qui vivaient dans les variables Railway, même si vous n’avez pas reçu d’avis personnel. C’était l’instruction de l’entreprise le 21 octobre, et le rapport préliminaire ne la réduit pas à une liste que vous pouvez vérifier vous-même. Incluez les clés d’API, les identifiants de base de données et les connexions de registre privé. Regardez ensuite chez ces fournisseurs s’il y a une utilisation que vous ne reconnaissez pas.
- Révoquez les jetons GitHub, ne vous contentez pas de reconnecter. Reconnecter donne un nouveau jeton à Railway. L’ancien jeton de registre reste valide chez GitHub tant que vous ne le révoquez pas là-bas.
- Redéployez tout ce qui lit les identifiants de compartiment. Railway dit que le nom du compartiment et les objets n’ont pas changé. Les clés d’accès, oui. Un conteneur en cours garde l’ancien environnement jusqu’à son prochain démarrage.
- Un mot de passe que vous n’avez utilisé que sur un site, et jamais stocké dans une variable Railway, n’est pas ce que décrit cet incident. L’entreprise dit ne pas avoir accédé aux comptes d’utilisateurs Railway.
Sources
- Railway, Security disclosure : Wednesday October 21st, 21 octobre 2026
- Railway, Preliminary report : Oct 21st security incident, octobre 2026
- Railway, Redeploy buckets and reconnect GitHub after the credential reset, 22 octobre 2026
Les nouveaux articles, par courriel.
Environ une fois par mois. Des notes sur la vie privée en termes simples, rien d’autre. Je ne partage jamais votre adresse.