Des pirates ont détourné environ une douzaine de sites web de protocoles DeFi et drainé environ 138 000 $ auprès d'utilisateurs ayant interagi avec les front-ends compromis. Chaque site touché partageait un point commun : son domaine était enregistré via Name.com. L'incident rappelle directement que la surface de confiance d'un protocole DeFi s'étend bien au-delà de ses smart contracts jusqu'à l'infrastructure web qui sert son interface utilisateur.

Ce que l'on sait des détournements de sites DeFi

Selon un rapport de The Block du 31 octobre 2026, les attaquants ont pris le contrôle d'environ douze sites DeFi et redirigé les utilisateurs vers des flux malveillants, entraînant environ 138 000 $ de fonds dérobés.

Les faits confirmés restent limités : environ douze sites DeFi ont été touchés, tous enregistrés via Name.com, et environ 138 000 $ de fonds utilisateurs ont été dérobés. Les protocoles spécifiquement ciblés, le vecteur d'attaque exact et le nombre de victimes individuelles n'ont pas été confirmés dans les reportages disponibles. Le partage d'un même registrar ne suffit pas à établir une causalité, et Name.com n'a pas été confirmé comme le point de défaillance direct.

Ce qui reste non confirmé

Selon des rapports non confirmés, l'enregistrement partagé via Name.com pourrait indiquer une compromission d'identifiants ou une prise de contrôle de compte au niveau du registrar, ce qui aurait permis aux attaquants de modifier les enregistrements DNS et de rediriger le trafic des domaines sans toucher aux smart contracts sous-jacents. L'incident aurait tout aussi bien pu impliquer des comptes de registrar compromis, de l'ingénierie sociale ou un tout autre vecteur.

Cette distinction importe autant pour les utilisateurs touchés que pour les équipes des protocoles : si les enregistrements DNS ont été altérés, les smart contracts on-chain eux-mêmes peuvent être intacts, ce qui signifie que les trésoreries et les pools de liquidité des protocoles pourraient demeurer intacts pendant que les utilisateurs ayant interagi avec les faux front-ends supportent les pertes.

Les détournements de front-ends passant par l'infrastructure de domaines ont des précédents dans le secteur : en 2022, des attaquants avaient redirigé le DNS de Curve Finance vers un clone malveillant de son interface après avoir compromis un compte chez un fournisseur de domaines, un épisode largement cité qui a fait entrer les contrôles de registrar et de DNS dans les listes de sécurité des équipes DeFi. Toutefois, un précédent n'est pas une preuve : le rôle central ou accessoire de l'enregistrement partagé via Name.com dans ce cas ne pourra être établi que par les conclusions propres des équipes concernées.

Comment un site DeFi détourné met les utilisateurs en danger

Une compromission de front-end web est structurellement différente d'une exploitation de smart contract. Lorsque les attaquants contrôlent un domaine, ils peuvent servir une copie visuellement identique de l'interface légitime tout en remplaçant silencieusement les points de connexion du portefeuille, les adresses de contrats ou les calldata des transactions. Un utilisateur signant ce qui semble être une approbation ordinaire peut en réalité autoriser un contrat drainer à balayer la totalité de son solde de tokens.

Ce que les utilisateurs doivent vérifier avant de signer une transaction

Avant de connecter un portefeuille ou de signer une transaction sur une interface DeFi, les utilisateurs doivent vérifier de manière indépendante l'adresse du contrat avec lequel ils interagissent, en la comparant à la documentation officielle du protocole, et non simplement à l'URL dans le navigateur. Le cadre Secure Transaction Verification and Authorization (STVA) détaille les étapes spécifiques pour inspecter les calldata avant toute approbation. Un domaine qui résout correctement et affiche un certificat SSL valide ne garantit pas que le front-end n'a pas été altéré au niveau du DNS ou de l'hébergement.

Les portefeuilles matériels résistants au phishing peuvent afficher les détails des transactions sur l'écran de l'appareil, indépendamment du navigateur, offrant aux utilisateurs une seconde couche de vérification. Cela dit, un attaquant déterminé qui contrôle le front-end peut rédiger des descriptions de transactions trompeuses. La seule protection fiable consiste à vérifier l'adresse du contrat de destination par rapport au déploiement on-chain canonique du protocole, issu du dépôt GitHub officiel ou de la documentation de gouvernance plutôt que de l'interface dApp connectée.

