How a Reentrant Bug in GMX Cost Over $40M — A Deep Dive into Leveraged GLP Exploitation

The $40M Heist Wasn’t Random

I was reviewing GMX’s transaction logs when I spotted the anomaly: an address that should’ve been an EOA was passed as a smart contract into executeDecreaseOrder. That’s like handing a thief a master key to your vault—not because they cracked encryption, but because the system trusted a fake identity. The attack didn’t require high gas or brute force; it required precision.

AUM: The Invisible Leverage Engine

AUM—the Asset Under Management—wasn’t meant to be dynamic. But here, attackers called unstakeAndRedeemGlp with inflated GLP supply values, tricking the formula: redeem_amount = (user_GLP / total_GLP_supply) * AUM. Since AUM included unrealized losses as positive value, their empty position became a self-fulfilling debt machine. They didn’t steal tokens—they redefined what “value” meant.

Reentrancy Isn’t a Bug—It’s an Feature Misused

The enableLeverage function turned liquid staking into weaponized speculation. When an attacker opened a WBTC short before redemption settled, they locked the pool’s liquidity under their control. The system had no guardrails because it assumed all calls came from trusted addresses—and they weren’t.

Why Zero-Knowledge Proofs Failed Us

We built this stack on trust, not verification. No one audited whether caller identities were EOA or contract-based—until it was too late. This isn’t about hacking; it’s about lazy engineering dressed as innovation.

Final Thought: Trust Is Not a Protocol

I’m not mad—I’m disappointed. We optimized for yield without security audits because we confused elegance with safety. Next time? Verify every call at the root level—or lose more than $40M again.