La même vulnérabilité. La même cible. La deuxième attaque en moins de 30 jours.
RetoSwap — la plateforme de trading pair-à-pair basée sur Monero — a de nouveau suspendu d'urgence tous les échanges après avoir annoncé que le protocole de trading Haveno sur lequel elle fonctionne est activement exploité. L'équipe a confirmé la suspension le 17 juin 2026, en portant la version client minimale à 2.0.0 et en bannissant les adresses onion des attaquants — la même réponse d'urgence utilisée lors de la première attaque le 20 mai 2026.
Source : X (anciennement Twitter)
RetoSwap a été clair sur un point : sa propre infrastructure n'a pas été compromise. La vulnérabilité se trouve dans le protocole Haveno — le framework de trading open source sur lequel RetoSwap est construit. L'équipe n'a pas écrit le code vulnérable. Elle l'a hérité.
Cette distinction est importante. Elle ne restaure pas les fonds.
Pour comprendre la suspension du 17 juin, il faut avoir en mémoire l'incident du 20 mai.
Le 20 mai 2026, le développeur principal de Haveno, woodser, a signalé que le protocole de trading Haveno était activement exploité. En moins de deux minutes — à 4h33 CET — RetoSwap a banni l'adresse onion de l'attaquant et suspendu le trading en fixant la version client minimale à 2.0.0 via la fonction de filtrage.
L'attaque a entraîné le vol de 7 000 XMR, d'une valeur d'environ 2,7 millions de dollars. L'analyste on-chain PeckShield a confirmé la violation.
Le mécanisme technique derrière l'exploit était sophistiqué. L'attaquant a envoyé un faux message d'accusé de réception hors séquence en se faisant passer pour l'arbitre — une partie tierce neutre dans le système de portefeuille multi-signatures 2-sur-3 de Haveno. Cela a conduit le logiciel client de la victime à écraser l'adresse de nœud de l'arbitre légitime avec celle du hacker. Le logiciel de la victime a ensuite collecté les clés du portefeuille, dont l'une provenait du faux nœud arbitre de l'attaquant. Le hacker a obtenu 2 des 3 clés du portefeuille avant même que les fonds de la victime ne soient déposés dans le portefeuille multi-signatures.
En termes simples : l'attaquant s'est fait passer pour l'arbitre avant le début de la partie — et a truqué le résultat avant que le moindre argent ne soit mis en jeu.
L'impact a principalement touché les transactions en cryptomonnaies de grande valeur. Les parties effectuant des échanges en monnaie fiduciaire n'ont pas été affectées. Ce n'était pas un hasard. L'attaquant a cartographié l'architecture du protocole, identifié la voie spécifique gérant les échanges de tokens en gros volumes, et l'a ciblée avec précision.
RetoSwap ne détient pas les fonds des utilisateurs. Les traders opèrent directement depuis des portefeuilles locaux au lieu de déposer des actifs sur un compte centralisé. Mais cette conception non-custodiale n'a fourni aucune protection ici — l'exploit s'est produit au niveau de la couche protocole, et non au niveau de la couche plateforme.
La suspension du 17 juin confirme ce que l'attaque du 20 mai laissait entendre : la vulnérabilité n'avait pas été entièrement résolue.
Le correctif appliqué après le 20 mai — mise à niveau obligatoire vers la version client 2.0.0 et bannissement de l'adresse de l'attaquant — a stoppé la violation active. Le développeur Haveno woodser a identifié la prévention comme étant simple : vérifier que le portefeuille multi-signatures est déjà créé avant de mettre à jour l'adresse de l'arbitre. Une pull request GitHub a été ouverte pour traiter ce problème. Mais l'incident du 17 juin montre que les attaquants ont trouvé un moyen d'exploiter à nouveau le protocole — que ce soit via un nouveau vecteur ou une exposition résiduelle dans la même vulnérabilité.
RetoSwap a confirmé le 17 juin que les pertes semblent limitées aux transactions de crypto-actifs de grande valeur. Les traders en monnaie fiduciaire n'ont une fois de plus pas été affectés. L'équipe a indiqué qu'elle évalue les options pour aider les traders touchés à récupérer leurs fonds et que le trading ne reprendra qu'une fois le protocole corrigé — cette fois sans délai annoncé.
Les options de récupération dans l'écosystème XMR relèvent en grande partie de la formalité. La conception axée sur la confidentialité de Monero — la même caractéristique qui lui donne de la valeur — rend les XMR volés pratiquement impossibles à tracer ou à récupérer. PeckShield peut signaler l'incident. Les fonds, une fois déplacés, sont effectivement perdus.
C'est là la tension centrale de toute cette histoire. La confidentialité qui protège les utilisateurs légitimes de Monero protège tout aussi bien les attaquants une fois le vol accompli.
Si vous utilisez RetoSwap ou toute plateforme construite sur Haveno, voici les étapes vérifiées issues des communications officielles de RetoSwap.
Étape une — sauvegardez immédiatement votre dossier de portefeuille. RetoSwap a confirmé que les utilisateurs affectés auront besoin de leur sauvegarde locale de portefeuille pour tout plan de récupération potentiel. Les emplacements des dossiers sont :
Linux : ~/.local/share/Haveno-reto/xmr_mainnet/wallet
macOS : ~/Library/Application Support/Haveno-reto/xmr_mainnet/wallet
Étape deux — n'essayez pas de trader avant que le correctif du protocole ne soit confirmé. Le trading reste suspendu au 17 juin 2026. Toute nouvelle transaction tentée via un client non mis à jour risque d'exposer l'utilisateur à la même attaque de spoofing d'arbitre multi-signatures.
Étape trois — mettez à jour vers la version client 2.0.0 minimum avant la réouverture de la plateforme. RetoSwap a fixé cette version comme version minimale autorisée. Les utilisateurs fonctionnant sur des versions antérieures doivent effectuer la mise à jour avant la reprise du trading.
Étape quatre — vérifiez les communications de l'arbitre lors de tout trade P2P. Vérifiez toujours les détails du trade et les communications de l'arbitre sur toute plateforme P2P. Soyez prudent avec les plateformes construites sur des protocoles open source qui n'ont pas fait l'objet d'audits de sécurité indépendants complets — la sécurité d'un projet forké n'est jamais plus solide que le code le moins audité dans sa chaîne de dépendances en amont.
La leçon plus large des incidents de mai et de juin est précise. RetoSwap n'a pas écrit le code vulnérable. Il l'a hérité — comme tout projet forké hérite des bugs, des angles morts et des zones non auditées de ce sur quoi il est construit. Les utilisateurs de toute plateforme construite sur Haveno font face au même risque hérité jusqu'à ce que le protocole central reçoive un audit indépendant complet.
Le protocole Haveno a désormais été exploité deux fois en moins de 30 jours. La propre infrastructure de RetoSwap n'a été compromise ni l'une ni l'autre fois — mais le protocole dont elle dépend l'a été. L'attaque de mai a coûté aux utilisateurs 7 000 XMR d'une valeur de 2,7 millions de dollars. La suspension du 17 juin suggère que les attaquants ont trouvé la même porte encore ouverte. Le trading reprendra lorsque le protocole sera corrigé. Sauvegardez votre dossier de portefeuille maintenant. Ne tradez pas avant que le correctif ne soit confirmé.
Cet article est fourni à titre informatif et éducatif uniquement. Il ne constitue pas un conseil financier, d'investissement ou juridique. Toutes les données relatives aux incidents proviennent du compte X officiel de RetoSwap et de sources publiques vérifiées au 17 juin 2026. Les pertes liées à l'attaque du 17 juin sont encore en cours d'évaluation — les chiffres pourront être mis à jour au fur et à mesure que de nouvelles informations seront disponibles. Tous les chiffres relatifs aux actifs de l'incident de mai sont vérifiés auprès de plusieurs sources nommées. Effectuez toujours vos propres recherches indépendantes et consultez un conseiller en sécurité ou en finance qualifié avant d'utiliser toute plateforme de trading décentralisée.


