Votre hébergeur a été piraté : renouvelez vos variables dans le bon ordre

Le 21 octobre 2026, Railway a publié un avis de sécurité : le matin même, l'entreprise a détecté une activité anormale dans les systèmes qui stockent les variables d'environnement de ses clients, et son enquête indique pour l'instant qu'un tiers non autorisé a pu accéder à des variables chiffrées et, pour certaines, en obtenir le contenu déchiffré. Railway recommande à tous ses utilisateurs de renouveler chaque variable d'environnement stockée chez elle, clés d'API et identifiants de registres privés compris, et de vérifier les journaux des services concernés. Si vous déployez une application Laravel ou Node, où que ce soit, la leçon dépasse cette seule entreprise : vos secrets vivent dans la base de données de quelqu'un d'autre, et le jour où elle fuit, vous découvrez si vous savez les remplacer.

Ce que Railway a déclaré

Selon Railway, les variables touchées peuvent contenir des clés d'API ainsi que des identifiants de bases de données et de registres. L'entreprise dit que son analyse initiale suggère un impact limité à une partie des utilisateurs, mais elle demande malgré tout à tout le monde de renouveler. Elle pense que l'incident s'inscrit dans une série d'attaques visant récemment les plateformes, dans le but d'atteindre des fournisseurs d'inférence IA, et elle a prévenu ces fournisseurs pour qu'ils révoquent les clés de manière préventive. Les déploiements ont été suspendus pendant l'enquête : impossible de livrer une nouvelle version tant que les builds n'étaient pas rétablis. Railway dit qu'elle écrira par e-mail aux clients dont l'exposition est confirmée et publiera ses mises à jour sur status.railway.com.

Ce dernier point compte pour s'organiser. Si votre rotation passe par un déploiement sur la plateforme compromise, vous devrez peut-être attendre. Raison de plus pour avoir la liste prête avant d'en avoir besoin.

L'inventaire que vous devriez déjà avoir

Ce qui suit est un conseil général, pas une consigne de Railway. Commencez par lister chaque secret utilisé par l'application et son origine. Pour une application Laravel ou Node classique, cela veut dire le mot de passe de la base, les identifiants de file d'attente et de cache, les clés du service d'e-mail, celles du prestataire de paiement et des fournisseurs d'IA, les secrets clients OAuth, les secrets de signature des webhooks, les clés de stockage objet comme S3 et les jetons de monitoring comme Sentry. À côté de chacun, notez le fournisseur, qui peut le renouveler et quels services le lisent. Sans cette liste, la rotation commence par une relecture du vieux code pour savoir à quoi l'application se connecte.

Laravel a un secret aux effets de bord. Changer APP_KEY invalide tout ce qui a été chiffré ou signé avec : cookies chiffrés, sessions, valeurs stockées via Crypt, URL signées. Laravel accepte une liste de clés précédentes, encore utilisées pour déchiffrer pendant une rotation ; lisez la documentation de votre version avant de compter dessus. La forme est une liste séparée par des virgules dans l'env :

APP_KEY=base64:the-new-key
APP_PREVIOUS_KEYS=base64:the-old-key

Gardez en tête que si l'ancienne clé a fuité, les données chiffrées avec elle sont lisibles par qui la détient. Rechiffrez ce qui compte et retirez l'ancienne clé dès qu'elle ne sert plus.

Dans cet ordre : créer, déployer, révoquer

L'ordre qui évite toute coupure est simple. Créez un nouvel identifiant chez le fournisseur pendant que l'ancien fonctionne encore. Mettez la nouvelle valeur dans l'env et déployez. Vérifiez que l'application l'utilise. Ensuite seulement, révoquez l'ancien, chez le fournisseur, et pas en l'effaçant de votre fichier env : une clé retirée de votre application reste une clé valide pour quiconque l'a copiée. Pour finir, ouvrez le tableau de consommation de chaque fournisseur et cherchez une activité qui ne vient pas de vous, surtout sur les API payantes.

Rendre la prochaine fuite moins coûteuse

Là encore, conseil général : utilisez des clés à périmètre restreint avec plafond de dépenses quand le fournisseur le permet, des clés distinctes par environnement pour qu'une fuite de staging ne devienne pas une fuite de production, et ne laissez jamais un secret atteindre un dépôt git ou un log de build. Chacune de ces mesures réduit ce que peut vous coûter un seul stockage compromis.

L'étape suivante est concrète. Aujourd'hui, rédigez l'inventaire d'une application : chaque secret, son fournisseur, et les étapes créer, déployer, révoquer qui le concernent. Si vous êtes sur Railway, suivez ses instructions et renouvelez tout maintenant. Sinon, faites l'exercice quand même : la question n'est pas de savoir si votre hébergeur sera le prochain, mais si vous pourriez réagir en une heure.

Source : blog de Railway, « Security Disclosure: Wednesday October 21st ».