Les approbations de tokens accordées à un contrat compromis persistent on-chain jusqu'à leur révocation explicite. Tout utilisateur ayant connecté un portefeuille et signé une transaction pendant la période où ces sites étaient sous le contrôle des attaquants doit considérer les approbations en cours comme potentiellement malveillantes. Les outils de gestion des approbations permettent d'auditer et de révoquer les autorisations sur les tokens ERC-20, mais uniquement après avoir confirmé de manière indépendante les bonnes adresses de contrats à révoquer et le bon réseau sur lequel opérer.

Ce que les utilisateurs et les équipes DeFi doivent faire maintenant

Actions des utilisateurs

Les utilisateurs ayant interagi avec l'un des sites DeFi touchés doivent d'abord éviter de connecter leur portefeuille ou de signer de nouvelles transactions jusqu'à ce que le protocole concerné confirme publiquement que le front-end a été restauré et vérifié. Les communications officielles doivent provenir des comptes sociaux vérifiés du protocole et de ses forums de gouvernance, et non de liens intégrés dans des messages privés ou des discussions communautaires, qui constituent un vecteur d'attaque secondaire courant après une compromission de front-end. Comme les reportages disponibles n'ont pas nommé les protocoles touchés, les utilisateurs de n'importe quel front-end DeFi doivent rester attentifs aux annonces directes des protocoles qu'ils utilisent plutôt que de présumer qu'ils n'ont pas été affectés.

Pour les utilisateurs qui ont signé des transactions pendant la période de l'incident, la révocation des approbations n'est conseillée qu'après avoir confirmé la bonne adresse du contrat malveillant auprès d'une source vérifiée et indépendante. Révoquer le mauvais contrat gaspille du gas et procure une fausse assurance. Des protocoles tels qu'Aave V4 publient des registres de contrats canoniques qui peuvent servir de référence pour distinguer les contrats légitimes du protocole des drainers déployés par les attaquants.

Réponse des équipes de protocole

Les équipes touchées doivent traiter cela comme un incident actif jusqu'à ce que la chaîne d'attaque complète soit confirmée. Les priorités immédiates incluent l'audit des journaux d'accès des comptes de registrar, la rotation de tous les identifiants associés aux comptes Name.com, la vérification des enregistrements DNS actuels par rapport à des instantanés réputés sains, et l'examen des journaux de transparence des certificats HTTPS pour détecter tout certificat non autorisé émis pendant la fenêtre d'attaque.

Les équipes doivent également préserver toutes les preuves de l'incident avant d'apporter des modifications, car les données légales sur la fenêtre d'attaque — y compris les journaux de modifications DNS et toute communication avec le registrar — seront nécessaires pour établir précisément ce qui a été compromis et quand. La publication d'un rapport d'incident clair et horodaté une fois le vecteur d'attaque confirmé, plutôt que des communications spéculatives pendant l'enquête, est le standard auquel les communautés touchées s'attendront.

La sécurité des comptes de registrar de domaines, incluant l'application de l'authentification à deux facteurs et les verrous de domaine au niveau du registrar, est une étape de durcissement de base qui empêche les modifications DNS non autorisées même lorsque les identifiants des attaquants sont valides. Le verrouillage de domaine empêche les transferts et les changements DNS sans confirmation explicite du registrar, ce qui en fait un contrôle significatif pour tout protocole dont le site web représente une surface de confiance pour des transactions impliquant des fonds réels.

La leçon plus large

La perte de 138 000 $ signalée sur environ une douzaine de protocoles est modeste par rapport à la TVL totale de la DeFi sur Ethereum. Mais la vulnérabilité structurelle qu'elle expose — à savoir qu'un compte de registrar web2 peut devenir le maillon le plus faible de la pile de sécurité d'un protocole — s'applique à tout projet DeFi qui dépend d'un domaine enregistré de manière centralisée pour servir son interface utilisateur. La sécurité des front-ends, incluant la surveillance du DNS, le durcissement des comptes de registrar et l'accompagnement des utilisateurs dans la vérification indépendante des contrats, mérite la même rigueur opérationnelle que l'audit des smart contracts.