Aller au contenu
Fondé MMXXVIVol. VI · № 273RSS
Blockchain Breaches

Archive des incidents de sécurité dans les cryptomonnaies — piratages, exploits, défaillances de ponts et rug pulls, documentés avec des preuves on-chain.

Dossier № 259Attaque par flash loan

Vidage de Makina via MachineShareOracle

4,13 M$ extraits du pool Curve DUSD/USDC de Makina via manipulation d'oracle par prêt flash ; négociation white-hat a récupéré 89% en une semaine.

Date
Victime
Makina
Chaîne(s)
Statut
Partiellement récupéré

Le 20 janvier 2026, le protocole on-chain de rendement et de gestion d'actifs Makina a perdu environ 4,13 millions de dollars lorsqu'un attaquant a manipulé le MachineShareOracle qui rapportait les prix des parts au pool stableswap Curve Dialectic USD (DUSD) / USDC. L'attaquant a utilisé 280 millions de dollars en prêts flash avec 170 millions déployés spécifiquement pour déplacer la lecture de l'oracle. Après négociation white-hat sous la politique SafeHarbor, 89% des utilisateurs affectés ont vu leurs fonds entièrement récupérés en une semaine.

Ce qui s'est passé

Makina exploitait des « Machines » — des coffres automatisés de gestion de rendement qui s'intégraient à des protocoles DeFi externes (Curve, Aave, autres) pour déployer le capital des utilisateurs. Le prix des parts de chaque Machine était calculé via un MachineShareOracle qui rapportait les actifs sous gestion au pool Curve où les utilisateurs fournissaient la liquidité.

La faille fatale : le calcul AUM du MachineShareOracle lisait l'état des pools depuis des intégrations Curve externes sans validation. En manipulant l'état du pool externe, un attaquant pouvait pousser le prix rapporté par l'oracle vers des valeurs incorrectes — ce qui affectait ensuite la façon dont le pool Curve de Makina valorisait les dépôts et retraits des utilisateurs.

L'attaque :

  1. Prise d'un prêt flash de 280 M USDC.
  2. Déploiement d'environ 170 M$ dans les pools Curve que le MachineShareOracle lisait, distordant l'état du pool pour gonfler artificiellement l'AUM que Makina rapporterait.
  3. Le MachineShareOracle a rapporté l'AUM gonflé, poussant le prix des parts du pool Curve DUSD/USDC vers le haut.
  4. Dépôt et retrait immédiat de positions Makina au prix des parts gonflé, extrayant plus qu'il n'avait mis.
  5. Remboursement du prêt flash et départ avec environ 4,13 M$ de profit.

Conséquences

  • L'équipe Makina a activé le « mode sécurité » sur toutes les Machines, mettant les opérations en pause pour éviter d'autres pertes.
  • Conseillé aux LP de retirer en mono-actif vers DUSD depuis le pool affecté pendant la remédiation.
  • L'équipe a pris des instantanés on-chain pré-exploit pour les calculs de compensation.
  • Coordonné avec SEAL911, ChainSecurity, EnigmaDarkLabs et Cantina pour la revue d'incident.
  • A proposé à l'attaquant une prime de 10% (jusqu'à 102,3 ETH) via la politique SafeHarbor WhiteHat.
  • L'attaquant a accepté l'offre : plus de 3,65 M$ ont été récupérés et 89% des utilisateurs ont été entièrement indemnisés en une semaine.
  • Le protocole a repris pleinement ses opérations normales le 26 janvier 2026 — seulement six jours après l'exploit.

Pourquoi c'est important

L'incident Makina est l'un des cas de 2026 les plus nets pour montrer comment un processus de réponse aux incidents bien architecturé peut convertir un exploit significatif en un événement opérationnel contenu. La politique SafeHarbor WhiteHat que Makina avait pré-engagée — incluant la structure de prime et les termes de protection légale — fournissait à l'attaquant un chemin crédible vers une résolution white-hat, qu'il a emprunté.

Les leçons structurelles :

  1. Les politiques de style SafeHarbor valent de plus en plus la peine d'être pré-engagées plutôt que négociées au milieu d'un incident. Le choix de l'attaquant entre « blanchir 4 M$ avec risque de poursuites » et « accepter une prime de 400 K$ avec protection contre les poursuites » est significativement orienté quand la politique est clairement documentée et prête à exécuter plutôt qu'improvisée.

  2. Les intégrations d'oracle avec des pools externes doivent valider contre la manipulation — le mode de défaillance du MachineShareOracle de Makina consistait à lire l'état du pool sans considérer que le pool était externe et manipulable. Les schémas défensifs modernes incluent la lecture depuis plusieurs pools, l'application d'agrégation pondérée dans le temps et le plafonnement du mouvement d'oracle par bloc.

  3. La chronologie « exploit à récupération complète » de 6 jours est l'une des plus rapides documentées pour un incident DeFi de plus de 4 M$. La combinaison d'un processus clair pré-construit, d'un chemin white-hat fonctionnel et de partenaires engagés en réponse aux incidents (SEAL911 et al.) a rendu cela possible. Les protocoles qui ne pré-disposent pas de ces capacités prennent des semaines ou des mois pour des résultats similaires.

Makina rejoint la catégorie croissante 2025-2026 des « exploits à échelle moyenne, récupération rapide via white-hat négocié » — un schéma qui devient le chemin de règlement dominant pour les incidents dans la fourchette de 1 M$ à 20 M$.

Sources & preuves on-chain

  1. [01]decrypt.cohttps://decrypt.co/355132/ethereum-defi-platform-makina-hit-by-flash-loan-exploit-loses-4m-in-eth
  2. [02]medium.comhttps://medium.com/coinmonks/makinas-4m-hack-8afca700c00c
  3. [03]quillaudits.comhttps://www.quillaudits.com/blog/hack-analysis/makina-4m-hack-explained

Dépôts liés