exploit
96 wallets drainés en 70 minutes : le soupçon d'une retombée de la fuite Railway du 21 octobre
Carlos (Definitive) documente 96 wallets drainés à partir de 16:11 UTC, signatures légitimes — soupçon d'une retombée de la fuite Railway du 21 octobre.
Un drainage coordonné de 96 wallets sur environ 70 minutes, à partir de 16:11 UTC, a été documenté publiquement par Carlos, growth lead de la plateforme d'exécution on-chain Definitive. Les transactions sont signées avec les clés légitimes des wallets victimes, ce qui suggère une fuite de clés privées, seed phrases ou accès de signature côté serveur. Carlos soupçonne un lien avec la compromission divulguée le 21 octobre par Railway, hébergeur dont le stockage de variables d'environnement a été compromis. Le fil est repris par Journal du Coin ; la source primaire est le post X de Carlos et le rapport Railway sur l'incident du 21 octobre (voir « Incident de sécurité, environment variables »).
Ce qui est documenté
- Volume observé : 96 wallets drainés, dont au moins un hot wallet personnel historique de Carlos
- Fenêtre : environ 70 minutes à partir de 16:11 UTC le 6 novembre 2026
- Chaînes confirmées : Ethereum (observations préliminaires). De l'activité sur d'autres chaînes a été notée sans analyse consolidée
- Vecteur : les transactions sont signées avec les clés légitimes des wallets concernés — le chemin d'intrusion n'est pas démontré
- Observation Carlos : plus de 110 000 USD en stablecoins routés via RelayDepository sur deux opérations sur un mois — chiffre partiel, pas le total des 96 wallets
- Statut Definitive : aucune preuve publique que Definitive ou ses clients aient été compromis
Aucune adresse d'attaquant n'a été publiquement identifiée à ce stade. Le total des pertes n'est pas consolidé.
L'incident Railway du 21 octobre
Railway, hébergeur PaaS largement utilisé pour déployer des services Node.js, Python et Go, a publié le 21 octobre 2026 la divulgation d'un accès non autorisé à son système de stockage de variables d'environnement. Les secrets chiffrés auraient pu être exposés en clair. Railway a recommandé à ses clients de révoquer et remplacer l'ensemble de leurs credentials. Le rapport préliminaire indique que l'intrusion visait les systèmes internes et non les comptes clients individuels.
Le soupçon de Carlos repose sur :
- La coïncidence temporelle entre l'incident Railway (21 octobre) et la vague de drainages (6 novembre, ~16 jours plus tard)
- Le mode opératoire : signatures avec clé légitime, cohérent avec un vol de secrets stockés dans un environnement serveur
- Son wallet victime : un hot wallet personnel historique dont la clé pourrait avoir transité par un environnement Railway
Aucune preuve publique ne relie, à ce stade, les 96 wallets à des infrastructures hébergées sur Railway.
Que surveiller
- Un décompte consolidé des pertes. Les 96 wallets sont une observation préliminaire ; la couverture réelle nécessitera un bilan ZachXBT, SEAL 911 ou équivalent — la bilan SEAL hebdomadaire couvert vendredi dernier listait déjà 68 M$ sur une semaine, hors cet épisode.
- La publication d'adresses d'attaquant. Sans adresse, la défense collective est aveugle — exchanges, analystes et victimes doivent pouvoir figer la moindre interaction.
- La remontée Railway post-mortem. L'hébergeur doit indiquer quelles organisations clientes avaient des secrets exposés et quand elles ont été prévenues. La fenêtre de 16 jours entre divulgation et exploitation potentielle est un indicateur de la maturité du post-incident.
- Les équipes crypto qui déploient sur Railway. Les signers, bots de market-making, bots MEV, et relayers de bridges qui conservent des clés privées côté serveur ont une priorité opérationnelle : rotation immédiate si ce n'est pas déjà fait au 21 octobre.
Contexte
Les compromissions d'infrastructure cloud à répercussion crypto suivent un pattern connu — Lastpass 2022 (vols de seed phrases exposées via des vaults de clients), Ledger Connect Kit 2023 (compromission de la chaîne d'approvisionnement JS, ~600 000 USD), Dropbox Sign 2024 (API keys de clients crypto exposées). Dans chaque cas, le vecteur était non crypto-natif : un gestionnaire de secrets, une librairie, un PaaS. La fenêtre d'exploitation varie — immédiate pour une supply-chain compilée, plusieurs mois pour des secrets chiffrés nécessitant décryptage. Si le lien Railway est confirmé, l'épisode du 6 novembre est le premier cas documenté sur ce PaaS spécifique ; il ne sera pas le dernier à exploiter une couche de déploiement non spécialisée crypto.