Piratage de Railway : tous les utilisateurs doivent changer leurs secrets, un développeur évoque 370 000 $ de crypto volés

Railway, une plateforme cloud où des développeurs hébergent applications, bases de données et tâches de fond, a demandé mercredi 21 octobre à tous ses utilisateurs de renouveler chaque secret stocké chez elle. Dans un avis de sécurité signé de Jacob Cooper, l’entreprise explique avoir détecté dans la matinée une activité anormale dans les systèmes qui conservent les variables d’environnement de ses clients, et qu’un tiers a peut-être lu des variables chiffrées et, pour certains clients, obtenu leur contenu déchiffré. Ces variables peuvent contenir des clés d’API et des identifiants de bases de données ou de registres privés.

Ce piratage de Railway a vite pris une dimension crypto. The Defiant rapporte qu’un développeur relie un vol d’environ 370 000 $ à l’exposition des secrets de Railway. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il s’agit de l’affirmation d’un seul développeur. Railway n’a confirmé aucun vol, et le seul rapport on-chain que nous ayons trouvé précise que le lien avec Railway n’est pas établi.

Les équipes crypto sont directement concernées. Bots de trading, keepers de liquidation, relayeurs, indexeurs et petits back-ends d’exchange tournent souvent sur des plateformes d’hébergement comme Railway, et beaucoup lisent la clé de signature d’un portefeuille dans une variable d’environnement au démarrage. Si l’hébergeur laisse fuiter la variable, le portefeuille est exposé sans le moindre bug dans un smart contract.

Piratage de Railway : ce que l’entreprise dit avoir été consulté

Le message de Railway est court et prudent. Il ne dit ni comment l’attaquant est entré, ni combien de clients sont touchés, ni depuis quand l’accès existait. L’entreprise indique que les premières analyses laissent penser que l’impact pourrait se limiter à une partie des utilisateurs, mais elle conseille à tous d’agir et préviendra par e-mail les clients dont elle confirmera qu’ils sont concernés.

Sur le mobile, Railway affirme croire que l’incident s’inscrit dans une série d’attaques récentes contre des entreprises de plateformes, dont le but est de compromettre des fournisseurs d’inférence d’IA. Autrement dit, l’attaquant en voulait probablement aux clés de services d’IA payants, qui se revendent ou servent à faire tourner des modèles aux frais d’autrui. Railway précise avoir demandé à ces fournisseurs en amont de révoquer les clés de manière préventive.

Le message ne mentionne ni crypto, ni portefeuilles, ni clés privées. L’avis couvre tous les secrets qu’un client a pu stocker, et une clé de portefeuille placée dans une variable d’environnement n’est qu’une chaîne de caractères de plus pour qui la lit, mais rien de ce que Railway a publié ne relie son incident à une perte de fonds.

Railway fait trois demandes à ses clients : renouveler toutes les variables d’environnement stockées sur la plateforme, y compris les clés d’API ; renouveler les identifiants de registres privés ; examiner les journaux de leurs services à la recherche d’activité inhabituelle. À 01 h 22 UTC le 22 octobre, l’entreprise a lié depuis sa page d’état 13 courts guides. Ils portent sur les usages inattendus des comptes OpenAI, Anthropic, OpenRouter et Grok et de Stripe, sur les accès anormaux à GitHub, AWS et Google Cloud, sur les nouveaux identifiants des bases PostgreSQL, MySQL, MongoDB et Redis, et sur le redéploiement des espaces de stockage après la réinitialisation des identifiants, comme le résume aussi le site de cybersécurité SecurityOnline. Aucun des 13 ne traite des portefeuilles ni des clés d’exchange.

Déploiements suspendus et jetons d’API révoqués : la chronologie de l’incident Railway

L’annonce s’est accompagnée d’un gel. Railway a suspendu tous les déploiements pendant l’enquête, ce qui crée un problème gênant : les clients invités à remplacer leurs identifiants ne pouvaient pas livrer de nouvelle version de leur application pour les utiliser. La page d’état de Railway montre le déroulé de la journée, en UTC.

