Ce qui s’est passé
Le 21 octobre, Railway a révélé qu’un tiers non autorisé avait accédé à des systèmes qui stockent les variables d’environnement des clients, et que pour certaines d’entre elles, l’attaquant avait peut-être obtenu le contenu déchiffré. Railway a suspendu tous les déploiements, prévenu les fournisseurs en amont pour qu’ils révoquent les clés, et demandé à tous ses utilisateurs de renouveler leurs variables d’environnement, y compris les identifiants de registres privés.
Son rapport préliminaire apporte plus de détails :
- L’attaque s’est déroulée du 20 octobre au début de la journée du 22 octobre (UTC). Elle a commencé par une tentative d’élévation de privilèges dans l’infrastructure de build.
- Au maximum 1,85 % des workspaces, soit environ 100 000, ont eu des variables potentiellement compromises. En raison de la façon dont les clés étaient chiffrées, Railway ne peut pas encore dire précisément quels secrets d’un projet affecté ont été exposés.
- L’attaquant cherchait des clés API de fournisseurs d’IA et de plateformes. Railway considère les workspaces comptant beaucoup de variables d’environnement, ou beaucoup de clés d’IA, comme plus à risque.
- Railway indique ne pas pouvoir rembourser les dépenses d’IA effectuées avec des clés compromises. C’est à voir directement avec le fournisseur concerné.
Selon TechCrunch, Railway pense que cette attaque s’inscrit dans une campagne plus large contre des plateformes, visant à compromettre des fournisseurs d’inférence IA. La même semaine, l’outil de code IA OpenCode a révélé que des pirates avaient dérobé des clés API et d’autres secrets à plus de 1 % de ses clients.
Pourquoi les builders sont visés
Des clés d’IA volées valent de l’argent bien réel. Les attaquants revendent l’accès ou épuisent votre quota pour leurs propres charges de travail, un phénomène que les chercheurs appellent LLMjacking. Une plateforme d’hébergement est un endroit idéal pour les récolter, car des milliers d’apps y conservent au même endroit leurs clés OpenAI, Anthropic, Stripe et celles de leur base de données.
Le rapport de Railway contient un détail dérangeant. Les variables étaient chiffrées, mais la plateforme doit pouvoir les déchiffrer pour les injecter dans vos builds et vos services en cours d’exécution. Une fois que l’attaquant a obtenu le bon accès interne, le chiffrement au repos ne l’a pas arrêté. Ce n’est pas propre à Railway. Tout hébergeur qui exécute votre code peut lire vos secrets.
La question n’est donc pas « mon hébergeur est-il sûr ? », mais « si les secrets de mon hébergeur fuitaient demain, quelle serait la gravité, et à quelle vitesse pourrais-je m’en remettre ? »
Comment évaluer votre exposition
Consacrez-y 20 minutes, même si vous avez déjà cliqué sur « renouveler » pour certains éléments.
1. Inventoriez chaque secret. Listez les noms de variables de chaque projet et de chaque environnement, y compris les environnements de staging et de preview. Si vous tenez à jour un .env.example, c’est un bon point de départ :
grep -oE '^[A-Z0-9_]+' .env.examplePour chacun, notez ce qu’il permet d’ouvrir : une base de données, un prestataire de paiement, un fournisseur d’IA, l’e-mail, un bucket de stockage, un jeton GitHub.
2. Vérifiez l’utilisation et la facturation de vos fournisseurs d’IA. Recherchez des pics d’utilisation, des modèles inconnus ou des requêtes à des heures inhabituelles depuis le 20 octobre. C’est là qu’un abus a le plus de chances d’apparaître en premier.
3. Consultez les journaux d’audit dont vous disposez. Railway recommande explicitement d’examiner les journaux d’audit GitHub et les accès des apps installées, ainsi que les journaux de registres comme Docker Hub. Regardez aussi les journaux d’API de votre prestataire de paiement et les journaux de connexion de votre base de données.
4. Vérifiez si votre base de données est accessible depuis Internet. Le rapport de Railway recommande de supprimer l’accès réseau public aux bases de données. Si une chaîne de connexion divulguée pointe vers une base à laquelle n’importe qui peut se connecter, la fuite est immédiatement exploitable :
nc -zv your-db-host.example 5432 # "succeeded" from your laptop = publicly reachable5. Vérifiez ce que votre frontend divulgue déjà. Ce genre d’incident rappelle qu’il faut distinguer les vrais secrets des valeurs publiques par conception. Une clé livrée dans votre bundle JavaScript n’a jamais été secrète.
Comment renouveler sans casser la production
L’erreur classique sous pression : révoquer d’abord l’ancienne clé, puis se dépêcher de déployer la nouvelle pendant que l’app renvoie des erreurs. Procédez plutôt dans cet ordre :
- Créez de nouveaux identifiants chez le fournisseur (nouvelle clé API, nouveau mot de passe de base de données, nouveau secret de webhook). Laissez les anciens actifs pour l’instant.
- Mettez à jour la variable chez votre hébergeur, puis redéployez pour que l’app en cours d’exécution la prenne en compte.
- Vérifiez que l’app fonctionne avec la nouvelle valeur. Appelez un endpoint qui utilise réellement ce service.
- Révoquez les anciens identifiants chez le fournisseur.
- Confirmez que les anciens sont bien morts, par exemple en faisant un appel de test avec eux et en vérifiant qu’il échoue.
Parcourez votre liste par ordre de gravité potentielle : clés de paiement, identifiants de base de données, clés cloud et de stockage, clés de fournisseurs d’IA, jetons GitHub et de registres, puis tout le reste. Les recommandations de Railway se concentrent sur les variables définies avant le 21 octobre, et ses conseils ultérieurs ajoutent de reconnecter GitHub et de recréer les identifiants CLI et CI.
Quelques secrets demandent une attention particulière :
- Les secrets de signature de session ou JWT. Les changer déconnecte tous les utilisateurs. C’est généralement acceptable après une fuite, mais prévenez vos utilisateurs si vous le pouvez.
- Les secrets de signature de webhook. Mettez à jour le côté récepteur et le fournisseur émetteur en même temps, sinon vous rejetterez des événements légitimes pendant un moment.
- Les mots de passe de base de données. Si votre plateforme le permet, créez un nouvel utilisateur de base de données avec les mêmes droits, basculez l’app dessus, puis supprimez l’ancien. C’est plus propre que de changer un mot de passe en place.
Rendre la prochaine fuite moins douloureuse
Vous ne pouvez pas empêcher votre hébergeur de se faire pirater. Vous pouvez en revanche faire en sorte qu’un secret divulgué vaille moins.
Limitez la portée des clés. Utilisez des clés restreintes quand les fournisseurs en proposent. Une clé restreinte Stripe qui ne peut que créer des sessions Checkout est bien moins utile à un attaquant qu’une clé secrète complète.
Plafonnez les dépenses. Définissez des budgets mensuels et des alertes d’utilisation chez chaque fournisseur d’IA. Une mauvaise surprise à cinq chiffres devient alors un simple e-mail.
Séparez les environnements. Ne réutilisez pas les clés de production en staging ou dans les déploiements de preview. Chaque environnement doit avoir ses propres identifiants, pour qu’une fuite dans l’un ne livre pas l’autre.
Gardez vos bases de données privées. Utilisez le réseau privé de votre plateforme et, si vous êtes sur Supabase, assurez-vous que la Row Level Security est activée pour qu’une clé anon divulguée n’expose pas vos tables.
Ne gardez jamais de secrets dans des fichiers accessibles. Un fichier .env déployé dans votre racine web fuit sans qu’il y ait besoin d’une quelconque intrusion.
Rédigez dès maintenant votre procédure de rotation : la liste de l’étape 1, l’ordre ci-dessus et l’endroit où chaque clé est gérée. La prochaine fois, la rotation prendra une heure au lieu d’un week-end.
Checklist rapide
Passez-la en revue pour chaque app que vous déployez :
- Chaque secret de chaque environnement est listé, avec ce qu’il permet d’ouvrir.
- Chacun a été renouvelé dans l’ordre créer, déployer, vérifier, révoquer.
- L’utilisation et la facturation des fournisseurs d’IA ont été vérifiées depuis le 20 octobre, avec des plafonds de dépenses en place.
- Les journaux GitHub, de registre, de paiement et de base de données ont été contrôlés.
- Les bases de données ne sont pas accessibles publiquement.
- La production et le staging utilisent des clés différentes.
- Aucun vrai secret n’est livré dans le code frontend ni stocké dans des fichiers accessibles depuis le web.
À retenir
Railway a bien fait de communiquer rapidement et de pousser au renouvellement. Mais cela arrive régulièrement aux plateformes d’hébergement et aux outils pour développeurs, parce que c’est là que se trouvent les clés. Les builders qui traversent ce genre d’épisode sereinement sont ceux qui savent quels secrets ils ont et peuvent les remplacer en un après-midi.
Pendant que vous faites le ménage, il vaut aussi la peine de vérifier ce que votre app expose de l’extérieur. AppSafe analyse votre site en production à la recherche de problèmes courants comme des clés API dans les bundles JavaScript, des fichiers .env et .git exposés ou des en-têtes de sécurité manquants, avec des correctifs expliqués simplement. Notre checklist de lancement pour les apps créées avec l’IA couvre les autres bases.
Une fois tout renouvelé, lancez un scan AppSafe gratuit pour vous assurer que rien d’autre ne fuit.