# Railway : comment une intrusion dans le build a atteint des secrets pourtant chiffrés

> Railway décrit une escalade dans son infrastructure de build puis la lecture de variables d’environnement chiffrées et déchiffrées. Chronologie, portée et réponse.

Publié le: 2026-11-04  
Canonical: https://rootzero.eu/research/railway-build-secrets-dechiffres-2026/

**Attaque du 20 au 22 octobre 2026 ; rapport préliminaire du 22.** [Railway](https://blog.railway.com/p/preliminary-report-october-security-incident) a identifié un accès non autorisé à une partie de ses systèmes internes pendant une campagne qui cherchait, selon son enquête initiale, des clés d'API de fournisseurs IA. Le détail important n'est pas que la plateforme stockait des variables d'environnement ; toutes les plateformes de déploiement le font. L'attaquant a progressé depuis une possible élévation de privilèges dans le **build** vers des identifiants internes, puis a atteint une capacité de **déchiffrement** de certaines variables. Le chiffrement au repos a contenu une étape, mais pas toute la chaîne.

## Reconstituer les transitions de privilèges

Railway date un premier signal anormal au 20 octobre à 13 h 58 UTC. Ses équipes ont suspecté une escalade dans l'infrastructure de build et arrêté les pipelines pour réduire l'exposition. Elles ont ensuite trouvé d'autres routes d'accès et interrompu de nouveau certains services. Dans la nuit du 21, l'attaquant a pu extraire des secrets sous forme **chiffrée** ; à ce stade, le rapport dit qu'il ne pouvait pas encore les déchiffrer. Il a ensuite atteint des identifiants de l'environnement CI permettant de déchiffrer des artefacts contenant d'autres accès API. Entre 7 h 25 et 9 h 18 UTC, des traces de base de données montrent une requête non autorisée sur des variables chiffrées dont **une partie a été déchiffrée** grâce à la combinaison des accès compromis.

Ce déroulé est plus précis qu'une phrase « le chiffrement n'a servi à rien ». Il a imposé à l'attaquant plusieurs étapes supplémentaires. Le défaut de séparation est que le plan de build, la CI et les capacités permettant de réutiliser ou déchiffrer les secrets pouvaient finalement être enchaînés. L'enquête publique n'expose pas tous les détails de l'exploit initial ; Railway parle de premiers indices d'une élévation de privilèges et réserve une divulgation plus complète à la fin de l'investigation.

## Mesurer le périmètre sans gonfler le bilan

Railway estime qu'**au maximum 1,85 % de ses workspaces**, environ **100 000 espaces de travail**, avaient des variables potentiellement compromises. Ce plafond n'est pas un nombre de victimes dont chaque clé a été lue ou utilisée. Le rapport précise qu'il ne peut pas identifier toutes les variables effectivement déchiffrées à partir de la seule requête observée. Des fournisseurs de clés ont reçu des listes plus larges pour révocation de précaution ; recevoir un email de rotation de l'un d'eux ne prouve donc pas que sa clé personnelle a été exfiltrée.

Railway dit que les comptes utilisateurs n'ont pas été connectés par l'attaquant dans cette intrusion. Il laisse ouverte, dans son rapport préliminaire, la question d'un éventuel accès au code source. Les déploiements déjà en cours sont restés en ligne, tandis que les nouveaux builds et certains outils ont été suspendus pendant l'enquête. Ces distinctions évitent de confondre interruption de plateforme, fuite de secret et vol de code.

## Ce qu'un audit aurait dû demander

Le test préventif d'une plateforme de build doit examiner l'isolation des jobs, les privilèges des agents CI, les identifiants qui ouvrent les artefacts et la façon dont une demande de déchiffrement est autorisée. Pour chaque clé, on suit le chemin complet : stockage, restauration dans le job, logs, sauvegardes et accès support. Le critère à vérifier est : « un composant compromis du build peut-il obtenir à la fois la donnée chiffrée et les droits permettant sa lecture ? ».

Railway dit avoir reconstruit ses outils depuis des sources vérifiées, changé les clés internes, accéléré le passage à une nouvelle génération de builders isolés et demandé aux clients de révoquer les secrets stockés avant le 21 octobre. La rotation doit se faire aussi chez les émetteurs de clés, puis être suivie d'une revue des accès effectués pendant la fenêtre d'exposition. Cette affaire montre que le chiffrement au repos est une **barrière parmi plusieurs** ; la sécurité dépend de l'isolement des capacités de déchiffrement et des chemins d'administration.

**Sources principales :** [rapport préliminaire Railway](https://blog.railway.com/p/preliminary-report-october-security-incident), [première communication Railway](https://blog.railway.com/p/security-disclosure-wednesday-october-21st).