Hack GMX : 40M $ Volés par une faille

Le vol de 40 M$ n’était pas aléatoire

J’ai observé le hash de transaction sur Arbitrum : 0x03182d3f0956a91c4e4c8f225bbc7975f9434fab042228c7acdc5ec9a32626ef. L’attaquant n’a pas forcé un coffre — il a exploité avec précision une faille de réentrance dans executeDecreaseOrder. Cette fonction était conçue pour accepter uniquement les adresses EOA. Mais il a transmis une adresse intelligente à la place. Ce n’est pas un bug — c’est une exploitation.

Comment AUM est devenu l’arme

GLP représente des créances proportionnelles sur les actifs : USDC, ETH, WBTC. La formule redeem_amount = (user_GLP / total_GLP_supply) * AUM semble claire — jusqu’à ce que AUM soit manipulé. Normalement, AUM = collatéral total moins pertes non réalisées. Mais quand la levée est activée et des positions courtes ouvertes avant le rachat ? Soudainement, les pertes non réalisées disparaissent — et AUM s’inflate artificiellement.

L’attaquant a ouvert d’immenses positions courtes WBTC juste avant d’appeler unstakeAndRedeemGlp. Le système a recalculé AUM comme si ces positions courtes étaient des profits — pas des expositions. Il a alors racheté du GLP contre une valeur de pool artificiellement gonflée, et s’est enfui avec bien plus que sa part équitable.

Ce n’est pas de l’avare ; c’est une hypothèse défectueuse : traiter les appels non vérifiés comme des entrées EOA fiables, en ignorant la dérive d’état sous levée.

Pourquoi cela se reproduit

Nous avons construit des systèmes sur la confiance, pas la vérification. Nous supposons que les pools de liquidité sont statiques lorsqu’ils sont dynamiques par conception — et nous permettons à la levée d’amplifier le risque sans traces d’audit en temps réel.

La prochaine attaque ne portera pas sur le code — elle portera sur la culture.