In March 2025, Abracadabra Money suffered its second major hack in a little over a year. The protocol was hacked for approximately $6.5 million in January 2024, and the latest hack netted twice as much — an estimated $13 million in ETH.
Inside the Attack
The latest hack of Abracadabra Money exploited state tracking errors within the protocols “cauldrons”. The attacker exploited the vulnerability via a multi-stage attack:
The attack began with a deposit into GMX that was designed to fail, causing them to stay in the OrderAgent contract, awaiting a claimant.
Next, the attacker borrowed funds, pushing their own position into liquidation. This is followed by a self-liquidation, causing the contract to wipe the position. However, the order and associated collateral remain within the contract.
Finally, they took out a loan using the liquidated position as collateral.
Since the attacker successfully removed both their initial deposit from the system and took out a loan, they have no reason to repay this bad loan. As a result, 6,260 ETH, worth an estimated $13 million, was stolen from the protocol. After taking out the bad loan on Arbitrum, the attacker bridged the stolen funds to Ethereum.
After acknowledging the incident, Abracadabra announced a 20% bounty on the stolen funds. They also claimed that they had the funds required to cover half of the damage immediately and more over the coming months. Additionally, plans to expand to new chains remain unchanged.
Lessons Learned from the Attack
The Abracadabra hack demonstrates how complexity within a DeFi protocol can introduce additional security risks. The vulnerable cauldrons exploited by the attacker were integrated with GMX, and the attacker took advantage of errors in how state was tracked for these interactions. A failed deposit to GMX created a situation where an attacker could self-liquidate their position and still be able to take out a bad loan using the now non-existent collateral.
This type of issue is best identified via invariant testing, which performs a fuzz test against a smart contract’s functions. By sending various random inputs, the tester can hopefully trigger any potential error cases like this one, enabling them to be addressed before deployment.
Managing smart contract security risks requires a wide range of smart contract tests, from validating business logic to fuzz testing to identify niche vulnerabilities. For help in securing your smart contracts against attack, reach out to Halborn.