Tu n'as pas acheté de rsETH mais ton WETH est gelé.

Introduction

Points clés :

• Quatre attaques détectées entre le 13 et le 19 avril 2026, impliquant plusieurs blockchains telles qu’Ethereum, Unichain, Arbitrum et NEAR, avec une perte estimée d’environ 310 millions de dollars.

• Les vecteurs d’attaque incluent la toxification de l’infrastructure RPC pour LayerZero DVN, la falsification de preuves MMR, l’abus d’entiers signés dans le fonds d’assurance, et l’exploitation de chemins d’échange circulaires dans les protocoles de trading à marge.

• L’incident KelpDAO (290 millions de dollars) montre que la sécurité des ponts cross-chain dépasse la couche des contrats intelligents, s’étendant à l’infrastructure de validation hors chaîne. La mise en gel en cascade de WETH sur cinq chaînes et la conversion forcée d’état sur Arbitrum révèlent comment la composabilité peut amplifier le point unique de défaillance, et où se situe réellement la frontière de confiance d’un système “décentralisé”.

Au cours de la semaine passée (13/04/2026 - 19/04/2026), BlockSec a détecté et analysé quatre incidents, avec une perte totale estimée à environ 310 millions de dollars. Le tableau ci-dessous résume ces événements, et les sections suivantes fourniront une analyse détaillée de chacun.

Tableau 1 : Aperçu des quatre incidents détectés cette semaine

Points clés de la semaine : KelpDAO

Cet incident a été choisi comme point fort de la semaine en raison de ses nouveaux vecteurs d’attaque d’infrastructure (toxification RPC unique pour DVN, plutôt que vulnérabilités de contrats intelligents), de ses effets en cascade multi-chaînes via la composabilité DeFi, et des problèmes de gouvernance liés à l’exécution d’une conversion d’état forcée pour récupérer des fonds volés par Arbitrum.

Le 18 avril 2026, le pont cross-chain rsETH LayerZero OFT de KelpDAO a été attaqué, avec une perte d’environ 290 millions de dollars. LayerZero Labs a attribué cette attaque à un acteur soutenu par un État, probablement le groupe Lazarus de Corée du Nord [1]. La cause fondamentale est la configuration DVN 1-of-1 de KelpDAO, qui réduit la validation des messages cross-chain à un point de défaillance unique. L’attaquant a toxifié l’infrastructure RPC de confiance de LayerZero Labs, forçant la signature d’une preuve de message cross-chain falsifiée, ce qui a permis de libérer 116 500 rsETH sur Ethereum, alors qu’aucun événement d’envoi correspondant n’a été enregistré sur la chaîne source Unichain.

Contexte

LayerZero est un protocole de messagerie cross-chain basé sur une architecture modulaire de sécurité. Son intégrité des messages cross-chain repose sur un réseau décentralisé de validateurs (DVN), qui sont des entités hors chaîne responsables de vérifier indépendamment que les messages envoyés depuis la chaîne source ont bien été émis, avant de permettre leur exécution sur la chaîne cible. Chaque application déployée sur LayerZero configure elle-même son DVN, en choisissant quels DVN faire confiance, combien doivent participer, et le seuil de consensus. Ce modèle modulaire donne aux applications un contrôle total sur leur sécurité, mais implique aussi une responsabilité totale : une configuration faible ne peut pas être compensée par le protocole lui-même.

Le rsETH de KelpDAO, déployé comme OFT (Token Fongible Inter-Chain) sur LayerZero, relie Unichain (chaîne source) et Ethereum Mainnet (chaîne cible). La norme OFT permet de détruire le token sur la chaîne source et de le libérer sur la chaîne cible à partir d’un dépôt verrouillé, la seule autorisation étant la transmission du message cross-chain. Sur Ethereum, l’adaptateur (0x85d456…e98ef3) est responsable de libérer rsETH au destinataire après validation et transmission du message. La configuration critique est que KelpDAO a configuré cette voie en mode 1-of-1 DVN, en désignant LayerZero Labs comme seul validateur. Cela signifie qu’un seul preuve DVN suffit pour autoriser la libération de n’importe quel token, sans confirmation tierce.

