Échanger 200 000 contre près d’un milliard, les stablecoins DeFi à nouveau attaqués

Écrit par : Eric, Foresight News

Vers 10h21, heure de Beijing, Resolv Labs, qui utilise une stratégie delta neutre pour émettre la stablecoin USR, a été victime d’une attaque par un hacker. L’adresse commençant par 0x04A2 a utilisé 100 000 USDC pour frapper le protocole Resolv Labs, ce qui a permis de créer 50 millions d’USR.

Suite à la révélation de l’incident, le prix de l’USR a chuté à environ 0,25 dollar, puis est remonté à environ 0,8 dollar au moment de la rédaction. La valeur du jeton RESOLV a également connu une baisse maximale proche de 10 % à court terme.

Par la suite, le hacker a répété la manœuvre, utilisant encore 100 000 USDC pour frapper 30 millions d’USR. Avec le dérapage massif de l’USR, les traders d’arbitrage ont rapidement réagi. De nombreux marchés de prêt supportant USR, wstUSR et autres comme collatéral sur Morpho ont été presque vidés, et la DAO Lista sur BNB Chain a suspendu les nouvelles demandes de prêt.

Les protocoles de prêt affectés ne se limitent pas à cela. Dans la conception du protocole Resolv Labs, les utilisateurs peuvent également frapper une autre cryptomonnaie, le RLP, dont la valeur fluctue davantage, avec des rendements plus élevés, mais qui implique une responsabilité en cas de pertes pour l’utilisateur. Actuellement, la circulation du RLP approche les 30 millions, le plus gros détenteur étant Stream Finance avec plus de 13 millions, exposant un risque net d’environ 17 millions de dollars.

Effectivement, Stream Finance, qui avait déjà subi un effondrement avec xUSD, pourrait à nouveau subir une attaque.

Au moment de la rédaction, le hacker a converti l’USR en USDC et USDT, et continue d’acheter de l’ETH, ayant déjà acquis plus de 10 000 ETH. Avec 200 000 USDC, il a échangé contre plus de 20 millions de dollars d’actifs, trouvant dans le marché baissier une « pièce à cent fois » pour lui.

Encore une fois, une faille due à un manque de rigueur

Le 11 octobre de l’année dernière, une chute brutale a entraîné la perte de collatéral pour de nombreux stablecoins émis via des stratégies delta neutres, notamment à cause de l’auto-désendettement (ADL). Certains projets utilisant des altcoins comme actifs de stratégie ont subi des pertes plus graves, allant jusqu’à la faillite.

Cette fois, Resolv Labs, qui a également utilisé un mécanisme similaire pour émettre l’USR, avait annoncé en avril 2025 avoir levé 10 millions de dollars lors d’un financement initial mené par Cyber.Fund et Maven11, avec la participation de Coinbase Ventures, et avait lancé le jeton RESOLV fin mai ou début juin.

Mais la cause de l’attaque n’est pas une situation de marché extrême, mais plutôt une conception « insuffisamment rigoureuse » du mécanisme de frappe de l’USR.

Aucune société de sécurité ou officiel n’a encore analysé les causes de cette attaque. La communauté DeFi, via YAM, a conclu après une analyse préliminaire que l’attaque est probablement due à la prise de contrôle par le hacker du SERVICE_ROLE, qui fournit les paramètres pour le contrat de frappe.

Selon Grok, lors de la frappe d’USR, l’utilisateur envoie une requête sur la blockchain en appelant la fonction requestMint du contrat, avec des paramètres tels que :

_depositTokenAddress : l’adresse du token déposé ;

_amount : la quantité déposée ;

_minMintAmount : le montant minimum d’USR attendu (pour éviter le slippage).

Ensuite, l’utilisateur dépose USDC ou USDT dans le contrat, le backend du projet, via le SERVICE_ROLE, surveille la requête, utilise l’oracle Pyth pour vérifier la valeur des actifs déposés, puis appelle les fonctions completeMint ou completeSwap pour déterminer la quantité réelle d’USR à frapper.

Le problème réside dans le fait que le contrat de frappe fait entièrement confiance au _mintAmount fourni par SERVICE_ROLE, supposant que ce chiffre a été vérifié hors chaîne par Pyth, sans limiter la valeur, ni effectuer une vérification supplémentaire via un oracle sur la chaîne, et exécute directement mint(_mintAmount).

Selon YAM, le hacker aurait contrôlé le SERVICE_ROLE, qui devrait normalement être sous le contrôle du projet (peut-être en raison d’un oracle interne défaillant, d’un vol de clé ou d’une compromission), et aurait fixé le _mintAmount à 50 millions, permettant ainsi de frapper 50 millions d’USR avec 100 000 USDC.

En résumé, Grok conclut que Resolv n’a pas anticipé que l’adresse (ou le contrat) recevant la demande de frappe pourrait être contrôlée par un hacker. Lors de la soumission de la requête de frappe, aucune limite maximale n’a été fixée, et aucune vérification supplémentaire via un oracle n’a été effectuée, ce qui a permis au hacker de faire confiance à tous les paramètres fournis par SERVICE_ROLE.

La prévention est également insuffisante

Outre l’analyse des causes de l’intrusion, YAM souligne que le projet n’était pas suffisamment préparé à faire face à une crise.

Sur X, YAM indique que Resolv Labs n’a suspendu le protocole que trois heures après la première attaque, un délai d’environ une heure étant dû à la collecte des signatures nécessaires pour une transaction multisignature. YAM pense qu’une suspension d’urgence devrait pouvoir être effectuée avec une seule signature, et que cette autorité devrait être confiée à des membres de l’équipe ou à des opérateurs externes de confiance, afin d’accroître la vigilance sur les anomalies on-chain, et de pouvoir réagir rapidement.

Bien que cette recommandation d’une suspension avec une seule signature soit un peu radicale, il est vrai qu’attendre plusieurs signatures à travers différents fuseaux horaires pourrait retarder une réaction critique en cas d’urgence. L’introduction d’un tiers de confiance, capable de surveiller en continu le comportement on-chain, ou l’utilisation d’outils de surveillance avec droits d’urgence, sont autant de leçons tirées de cet incident.

Les attaques contre les protocoles DeFi ne se limitent pas aux vulnérabilités de contrat. L’incident de Resolv Labs rappelle aux projets que, dans la conception de la sécurité, aucune étape ne doit être considérée comme totalement fiable. Tous les paramètres impliqués doivent faire l’objet d’au moins une vérification secondaire, y compris par des backends gérés par le projet lui-même.