Abracadabra.money was exploited for roughly $1.8 million when a logic flaw in its cook() batching function allowed an attacker to borrow MIM (Magic Internet Money) tokens from multiple Cauldrons without collateral.
A virtual hook reset a solvency flag inside the same transaction, so the end-of-transaction check never ran. Six Cauldrons were drained; stolen MIM was swapped to ETH and then moved through Tornado Cash.
Initial Overview
Abracadabra users deposit collateral into Cauldrons to borrow MIM, the protocol’s stablecoin. Cauldrons handle the borrowing logic, while funds are held in a shared vault called DegenBox.
Abracadabra’s cook() function batches multiple actions into a single transaction. A bug in how cook()’s auxiliary action hook was implemented created a vulnerability where an attacker could bypass the post-transaction solvency check and withdraw borrowed MIM with no collateral.
Attack Vector Explained
The root cause was a vulnerability in the Abracadabra smart contract’s cook() function.
During cook(), Action 5 (borrow) sets needsSolvencyCheck = true to enforce a solvency check at the end of the batch.
However, the cook() function also supports a faulty hook that is declared virtual. The base implementation returns default values (all booleans default to false, including needsSolvencyCheck). This bug was never overridden in the vulnerable Cauldrons.
By calling action sequence [5, 0] (borrow then the virtual action), the attacker caused the hook to reset the needsSolvencyCheck flag to false. The end-of-transaction solvency check never ran, and the attacker kept the borrowed MIM without providing collateral.
MIM Hack Timeline
The attack was executed in a single transaction that iterated through six vulnerable Cauldrons, borrowing the maximum available MIM on each.
The attacker immediately swapped the 1.79M MIM for 395 ETH.
Within minutes, the attacker began splitting and moving funds to Tornado Cash. 46 deposits total were executed gradually over ~22 hours to obfuscate the trail: 39 × 10 ETH, 5 × 1 ETH, 2 × 0.1 ETH.
Extractor by Hacken detected the incident by flagging abnormal activity and an unusually large MIM withdrawal from DegenBox. Its alert breakdown showed a total of about 1.79 million MIM withdrawn during the attack.
Possible Vulnerability in Abracadabra Forks
Synnax runs a forked version of Abracadaba’s protocol on the SEI chain. Three days before the MIM hack, Synnax paused operations by unwhitelisting a CauldronV4 master on DegenBox.
Any fork that retains the same virtual hook pattern without implementing the auxiliary action safely should be assumed at risk until patched.
Lessons Learned
- Avoid unsafe virtual defaults for security-critical flags. Don’t rely on default virtual functions to preserve security invariants. If a hook can influence a post-transaction check, the base implementation must preserve the invariant, or the function must be final or explicitly handled.
- Implement explicit post-condition checks. Make sure solvency and similar safety checks can’t be flipped inside the same transaction by operating on immutable transaction snapshots or performing checks in code paths that cannot be modified by user-supplied hooks.
- Audit batching mechanisms carefully. Batch convenience features increase the attack surface. Audits and formal verification should target all possible action sequences.
- Execute multiple independent security reviews. Audits from more than one third-party reduce the chance of a common oversight. Encourage red-team style testing that tries unusual action orderings.
- Implement onchain monitoring & automated response. On-chain anomaly detection (e.g., large uncollateralized borrows, sudden DegenBox outflows) coupled with automated throttles/pauses can limit damage while teams triage.
- Maintain appropriate fork hygiene. When running forked protocol logic, never assume inherited safety. Re-run all audits and threat models, and pay attention to virtual/override semantics and default behaviors in the new environment.
- Deploy rapid mitigation systems. Prepare governance and operations procedures to pause systems or de-whitelist masters on shared vaults, so a patch or mitigation can be applied immediately when a systemic risk is identified.