Pour remplir sa fonction de validation, le DVN de LayerZero Labs interroge plusieurs nœuds RPC pour confirmer que l’événement d’envoi a bien eu lieu sur la chaîne source. Ces nœuds incluent des infrastructures auto-opérées et des fournisseurs externes, et le DVN dépend de leur réponse collective pour signer la preuve. L’intégrité de ce processus repose sur l’hypothèse que la majorité des nœuds interrogés renverront des données authentiques.

Analyse de la vulnérabilité

Cette vulnérabilité résulte d’un échec systémique au niveau de l’infrastructure et de la configuration, constitué de trois faiblesses cumulatives.

Première faiblesse : la configuration 1-of-1 du DVN de KelpDAO élimine toute redondance au niveau de la validation. La configuration recommandée par LayerZero exige plusieurs DVN indépendants, utilisant des validateurs séparés, pour éviter qu’un seul DVN puisse valider seul un message. En ne s’appuyant que sur le DVN de LayerZero Labs, KelpDAO garantit qu’une seule compromission suffit à autoriser la libération de n’importe quel token.

Deuxième faiblesse : le mécanisme de basculement du DVN redirige les requêtes vers n’importe quel nœud RPC accessible. Ce design suppose que la défaillance d’un nœud est accidentelle, pas intentionnelle. Cependant, cela crée une condition où un attaquant n’a pas besoin de compromettre toutes les sources : en lançant un DDoS pour faire tomber les nœuds sains, et en préparant un nœud toxifié comme seule source accessible, il peut contrôler totalement les données reçues par le DVN.

Troisième faiblesse : le remplacement du fichier exécutable op-geth sur le nœud RPC nécessite un accès OS au serveur sous-jacent. La vectorisation initiale précise n’a pas été divulguée, mais la compromission de deux nœuds situés dans des clusters indépendants indique que la sécurité de ces serveurs présente des failles communes.

Ces trois conditions forment ensemble une chaîne d’attaque complète : la première empêche tout DVN indépendant de valider seul un message falsifié, la deuxième permet à l’attaquant de contrôler totalement les données reçues par le DVN unique, et la troisième fournit le point d’entrée initial pour manipuler ces données. Aucun de ces faiblesses pris isolément ne suffit. Sans configuration 1-of-1, le second DVN d’une infrastructure indépendante rejettera la falsification. Sans basculement, les nœuds sains rejetteront la toxification. Sans compromission du serveur, l’attaquant ne pourra pas injecter de fausses données.

Analyse de l’attaque

L’analyse suivante se base sur la transaction 0x1ae232…4222 et la déclaration officielle de LayerZero Labs.

Étape 1 : l’attaquant obtient la liste des nœuds RPC de confiance du DVN de LayerZero Labs. Cette liste constitue une cible de haute valeur, car connaître précisément ces nœuds permet de planifier des opérations ciblées, plutôt qu’une attaque infrastructurelle large.

Étape 2 : l’attaquant obtient les droits d’écriture OS sur deux nœuds RPC, et remplace le binaire op-geth en cours d’exécution par une version malveillante. Ces deux nœuds tournent dans des clusters indépendants, ce qui suggère que la vectorisation initiale implique une dépendance commune (par exemple, des identifiants de déploiement compromis, une chaîne CI/CD, ou une attaque d’ingénierie sociale contre des opérateurs ayant accès aux deux).

LayerZero Labs n’a pas divulgué la méthode exacte d’accès initial. Cette étape est la condition préalable à toute manipulation ultérieure des données.

Étape 3 : le binaire malveillant implémente une logique de réponse ciblée : il ne renvoie des données falsifiées qu’aux IPs du DVN, tout en fournissant des états blockchain authentiques à tous les autres requérants, y compris l’infrastructure de surveillance de LayerZero, les explorateurs et scanners. Cette toxification sélective rend l’attaque invisible pour tous les systèmes d’observation ; de l’extérieur, la chaîne source semble fonctionner normalement.

