La plateforme d’hébergement Railway a publié le 22 octobre un rapport préliminaire sur l’intrusion qui l’a forcée à suspendre tous les déploiements pendant près de deux jours. Le bilan est sérieux : environ 1,85 % des workspaces, soit à peu près 100 000, ont eu des variables d’environnement potentiellement compromises.
Ce qui s’est passé
Selon Railway, l’attaquant a obtenu une élévation de privilèges dans l’infrastructure de build, puis a atteint l’environnement de CI et l’outillage interne. De là, il a extrait des variables d’environnement chiffrées de la base de données. Il a ensuite réussi à en déchiffrer une partie avec des identifiants compromis.
D’après Railway, sa cible principale était les clés d’API de fournisseurs d’IA, apparemment pour des attaques de distillation de modèles. Railway a d’ailleurs prévenu ces fournisseurs dès le matin du 21 octobre pour qu’ils révoquent les clés. Mais une variable d’environnement contient bien plus que des clés d’IA : mots de passe de bases de données, jetons de registres privés, clés de paiement…
Railway affirme que les comptes utilisateurs n’ont pas été touchés. En revanche, un accès au code source n’est pas encore exclu ; le rapport final doit trancher.
Chronologie (UTC)
| Date | Événement |
|---|---|
| 20 oct., 13 h 58 | Début de l’attaque |
| 20 oct., 14 h – 18 h | Élévation de privilèges découverte, builds arrêtés |
| 21 oct., 4 h 24 | L’attaquant peut extraire les secrets chiffrés |
| 21 oct., matinée | Une partie des secrets est déchiffrée ; les fournisseurs d’IA sont prévenus |
| 21 oct., soir | Sessions invalidées, annonce publique, consignes de rotation |
| 22 oct., 3 h 32 | Attaquant expulsé des systèmes internes |
| 22 oct., soir | API et déploiements rétablis |
Railway explique qu’il ne peut pas encore dire précisément quelles clés ont été déchiffrées, à cause du chiffrement par enveloppe qu’il utilise. C’est pour cette raison que la consigne vaut pour tout le monde, et pas seulement pour les comptes prévenus.
Si vous avez des services sur Railway, considérez comme compromis tous les secrets enregistrés avant le 21 octobre.
La checklist
- Changez les identifiants de vos bases (PostgreSQL, MySQL, Redis, MongoDB) et supprimez leur accès réseau public s’il n’est pas indispensable.
- Révoquez et recréez vos clés d’API : OpenAI, Anthropic, OpenRouter, Stripe, AWS, GCP… puis surveillez leur consommation pour repérer un usage anormal.
- Vérifiez les journaux d’audit de GitHub, de Docker Hub ou de votre registre, ainsi que les applications GitHub installées.
- Recréez vos jetons CLI et CI liés à Railway, et reconnectez GitHub : Railway a réinitialisé toutes les installations de son application GitHub.
- Redéployez votre dernier commit : les commits poussés pendant la suspension du 21 octobre n’ont pas été déployés.
Pour la rotation, l’ordre compte : créez d’abord le nouveau secret, mettez-le en place dans l’application, redéployez, puis révoquez l’ancien. Révoquer en premier, c’est provoquer sa propre panne.
# Lister les variables d'un service pour inventorier ce qu'il faut changer
railway variable list
# Remplacer une valeur (puis redéployer avant de révoquer l'ancienne clé)
railway variable set "DATABASE_URL=postgres://…"Ce qu’on en retient
Le build est la partie la plus exposée d’une plateforme : il exécute du code arbitraire, celui des clients, à côté de systèmes qui ont accès aux secrets. Railway dit avoir déplacé ses builders vers un environnement isolé par client. C’est justement le genre de cloisonnement dont l’absence a rendu l’attaque possible.