À la mise à jour de 04 h 39 UTC, seuls les clients Enterprise pouvaient de nouveau construire leurs applications, et même eux devaient passer par « Deploy Latest Commit », le bouton Redeploy restant désactivé (mise à jour de 04 h 00 UTC). Railway précise aussi que certaines étapes de rotation, comme la prise en compte des nouveaux identifiants de stockage, ne jouent qu’après un redéploiement. Pour une équipe sur une offre Pro ou Hobby, un secret peut donc être renouvelé chez le fournisseur alors que l’application hébergée sur Railway ne peut pas encore utiliser le nouveau. Un bot dont la clé a été révoquée s’arrête simplement d’ici là.

Vol de 370 000 $ : l’accusation d’un développeur et ce qu’a relevé Onchain Lens

La perte en crypto repose sur deux éléments distincts. Le premier est un article de The Defiant dont le titre indique qu’un développeur relie un vol de 370 000 $ à l’exposition des secrets de Railway. Nous n’avons pas pu lire le corps de l’article : le nom du développeur, la blockchain, le type de portefeuille et les preuves avancées nous sont donc inconnus. Le titre rapporte l’affirmation d’un développeur, relayée par un seul média.

Le second élément est on-chain. Le compte d’analyse Onchain Lens a signalé un « portefeuille d’attaquant présumé » qui a envoyé au moins 369 300 $ vers l’exchange HitBTC et vers d’autres adresses, selon TechFlow, qui a publié l’information à 04 h 03 UTC le 22 octobre, et selon PANews. Les mêmes comptes rendus indiquent que ce portefeuille avait reçu auparavant des fonds d’une adresse liée au CryptoBillis Ledger Drainer, que TechFlow décrit comme un outil de drainage de portefeuilles. Onchain Lens a lui-même précisé que le lien de ce portefeuille avec l’incident Railway n’était pas confirmé.

Les deux montants sont proches, 369 300 $ contre environ 370 000 $, mais aucun des deux rapports ne dit qu’il s’agit de la même perte, et personne ne l’a démontré. Aucune adresse de portefeuille ni aucun hash de transaction n’apparaissait dans les sources que nous avons pu ouvrir : les mouvements n’ont donc pas pu être vérifiés sur un explorateur de blocs. Le lien avec un drainer ne tranche pas non plus. Un portefeuille alimenté depuis des adresses liées à un drainer peut appartenir à un voleur qui réutilise ses outils, ou à un vol sans rapport avec Railway.

Ce que l’on ignore encore sur l’incident Railway

• Comment l’attaquant a atteint les systèmes qui stockent les variables d’environnement, et depuis quand.
• Combien de clients ont vu leurs variables déchiffrées, et si les e-mails aux clients concernés sont partis.
• Si une clé privée de portefeuille ou une phrase de récupération était stockée dans une variable Railway touchée.
• Qui est le développeur cité par The Defiant, et quelle preuve relie la perte de 370 000 $ à Railway.
• Si le portefeuille signalé par Onchain Lens est celui que ce développeur met en cause.
• Si Railway s’exprimera un jour sur des pertes en crypto.

Variable d’environnement exposée : ce que cela change pour les portefeuilles et les bots

Une variable d’environnement est une valeur nommée qu’un programme lit à son démarrage, comme DATABASE_URL ou OPENAI_API_KEY. Les plateformes d’hébergement conservent ces valeurs pour vous et les injectent dans l’application : c’est pratique, et cela garde les secrets hors du dépôt de code. Cela veut aussi dire que l’hébergeur détient une copie de chaque secret. Quand il est piraté, tous les secrets sont exposés d’un coup.

Pour la plupart des applications, une clé d’API qui fuite est un problème de facturation ou de données. On peut la révoquer, et les dégâts se limitent à ce qu’elle autorisait. Une clé privée est tout autre chose. Celui qui la lit contrôle le portefeuille, et il n’existe pas de bouton de révocation sur une blockchain. Les fonds déplacés sont perdus, sauf si un exchange les gèle à leur arrivée.

C’est le point faible de nombreuses petites opérations crypto. Un bot de market making, un script d’arbitrage ou un keeper pour un protocole de prêt doit signer des transactions sans qu’une personne clique sur « confirmer » : la clé se retrouve donc souvent dans une variable nommée PRIVATE_KEY, sur le même hébergeur que le code. Le portefeuille devient un hot wallet dont la sécurité vaut celle du compte d’hébergement.

Quoi renouveler tout de suite si vous avez utilisé Railway