Étape 4 : le consensus interne du DVN exige que les nœuds toxifiés et non compromis parviennent à un accord. Pour résoudre ce conflit, l’attaquant lance un DDoS sur les nœuds sains durant la fenêtre d’attaque (10h20-11h40 heure du Pacifique), déclenchant la logique de basculement du DVN, qui dépend entièrement de l’infrastructure toxifiée. Cette étape est cruciale : sinon, les nœuds sains renverraient des données authentiques en contradiction avec la réponse falsifiée.

Étape 5 : le DVN, recevant désormais uniquement des données contrôlées par l’attaquant, présente un message cross-chain falsifié comme valide. La preuve sur Ethereum indique un nonce 308, alors que sur Unichain, aucun événement de sortie correspondant n’a été enregistré (le nonce sortant maximal sur la source est 307).

Étape 6 : l’adaptateur rsETH sur Ethereum, après validation de la preuve, libère 116 500 rsETH à l’adresse du receveur contrôlée par l’attaquant (0x8b1b6c…0d3b), qui avait été préalablement alimentée via Tornado Cash. Les tokens volés sont dispersés dans sept portefeuilles, puis convertis via Aave, échangés contre ETH, et transférés cross-chain vers Arbitrum pour liquidation, avec des fonds finissant dans des adresses consolidées sur Ethereum (0x5d3919…7ccc) et Arbitrum.

Étape 7 : le binaire malveillant, après exécution, déclenche une auto-destruction, supprimant ses fichiers et logs locaux. Cela complique considérablement la récupération post-incident, témoignant du haut niveau d’opération de l’attaquant.

Étape 8 : l’attaquant tente de réitérer la même opération pour voler 40 000 rsETH supplémentaires (~95 millions de dollars), mais est stoppé lorsque KelpDAO détecte l’anomalie et suspend tous les contrats liés sur Ethereum et les L2 [2].

Impact plus large

Les dommages dépassent largement la faille initiale du pont LayerZero $290M . L’attaquant a déposé environ 89 567 rsETH (~221 millions de dollars) dans plusieurs marchés Aave, en prêtant à un LTV de 93% en mode E, en utilisant rsETH comme collatéral toxique. Comme Aave ne peut pas distinguer sur la chaîne entre rsETH légitime et tokens libérés via la falsification, ces collatéraux “toxiques” sont considérés comme valides. La suspension des réserves WETH s’est propagée d’Ethereum vers Arbitrum, Base, Mantle et Linea, affectant des utilisateurs n’ayant jamais touché à rsETH. Cette cascade, du défaut de configuration d’un seul pont à l’interruption de marchés DeFi multi-chaînes, illustre comment la composabilité peut amplifier l’impact et le coût d’un point de défaillance unique.

Les développements ultérieurs ont aussi soulevé des questions sur la réalité d’une gouvernance décentralisée. LayerZero Labs a annoncé que leur DVN ne signerait plus pour des applications configurées en mode 1-of-1 [4], ce qui montre que la décentralisation au niveau du protocole ne suffit pas à compenser une faiblesse de configuration au niveau applicatif.

Au niveau chaîne, le Conseil de sécurité d’Arbitrum a lancé une opération d’urgence, gelant 30 766 ETH détenus par l’attaquant sur Arbitrum One. Selon BlockSec [1], cette opération a été réalisée via une conversion d’état forcée : le Conseil a temporairement mis à jour le contrat inbox d’Ethereum, injectant un message L1 non signé simulant l’attaque, puis a restauré le contrat d’origine, sans nécessiter la signature du détenteur [5].

Ce geste, légitime dans le cadre d’un pouvoir d’urgence défini par la gouvernance, a été effectué en toute transparence après coordination avec les autorités. Mais il montre aussi que la chaîne L2 conserve une capacité d’intervention centralisée : en principe, tout actif sur Arbitrum One pourrait être déplacé par le Conseil via ce mécanisme. Comme chaque couche le révèle, la différence entre le modèle de confiance théorique et ses limites réelles est la principale source de risque.

Conclusion

