Dans la nuit du 30 au 31 octobre 2026, au moins 12 sites de finance décentralisée (DeFi), tous enregistrés chez le registrar américain Name.com, ont redirigé leurs visiteurs vers des copies piégées. Ces copies demandaient de connecter un portefeuille crypto puis de signer des autorisations qui vidaient les fonds. Les pertes sont estimées entre 138 000 et 202 000 dollars selon les sources. Aucun code applicatif n'a été modifié : l'attaquant a changé l'endroit vers lequel pointait le nom de domaine.
Cet incident concerne la crypto, mais le mécanisme s'applique à n'importe quel site. Voici les faits établis, ce qui reste incertain, puis les protections utiles pour une entreprise qui ne touche pas à la blockchain.
Ce que l'on sait des faits
Chronologie (heures UTC)
| Heure | Événement | Source |
|---|
| 31 oct., 01:00 | Premiers fonds détournés, sur BNB Chain | Bitquery, The Block |
| 31 oct., vers 01:10 | Un utilisateur signale sur X que le site de Flap semble compromis | The Block |
| 31 oct., vers 02:10 | Flap annonce « un incident de détournement DNS » | The Block |
| 31 oct., 02:54 | Blockaid alerte sur Flap et Kintsu, puis liste les autres sites | The Block |
| 31 oct., 03:51 | Des observateurs relèvent que tous les domaines sont chez Name.com | The Block |
| 31 oct., après 05:30 | Derniers vols constatés | Bitquery |
| 31 oct., 12:32 | 10 domaines passent en statut clientHold chez le registrar | The Block |
| 31 oct., fin de matinée (heure de New York) | Suspensions levées, domaines rétablis avec verrou de transfert | The Block |
The Block donne ses heures en heure de New York ; nous les avons converties en UTC. Le statut clientHold demande au registre de retirer le domaine du DNS : le site ne répond plus du tout, ce qui coupe l'attaque.
Les sites touchés
Bitquery liste 12 domaines : flap.sh, kintsu.xyz, pickle.finance, origami.finance, longbow.cash, echelon.market, apexdefi.xyz, shprd.finance, fluxbeam.xyz, stakepoint.app, stonkfun.xyz et supswap.xyz. Name.com a ensuite indiqué que 15 domaines clients avaient été détournés, dont 10 liés à la plateforme d'hébergement Vercel, qui revend des domaines via Name.com.
Les pertes : une fourchette, pas un chiffre
- The Block retrace environ 138 000 dollars arrivés sur trois portefeuilles de l'attaquant, sans compter les pertes sur Solana et Aptos.
- Bitquery compte 202 386 dollars pris à 32 portefeuilles sur six blockchains, et présente ce total comme un minimum. Un seul utilisateur de Kintsu aurait perdu 160 531 dollars, soit environ quatre cinquièmes du total.
Les deux chiffres ne mesurent pas le même périmètre. Retenez une fourchette de 138 000 à 202 000 dollars, probablement sous-estimée.
L'outil utilisé
Selon Blockaid, cité par The Block et Bitquery, les fausses pages embarquaient « Step Drainer », un kit vendu à des escrocs. Le visiteur connecte son portefeuille, le kit lui fait signer une autorisation de transfert, et les fonds partent. Le butin était ensuite réparti entre trois portefeuilles selon des parts fixes de 15, 30 et 55 %.
Ce que l'on ignore encore
Au 5 novembre 2026, aucune analyse de cause publiée par Name.com ou Vercel n'était disponible. Plusieurs points restent ouverts :
- Le point d'entrée. Name.com a reconnu une « activité non autorisée » qui a redirigé des domaines enregistrés sur sa plateforme, sans en préciser l'origine. Selon un projet touché cité par The Block, un représentant de Name.com estimait que la faute venait de « revendeurs tiers ». Kintsu affirme que le problème venait « du côté de Vercel ». Origami évoque une attaque sur des serveurs de noms associés à Vercel.
- Le type de modification. Aucune source consultée ne dit si l'attaquant a changé les serveurs de noms (NS) des domaines ou seulement leurs enregistrements A. Les domaines n'avaient pas tous le même hébergeur DNS : certains utilisaient Cloudflare, d'autres Vercel ou les serveurs de Name.com.
- Un lien avec d'autres incidents. CircleID rappelle qu'un incident distinct, la veille, a touché Polymarket via un script tiers de DebugBear, dont les enregistrements DNS avaient été modifiés via son registrar. Aucun lien d'auteur ou de technique n'est établi entre les deux.
Le seul point commun établi : tous les domaines étaient enregistrés chez Name.com, directement ou via un revendeur.
Pourquoi les smart contracts n'étaient pas en cause
Une application DeFi a deux parties. Les smart contracts tournent sur la blockchain et gardent les fonds. Le site web (le « front-end ») est une page ordinaire, servie par un serveur et trouvée grâce au DNS. C'est lui qui prépare les transactions que l'utilisateur signe.
Kintsu, Origami, FluxBeam et StonkFun ont confirmé que leurs contrats n'avaient pas été touchés. L'attaquant n'en avait pas besoin. En contrôlant la résolution du nom de domaine, il remplaçait le site légitime par le sien, à la même adresse. Le visiteur voyait la bonne URL, une interface familière, et signait de lui-même une transaction vers l'attaquant.
Transposé à une entreprise classique, le même scénario donne une fausse page de connexion à l'adresse habituelle de votre espace client, ou un faux tunnel de paiement sur votre boutique.
Ce qui a pu être modifié
Deux leviers permettent ce type de redirection. Faute de détails publics, voici ce que chacun implique.
| Modification | Où elle se fait | Effet | Comment la repérer |
|---|
| Serveurs de noms (NS) | Chez le registrar | Toute la zone passe sous le contrôle de l'attaquant : site, emails, sous-domaines | dig NS sur le serveur du registre |
| Enregistrement A ou CNAME | Chez l'hébergeur DNS | Seul le nom visé pointe vers un autre serveur | dig A et comparaison avec l'IP attendue |
Pour vérifier les serveurs de noms tels que le registre les publie, interrogez directement un serveur du registre :
dig NS exemple.com @a.gtld-servers.net +norecurse
dig NS exemple.fr @d.nic.fr +norecurse
Pour servir une copie en HTTPS sans alerte du navigateur, un attaquant a besoin d'un certificat valide pour le domaine. Les sources publiques ne précisent pas comment les copies étaient servies dans ce cas.
Ce qu'une entreprise non-crypto doit en retenir
Vos clients ne perdront pas de crypto. Mais un nom de domaine détourné peut collecter des mots de passe, des numéros de carte ou des emails pendant des heures. Les protections suivantes s'appliquent à toute organisation.
1. Double authentification sur le compte registrar
C'est la première recommandation publiée par Name.com après l'incident : activer la double authentification et vérifier ses enregistrements DNS. Le compte registrar contrôle les serveurs de noms. Un mot de passe seul ne suffit pas. Vérifiez aussi la procédure de récupération de compte : en avril 2026, l'attaquant d'eth.limo a obtenu l'accès chez easyDNS en se faisant passer pour un membre de l'équipe, via la procédure de récupération.
2. Verrou registrar et Registry Lock
Le verrou de transfert classique (clientTransferProhibited) bloque les transferts, mais il est posé et levé par le registrar. Le Registry Lock va plus loin : le registre lui-même refuse toute modification tant qu'une procédure de déverrouillage hors ligne n'a pas eu lieu. Verisign le propose pour le .com via les registrars participants, l'AFNIC propose .FR Lock pour le .fr. C'est payant et ça ralentit chaque changement : réservez-le aux domaines critiques. Son intérêt : un mot de passe volé sur votre compte client ne suffit plus pour changer les NS, puisque le déverrouillage passe par une vérification hors ligne entre le registre et le registrar.
3. DNSSEC, avec ses limites
DNSSEC signe vos réponses DNS. Un attaquant qui change vos NS sans pouvoir signer à votre place produit des réponses rejetées par les résolveurs qui valident. C'est ce qui a limité les dégâts chez eth.limo : la plupart des utilisateurs ont vu une erreur au lieu du faux site. CircleID rappelle toutefois que DNSSEC ne protège pas forcément contre un attaquant qui contrôle le compte registrar, puisqu'il peut aussi modifier ou retirer l'enregistrement DS. Voir notre guide pour activer DNSSEC selon votre registrar.
4. Une alerte quand vos NS ou vos IP changent
Dans ce cas, la détection est venue d'utilisateurs sur X, plus d'une heure après les premiers vols. Une surveillance qui compare régulièrement vos enregistrements NS, A et MX à une référence vous prévient dès le changement. Vous pouvez faire une vérification ponctuelle avec notre outil DNS lookup.
5. Les logs Certificate Transparency
Chaque certificat émis par une autorité reconnue est publié dans des journaux publics. Un certificat émis pour votre domaine pendant une fenêtre suspecte, par une autorité que vous n'utilisez pas, signale qu'un tiers a contrôlé votre DNS ou votre serveur. Vous pouvez les consulter sur crt.sh.
Pour une vue d'ensemble des techniques, des autres cas connus et des moyens de détection, lisez notre article sur le DNS hijacking.
Domains Defender alerte quand un enregistrement DNS change (NS, A, MX, TXT) et surveille la configuration DNSSEC et le verrou de transfert de vos domaines. Le plan Pro ajoute le suivi des logs Certificate Transparency, qui signale une nouvelle autorité de certification ou un nouveau sous-domaine. Il détecte un changement, il ne le bloque pas. Les détails sont sur la page des plans.
Questions fréquentes
Name.com a-t-il été piraté ?
Ce n'était pas établi au 5 novembre 2026. Name.com a reconnu une activité non autorisée et rétabli les domaines. Plusieurs projets mettent en cause Vercel, revendeur de domaines via Name.com. Aucune analyse de cause officielle n'avait été publiée à cette date.
Combien d'argent a été volé ?
Entre 138 000 dollars (estimation de The Block, hors Solana et Aptos) et 202 386 dollars (Bitquery, présenté comme un minimum). L'écart vient du périmètre compté.
Mon domaine chez Name.com est-il concerné ?
Name.com a demandé à ses clients de vérifier leurs enregistrements DNS et d'activer la double authentification. Comparez vos NS et vos IP actuels à ce que vous avez configuré, et consultez les certificats émis récemment pour votre domaine sur crt.sh.
Un site classique peut-il subir la même attaque ?
Oui. Le mécanisme ne dépend pas de la crypto. Tout site dont le DNS est modifié peut servir une fausse page de connexion ou de paiement à sa propre adresse.