Railway et Heroku ont tous deux été compromis via leur infrastructure partagée. Voici le vrai schéma, pas un argument de vente.

Deux plateformes qui font tourner les applications de beaucoup d’autres personnes ont publié de vrais incidents de sécurité confirmés ces dernières années : Railway en octobre 2026, et Heroku en avril 2022. Les deux sont documentés par les entreprises elles-mêmes, pas par des rumeurs. Et les deux remontent à la même forme de risque sous-jacente : une faille dans une infrastructure que la plateforme exploite pour le compte de nombreux clients à la fois, qui s’est transformée en accès à des données appartenant à des clients qui n’avaient rien à voir avec la faille d’origine.

Ce billet n’est pas « toutes les plateformes ont été piratées » — ce serait faux, et nous n’allons pas l’affirmer. Ce sont deux incidents réels et bien documentés, ce qu’ils ont réellement en commun, et ce qu’un modèle où vous possédez vos serveurs change à ce schéma précis. Nous avons déjà écrit une analyse complète de l’incident Railway à part : la faille de Railway sur les variables d’environnement. Ce billet regarde le schéma à travers les deux incidents.

Ce qui s’est réellement passé, dans les deux cas

Railway, octobre 2026. Le rapport préliminaire de Railway décrit un attaquant qui a escaladé ses privilèges dans l’infrastructure de build de Railway, atteint son environnement CI, puis accédé depuis là aux systèmes stockant les variables d’environnement des clients — en déchiffrant une partie d’entre elles. Selon les chiffres de Railway lui-même, jusqu’à 1,85 % de tous les workspaces, environ 100 000, ont eu des variables d’environnement potentiellement exposées. Le détail complet et les mots de Railway sont dans notre billet dédié à la faille.

Heroku, avril 2022. Un acteur malveillant a obtenu les identifiants d’un compte machine Heroku, laissés dans un dépôt GitHub privé archivé contenant le code source de Heroku. Cet accès a atteint une base de données Heroku stockant les jetons OAuth de l’intégration GitHub des clients, puis une base de données clients interne, où des mots de passe clients hachés et salés ont été exfiltrés. Heroku a fait sa divulgation le 15 avril 2022, a révoqué les jetons de l’intégration GitHub, forcé une réinitialisation de mot de passe pour les utilisateurs concernés, et l’intégration GitHub elle-même est restée hors ligne jusqu’au 25 mai 2022. L’équipe sécurité de GitHub a confirmé séparément que les jetons OAuth volés avaient servi à accéder à des dépôts privés dans des dizaines d’organisations, dont npm.

Le schéma commun aux deux

Dans aucun des deux cas, un client n’a fait quoi que ce soit de mal, et ce n’était pas une attaque par force brute sur un compte individuel. Dans les deux cas, le point d’entrée était un élément d’infrastructure que la plateforme exploite de façon centralisée — le pipeline build/CI de Railway, le contrôle de source interne et les identifiants de compte machine de Heroku — et le point de sortie était des données appartenant à un grand nombre de clients sans lien entre eux, atteintes à travers ce seul système partagé.

C’est le mécanisme réel qui vaut la peine d’être nommé : sur une plateforme multi-tenant, le système de build, le control plane et le calcul qui fait tourner le code des clients se trouvent typiquement tous dans le même périmètre interne d’un seul opérateur. Une fuite d’identifiants ou un bug d’escalade de privilèges dans n’importe lequel de ces systèmes est potentiellement un chemin vers les données de tout le monde, parce que « tout le monde » partage l’infrastructure où vit ce bug.

Ce qu’un modèle sur vos propres serveurs change réellement — et ce qu’il ne change pas

Nous l’avons écrit avec soin dans le billet sur Railway et ça s’applique ici aussi : le control plane de Railyard stocke lui aussi les variables d’environnement des clients de façon centralisée, chiffrées au repos, de la même manière générale que toute plateforme qui détient des secrets clients — Railway et Heroku inclus. Une compromission de la base de données du control plane de Railyard et de sa clé de chiffrement est le même type général de risque que porte tout magasin de secrets centralisé, quel que soit l’endroit où tourne le calcul. Posséder son propre serveur ne fait pas disparaître cette base de données.