Cet incident montre que la sécurité des ponts cross-chain ne peut se réduire à la seule correction du protocole. Le protocole LayerZero fonctionne comme prévu ; la vulnérabilité réside entièrement dans la couche opérationnelle. La leçon clé est que l’infrastructure de validation hors chaîne fait partie de la frontière de confiance, et sa sécurité doit correspondre à la valeur qu’elle protège.

Trois mesures d’atténuation, même prises séparément, auraient pu prévenir cet incident :

• Configuration multi-DVN : exiger plusieurs DVN indépendants pour atteindre un consensus, rendant insuffisante la compromission d’un seul DVN pour valider un message.

• Sélection RPC sensible à la défaillance : en cas de réduction soudaine des nœuds accessibles durant la fenêtre de validation, cela doit être considéré comme un signal d’attaque, pas une simple indisponibilité. La mise en œuvre doit prévoir une suspension ou une alerte en cas de réduction du nombre de nœuds actifs, plutôt que de continuer à fonctionner avec un sous-ensemble.

• Renforcement de l’infrastructure RPC : la capacité à remplacer le fichier exécutable en production indique une faiblesse dans le contrôle d’accès du serveur sous-jacent. L’infrastructure utilisée pour obtenir l’état réel de la chaîne source doit bénéficier d’un même niveau de sécurité que la clé de signature du DVN.

De façon plus large, tout pont ou protocole cross-chain basé sur une preuve hors chaîne doit être audité non seulement au niveau des contrats, mais aussi de l’ensemble du pipeline de données depuis l’événement source jusqu’à l’exécution sur la chaîne cible. Lorsqu’une valeur de plusieurs centaines de millions de dollars dépend de l’infrastructure RPC, la confiance implicite dans sa fiabilité n’est plus justifiée.

Références

[3] LayerZero Labs, “Déclaration d’incident KelpDAO”, 20 avril 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[1] KelpDAO, “Contexte supplémentaire du 18 avril”, 21 avril 2026. https://x.com/KelpDAO/status/2046332070277091807

[2] Arbitrum, “Action d’urgence du Conseil de sécurité”, 21 avril 2026. https://x.com/arbitrum/status/2046435443680346189

[3] LlamaRisk, “Rapport d’incident rsETH”, 20 avril 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[4] BlockSec, “Analyse du mécanisme de gel du Conseil de sécurité d’Arbitrum”, 21 avril 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

Autres incidents de cette semaine

Hyperbridge
Le 13 avril 2026, Hyperbridge, un pont cross-chain basé sur Ethereum, a été attaqué en raison d’un manque de vérification d’entrée dans la logique de preuve MMR (Merkle Mountain Range), entraînant une perte d’environ 242 000 $. La fonction MerkleMountainRange.VerifyProof[5]( ne force pas la vérification que leaf_index < leafCount, permettant à l’attaquant de falsifier une preuve cross-chain et d’exécuter des opérations privilégiées, notamment la création de 1 milliard de DOT.

) Contexte

Hyperbridge utilise un modèle de validateurs et de planificateurs côté Ethereum pour traiter les messages cross-chain. Sur Ethereum, le contrat HandlerV1 vérifie la preuve fournie contre un overlayRoot stocké, et si la vérification est acceptée, il distribue le message à un module cible, comme TokenGateway.

TokenGateway est un module de gestion d’actifs privilégiés. Outre le pontage classique, il supporte des opérations de gouvernance telles que la création, la suppression d’actifs, et la gestion des administrateurs. Pour les actifs de pontage conformes à ERC6160Ext20, l’administrateur peut transférer directement le contrôle de la création via changeAdmin###(, et le nouveau admin peut minter n’importe quelle quantité de tokens via mint)(.

Cela signifie que la sécurité de tout le pont d’actifs dépend de la vérification de preuve dans HandlerV1. Si un message falsifié passe la vérification, le module en aval considérera la commande comme authentique.

) Analyse de la vulnérabilité