Les mesures ci-dessous relèvent de la bonne pratique générale en sécurité, pas de consignes de Railway, hormis le renouvellement des variables et des identifiants de registres que Railway demande lui-même.

• Si une clé privée de portefeuille ou une phrase de récupération a un jour été stockée dans une variable Railway, considérez-la comme compromise : créez un nouveau portefeuille, déplacez les fonds, puis faites utiliser la nouvelle clé par le bot.
• Révoquez les autorisations (allowances) de jetons accordées par l’ancien portefeuille à des contrats, car un voleur qui détient la clé peut aussi s’en servir.
• Renouvelez les clés d’API d’exchange stockées sur Railway ; en créant les nouvelles, désactivez le droit de retrait et limitez-les à l’adresse IP de votre serveur si la plateforme le permet.
• Changez les clés de fournisseurs RPC, les mots de passe de bases de données, les secrets de webhooks et les jetons des bots Telegram ou Discord utilisés pour les alertes.
• Créez de nouveaux jetons d’API Railway, puisque les anciens ont été invalidés à 04 h 17 UTC le 22 octobre, et mettez à jour les scripts de déploiement qui les utilisent.
• Vérifiez dans les journaux de vos comptes d’IA, de paiement et de cloud les activités que vous n’avez pas lancées, comme le suggèrent les guides de Railway.

Garder les clés de hot wallet hors des variables d’environnement en clair

La solution durable consiste à ne plus mettre une clé de signature brute là où l’hébergeur peut la lire. Parmi les options : un service de gestion de clés dans le cloud ou un module de sécurité matériel (HSM) qui signe sans exposer la clé, un service de signature séparé avec ses propres plafonds, ou un portefeuille de smart contract dont la clé du bot ne peut faire que de petites transactions sur liste blanche. Quelle que soit la solution, un hot wallet utilisé par un bot ne doit contenir que le solde nécessaire pour les prochaines heures, le reste dormant en stockage à froid, comme l’explique notre guide des portefeuilles crypto et de la conservation.

Côté français, deux cadres existent, sans lien direct avec l’incident lui-même. D’une part, les applications qui détiennent des données personnelles de résidents de l’Union européenne ont une échéance légale. Selon le RGPD, l’entreprise qui décide de l’usage des données (l’exploitant de l’application, dans la plupart des cas) doit notifier une violation de données personnelles à son autorité de protection, en France la CNIL, dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les personnes. Un hébergeur agissant comme sous-traitant doit prévenir son client dans les meilleurs délais. D’autre part, l’AMF et l’ACPR ne sont pas directement concernées par cette fuite, mais un prestataire de services sur actifs numériques agréé qui ferait tourner des systèmes sur Railway aurait à évaluer l’impact sur ses propres clients.

Railway, troisième alerte sur la sécurité des clés cette semaine

L’incident Railway tombe une semaine difficile pour la sécurité des clés. La fondation Polkadot a demandé aux utilisateurs d’une extension de navigateur de déplacer leurs fonds après que l’extension Fearless Wallet a laissé fuiter des clés privées, et une fausse alerte diffusée par l’application même de Ngrave a vidé au moins 2,56 millions de dollars sur environ 70 portefeuilles. Aucun lien entre les trois affaires n’a été rapporté, et elles fonctionnent différemment. Dans chacune, les pertes, avérées ou alléguées, remontent à l’endroit où les clés ou les secrets sont conservés, non à une faille de protocole.

Ce schéma colle aux chiffres d’ensemble. Les pirates ont dérobé 1,18 milliard de dollars au troisième trimestre 2026, le pire trimestre depuis le piratage de Bybit, selon le rapport Q3 de Hacken.

Ce qu’il faut suivre ensuite

Railway a promis d’écrire aux clients dont elle confirmera qu’ils sont touchés et de publier des mises à jour sur sa page d’état à mesure que le périmètre se précise. Les constructions des offres Pro, Hobby et Free/Trial devaient encore être rétablies par étapes après la mise à jour de 04 h 39 UTC le 22 octobre. La question ouverte pour les lecteurs crypto : le développeur à l’origine de l’accusation à 370 000 $, ou Onchain Lens, publiera-t-il les adresses concernées ? Chacun pourrait alors vérifier si les fonds volés remontent bien à une variable Railway.