Ce qui change, c’est ce que touche la copie déchiffrée et active d’un secret une fois sortie de ce magasin. Sur Railyard, les variables sont déchiffrées une seule fois, au moment du déploiement, et livrées à un serveur dans le compte cloud propre à ce client précis — pas à une flotte de calcul partagée que la plateforme exploite elle-même. Il n’y a pas de pipeline de build ou d’environnement CI unique dont la compromission donne à un attaquant un point d’appui dans les applications en cours d’exécution d’autres clients, parce qu’il n’y a pas de flotte partagée d’applications en cours d’exécution à travers laquelle pivoter. L’environnement actif de chaque client est une machine différente dans un compte différent.

C’est une affirmation étroite et précise : elle ferme un seul chemin — un bug dans l’infrastructure partagée de la plateforme devenant une voie vers les secrets actifs de nombreux clients sans lien à la fois — pas tous les chemins. Ce n’est pas une affirmation que Railyard, ou qui que ce soit, est à l’abri d’une faille. Une entreprise qui vous dit qu’elle ne peut pas être piratée est une entreprise dont vous devriez être plus méfiant, pas moins.

Que faire réellement, sur n’importe quelle plateforme

• Faites tourner vos secrets sur un calendrier, pas seulement après une divulgation. Une clé API statique et de longue durée qui dort dans le tableau de bord de n’importe quelle plateforme est un risque permanent, indépendant de tout incident précis.
• Limitez la portée des identifiants. Plus la portée d’une seule clé volée est petite, moins une faille de n’importe quel type vous coûte.
• Demandez ce qu’il faut compromettre pour atteindre un secret déchiffré et actif — pas seulement si les données sont « chiffrées au repos ». Le chiffrement au repos est la base partout ; la vraie question est combien de systèmes partagés se trouvent entre un bug ailleurs sur la plateforme et vos secrets réellement en cours d’exécution.
• Lisez les rapports d’incident que les entreprises publient réellement. Les divulgations de Railway et de Heroku sont ici réellement instructives quand on sépare ce qu’elles ont confirmé de ce qui a été amplifié par des sources secondaires — voir notre analyse de la faille Railway pour un exemple de cette distinction.

Voir les comparaisons complètes : Railyard contre Railway et Migrer depuis Heroku.

FAQ

Est-ce que toutes les plateformes PaaS ont été piratées? Non, et nous ne l’affirmons pas. Ce billet couvre deux incidents précis, confirmés et bien documentés — Railway (2026) et Heroku (2022) — pas toutes les plateformes du marché.

Faire tourner son propre serveur rend-il une faille impossible? Non. Le control plane d’une plateforme doit toujours stocker vos secrets quelque part avant de les déployer, et ce magasin reste une cible sur n’importe quelle architecture, Railyard inclus. Ce qui change, c’est si un bug dans l’infrastructure partagée de build/calcul de la plateforme peut devenir un chemin vers les secrets actifs d’autres clients — sur un modèle où vous possédez vos serveurs, il n’y a pas de flotte de calcul partagée à travers laquelle ce bug peut pivoter.

Quel est le point commun réel entre les incidents de Railway et de Heroku? Dans les deux cas, le point d’accès initial était une infrastructure que la plateforme exploite pour le compte de nombreux clients à la fois (le pipeline build/CI de Railway ; le contrôle de source interne et les identifiants de compte machine de Heroku), et l’impact a atteint des clients qui n’avaient rien à voir avec la faille d’origine.

Sources

• Security Disclosure: Wednesday October 21st — blog officiel de Railway
• Preliminary Report: Oct 21st Security Incident — blog officiel de Railway
• April 2022 Incident Review — blog officiel de Heroku
• Incident 2413 — page de statut officielle de Heroku
• Security alert: Attack campaign involving stolen OAuth user tokens — blog officiel de GitHub
• Heroku Forces User Password Resets Following GitHub OAuth Token Theft — couverture secondaire