Le problème central réside dans la fonction HandlerV1 (0x6c84ed…6d64), en particulier dans la vérification de la preuve MMR. La fonction handlePostRequests###( construit d’abord un objet MmrLeaf) à partir des entrées de l’attaquant, notamment en utilisant leaf.kIndex, leaf.index, et commitment(. Ensuite, elle appelle VerifyProof)( pour valider la preuve.

Mais VerifyProof) ne vérifie que si root == CalculateRoot(, leaves, mmrSize), sans s’assurer que chaque leaf.index est dans la plage valide (leaf.index < leafCount). En choisissant leafCount=1 et leaf_index=1, l’attaquant fait en sorte que CalculateRoot() saute la validation de la demande falsifiée, et retourne directement le root attendu. Cela brise le lien entre le message et la preuve, permettant à tout payload de passer sous le nom d’un état historique légitime.

Figure : extrait de code de VerifyProof montrant l’absence de vérification de leaf_index

( Analyse de l’attaque

Basée sur la transaction 0x240aeb…1109 et la déclaration officielle de LayerZero Labs.

Étape 1 : l’attaquant, EOA 0xC513…F8E7, déploie deux contrats auxiliaires 0x518A…8f26 et 0x31a1…ca9AB dans la même transaction.

Étape 2 : le contrat 0x31a1…ca9AB utilise la faille dans handlePostRequests)( pour soumettre une requête falsifiée. La vérification VerifyProof)###, ne rejetant pas un leaf_index hors limite, accepte la demande falsifiée, qui est exclue du calcul du root mais correspond toujours à l’état historique attendu.

Étape 3 : le message falsifié est distribué à TokenGateway, qui exécute changeAdmin[1](, transférant le contrôle de DOT à l’attaquant.

Étape 4 : le contrat auxiliaire minte 1 milliard de DOT.

Étape 5 : le contrat auxiliaire échange ces DOT contre 108,2 ETH via Odos Router V3.

Étape 6 : l’attaquant transfère 108,2 ETH à son EOA.

) Conclusion

L’incident résulte d’une erreur dans la logique de vérification de preuve dans Hyperbridge. L’absence de vérification que leaf_index < leafCount permet à un attaquant de falsifier un message qui n’a jamais été inclus dans le Merkle Mountain Range, mais qui passe la vérification de l’état historique. La solution consiste à ajouter une vérification stricte de la borne de leaf_index avant de valider la preuve, pour assurer que chaque feuille est dans la plage attendue.

Références

BlockSec, “Analyse de l’attaque Hyperbridge”, 13 avril 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango
Le 13 avril 2026, Dango, un DEX perpétuel construit sur Cosmos AppChain, a été attaqué en raison d’un manque de vérification de la symbolique, avec une perte d’environ 1,5 million de dollars. La fonction replenish_insurance_fund[1]( utilise is_non_zero)( plutôt que is_positive)( pour valider le montant d’entrée, permettant à l’attaquant de fournir une valeur négative de UsdValue et de transférer des fonds de l’assurance vers sa position de marge.

) Contexte

Dango est un DEX perpétuel sur Cosmos AppChain. Les utilisateurs déposent USDC comme collatéral dans un contrat perpétuel, et ouvrent des positions longues ou courtes avec levier sur des actifs comme BTC, ETH, SOL via un carnet d’ordres centralisé on-chain. Le solde de collatéral de chaque utilisateur est suivi dans un compte de marge dans le contrat.

Pour protéger les LP contre la perte irrécouvrable, le protocole maintient un fonds d’assurance : une réserve en USDC dans le contrat perpétuel, qui couvre les déficits en cas de liquidation lorsque la valeur du collatéral est insuffisante pour couvrir la dette. Sans ce fonds, les déficits seraient répartis entre LP. Tout utilisateur peut faire un don au fonds d’assurance depuis son compte de marge.

Analyse de la vulnérabilité

Le problème principal réside dans la fonction replenish_insurance_fund###( du contrat 0x90bc84…bea4f, qui ne rejette pas les montants négatifs. La fonction comporte deux vérifications, mais aucune ne bloque une valeur négative :

• ensure!)amount.is_non_zero(() vérifie que le montant n’est pas zéro, mais pas qu’il est positif.

• ensure!)user_state.margin >= amount( vérifie que l’utilisateur a suffisamment de marge, mais tout montant positif satisfait cette condition même s’il est négatif.

Après ces vérifications, la fonction exécute user_state.margin.checked_sub_assign)amount( et state.insurance_fund.checked_add_assign)amount(. Si amount est négatif, cela augmente la marge de l’utilisateur et réduit le fonds d’assurance, inversant la logique attendue.

![])https://img-cdn.gateio.im/social/moments-bfbc4f9ac0-5d013c5828-8b7abd-badf29(

Figure : vérification manquante de la symbolique dans replenish_insurance_fund

) Analyse de l’attaque

Transaction :

Phase 1 :

Dans la transaction 1, l’attaquant vole des fonds du fonds d’assurance en effectuant :

Étape 1 : dépôt de 1 million USDC pour ouvrir une position de marge. C’est la condition préalable pour appeler replenish_insurance_fund###(.

![])https://img-cdn.gateio.im/social/moments-5ad24912d0-4401c4b1da-8b7abd-badf29(

Figure : suivi de la transaction d’ouverture de position avec dépôt USDC

Étape 2 : appel de replenish_insurance_fund)( avec un montant négatif (-1,5 million). La validation incorrecte accepte cette valeur, transférant des fonds du fonds d’assurance vers la position de marge de l’attaquant.

Étape 3 : l’attaquant retire tout le solde de la position, obtenant 1,5 million de USDC.

![])https://img-cdn.gateio.im/social/moments-981929548c-dd4d29a21b-8b7abd-badf29(

Figure : suivi de la transaction de retrait des fonds volés

Phase 2 :

Dans les transactions 2 à 8, l’attaquant utilise transfer_remote)( pour transférer les fonds volés vers Ethereum. Au final, 410 000 $ USDC sont bridgés vers Ethereum.

) Conclusion

L’attaque repose sur l’utilisation d’entiers signés dans un contexte non signé, et l’absence de vérification de la symbolique. La variable UsdValue est conçue comme signée (car le PnL perpétuel peut être négatif), mais la voie de don à l’assurance ne considère que les valeurs positives. L’utilisation de is_non_zero###( plutôt que is_positive)( laisse une faiblesse : tout appelant peut inverser la direction du flux, transférant USDC de l’assurance vers la marge. L’attaquant a réalisé toute l’opération en une seule transaction (dépôt de 1, transfert de 1,5 million, retrait de 1 500 001), puis a lentement bridgeé les fonds. La limitation par le taux de bridge est la seule barrière à la perte totale, qui serait irréversiblement transférée sur Ethereum.

Rhea Finance
Le 16 avril 2026, Rhea Finance, sur NEAR, a été attaqué via son protocole de prêt et de trading à marge Burrowland, en raison d’un défaut dans la logique métier du module de marge, avec une perte d’environ 18,4 millions de dollars. Lors de l’ouverture d’une position à levier, le protocole utilise verify_token_out)( pour valider la sortie attendue de l’échange. Mais cette fonction additionne incorrectement le montant token_out dans l’étape intermédiaire, sans tenir compte du fait que ces montants sont ensuite réutilisés comme token_in dans une boucle, créant un effet d’auto-augmentation. L’attaquant déploie de faux tokens et pools, construit un chemin circulaire, gonfle la valeur perçue de la sortie, et passe la vérification de capacité, pour extraire environ 18,4 millions de dollars.

) Contexte

Burrowland est un protocole open-source de prêt et de trading à marge sur NEAR. Outre le prêt classique, il supporte le trading à marge, avec trois variables clés pour représenter la position : token_c (collatéral), token_d (actif emprunté), et token_p (actif de la position).

Pour une position longue, l’utilisateur dépose token_c en collatéral, et emprunte token_d avec levier (par exemple 5x). Le token_d emprunté est échangé sur un DEX contre token_p, que l’utilisateur souhaite exposer. En théorie, la valeur de token_p reçue doit être proche de celle de token_d dépensé. Le protocole détient token_p pour l’utilisateur, tout en enregistrant la dette en token_d.

Pour une position courte, l’utilisateur dépose token_c, emprunte token_d (l’actif qu’il veut short), et échange ce token contre un autre, créant une exposition short sur token_d. La valeur échangée doit rester cohérente en théorie.

Tout au long de la position, token_p est détenu par le protocole, et l’utilisateur ne peut pas le retirer directement. La clôture de la position permet de réaliser gains ou pertes, en échangeant token_p contre token_d pour rembourser la dette.

L’ouverture de position à marge est gérée par internal_margin_open_position###(, qui configure la position et distribue le prêt à un DEX.

![])https://img-cdn.gateio.im/social/moments-084491e5bb-d203f16753-8b7abd-badf29(

Figure : configuration de internal_margin_open_position

Avant que le protocole n’accepte la nouvelle position, il évalue en ordre quatre protections : is_min_amount_out_reasonable)( compare le min_token_p_amount déclaré par l’utilisateur avec la sortie d’échange implicite par Pyth, pour limiter le slippage ; is_open_position_liquidatable)( vérifie que la valeur de la position et du collatéral dépasse le seuil de liquidation ; is_open_position_forcecloseable)( vérifie que le compte n’est pas en déficit ; et get_open_position_lr)( impose que le ratio token_d/token_c ne dépasse pas le levier maximal.

Toutes ces vérifications utilisent min_token_p_amount comme valeur de l’actif de la position, car l’échange n’a pas encore été effectué, et aucune somme réelle n’est disponible. La validité de chaque étape dépend donc de la relation entre min_token_p_amount et la quantité réellement livrée par le DEX. Cette relation doit être assurée par verify_token_out)(, qui doit s’exécuter sur le message d’échange soumis par l’utilisateur.

![])https://img-cdn.gateio.im/social/moments-5d0de6737a-27b31cb2f8-8b7abd-badf29(

Figure : verify_token_out et vérification de la capacité de remboursement

) Analyse de la vulnérabilité

Le défaut réside dans verify_token_out(). La fonction prend le dernier token_out de l’étape d’échange, et additionne tous les min_amount_out déclarés pour chaque étape produisant le même token_out, en supposant que chaque sortie contribue au total. Cela est correct pour un échange multi-chemins (split routing), mais ne vérifie pas si ces sorties sont immédiatement consommées dans la suite, c’est-à-dire si elles sont réutilisées comme token_in dans une étape suivante. Un chemin circulaire (A->B->A->B) peut faire que chaque étape B->A soit comptabilisée, même si ses tokens sont consommés dans la prochaine étape, et ne parviennent jamais à Burrowland. La somme min_amount_out validée ne représente plus la quantité réellement retournée par le DEX.

![]###https://img-cdn.gateio.im/social/moments-2cf6bed575-bf31deedff-8b7abd-badf29(

Figure : code de verify_token_out

![])https://img-cdn.gateio.im/social/moments-1c4737e761-6f8a15577b-8b7abd-badf29(

Figure : erreur dans get_token_out avec la logique d’addition défectueuse

Une fois verify_token_out)( contournée, le min_token_p_amount gonflé est considéré comme la valeur réelle dans internal_margin_open_position)(. Toutes les vérifications de capacité de remboursement qui s’appuient sur cette valeur sont faussées, et la position est acceptée, avec le token_d distribué au pool de référence, en dépit d’un gonflement artificiel.

Les développeurs de contrats de trading à marge doivent :

• considérer min_amount_out déclaré comme une entrée non vérifiée, en ne prenant en compte que la dernière étape, ou en refusant explicitement la réutilisation des sorties précédentes (pas de boucle circulaire).

• utiliser une limite supérieure ou inférieure implicite via une oracle pour fixer une enveloppe de slippage, empêchant un attaquant de gonfler artificiellement la déclaration pour passer la vérification de capacité.

Ce défaut permet à un attaquant de gonfler la valeur déclarée, et de faire accepter une position non sécurisée, en exploitant la dépendance à la valeur gonflée dans la vérification de capacité.