Third Time Around, Abracadabra's Deprecated Cauldrons Bleed $1.8 Million to a Two-Line Exploit

Abracadabra has been hit for a third time in under two years, this time losing $1.8 million in MIM tokens to an attacker who needed only two sequential actions to bypass the protocol's solvency check.

The exploit struck on Saturday, October 4, targeting six cauldrons on Ethereum mainnet that the protocol had labeled "deprecated" but never actually disabled. None of these CauldronV4 contracts had been audited since November 2023, yet they remained fully operational and able to mint stablecoins without backing collateral.

01Discovery and disclosure

Security researcher William Li flagged the issue first, on October 4, publishing an early breakdown on social media. BlockSec Phalcon corroborated the finding within hours, noting that the same exploit pattern was being repeated across multiple cauldron addresses. Phalcon's analysis pinned the root cause on the cook() function's shared status tracker, which allowed one action within a batched call to silently overwrite the solvency flag set by another.

Separately, GoPlus Security traced 51 ETH moving into Tornado Cash, while another 344 ETH initially remained sitting in the attacker's wallet.

Abracadabra did not address the incident through its official Twitter account. Instead, the first word came via Discord contributor 0xMerlin, whose message covered the now-familiar checklist: a vulnerability had been found, the DAO treasury was being deployed to buy back the affected MIM, no user funds were lost, and the situation was under control. A public acknowledgment on Twitter didn't follow until two days after the attack, alongside a pause on all cauldron borrowing described as needed "as we review the current codebase for future upcoming deployments." The team also characterized the damage as having "relatively small impact," despite the incident marking the protocol's third exploit in two years and pushing cumulative losses past $21 million, against a reported TVL of $154 million.

02How the exploit worked

CauldronV4's cook() function allows several operations to be bundled into a single transaction. Each operation is assigned an action ID and runs sequentially, with a shared status struct determining whether the contract needs to verify the caller's solvency once the batch completes.

Action 5, ACTION_BORROW, initiates a borrow and sets the flag needsSolvencyCheck to true, which should force a collateral check before the transaction finishes. But Action 0, ACTION_CUSTOM, calls an internal helper called _additionalCookAction() — a function that, despite its name, does nothing more than return a freshly reset CookStatus struct with every field, including the solvency flag, set back to false:

function _additionalCookAction(CookStatus memory, bytes memory) internal pure returns (CookStatus memory) {
    return CookStatus(false);
}

By calling cook() with the action sequence [5, 0] and supplying parameters for a large borrow, the attacker let Action 5 flip the solvency flag to true, only for Action 0 to immediately reset it to false. When the function reached its final check — if (status.needsSolvencyCheck) _ensureSolvent(user); — the flag read false, the check never ran, and the borrow went through unopposed. In total, the attacker withdrew 1,793,755 MIM tokens against zero collateral.

Attacker's address: 0x1AaaDe3e9062d124B7DeB0eD6DDC7055EFA7354d

The same two-step sequence was repeated across six separate cauldrons:

• 0x46f54d434063e5F1a2b2CC6d9AAa657b1B9ff82c
• 0x289424aDD4A1A503870EB475FD8bF1D586b134ED
• 0xce450a23378859fB5157F4C4cCCAf48faA30865B
• 0x40d95C4b34127CF43438a963e7C066156C5b87a3
• 0x6bcd99D6009ac1666b58CB68fB4A50385945CDA2
• 0xC6D3b82f9774Db8F92095b5e4352a8bB8B0dC20d

Attack transaction: 0x842aae91c89a9e5043e64af34f53dc66daf0f033ad8afbf35ef0c93f99a9e5e6

There was no multi-step gymnastics involved. Just two actions, in a specific order, were enough to exploit a logic error that would have been visible to anyone reviewing the contract code directly.

03Tracing the funds

Execution followed a consistent pattern across all six affected cauldrons, and the attacker's initial capital originated from Tornado Cash.

Tornado Cash funding transaction: 0x68437f1f687e3fbe65dd86a802f6ca08b44af3dff612f02c4c8b6945c9dd4f82

Wallet used to route funds from Tornado Cash: 0x1FF8Ea9b29aa10713774b60134D53529301Ca9C5

Primary attacker address: 0x1AaaDe3e9062d124B7DeB0eD6DDC7055EFA7354d

Attack contract (self-destructed): 0xB8e0A4758Df2954063Ca4ba3d094f2d6EdA9B993

Exploited DegenBox contract: 0xd96f48665a1410c0cd669a88898eca36b9fc2cce

Working through the six cauldrons, the attacker minted 1,793,755 MIM with no collateral behind it. Roughly half of that was converted to ETH, then run through the standard laundering sequence of swapping, bridging, and mixing.

51 ETH went into Tornado Cash almost immediately, while 344 ETH stayed in the attacker's wallet for only a few minutes before it, too, was laundered through Tornado Cash across more than three dozen separate transactions.

All Tornado Cash laundering transactions from the attacker's address: 0x1aaade3e9062d124b7deb0ed6ddc7055efa7354d

Abracadabra's DAO treasury subsequently executed a buyback, repurchasing the dumped MIM from the open market and asserting the move had "completely reversed the effect of the attack."

Buyback transaction: 0xbaede1ddbab71fb48d25139e720356d8c487d47ce4b94aaf683969dc1fb1c984

The team's public framing centered on the claim that "no user funds" were lost — a statement that holds only if DAO treasury assets aren't counted as belonging to anyone. Those treasury reserves are, in practice, stakeholder capital that could otherwise have gone toward audits or development rather than covering losses from an avoidable exploit.

04A gap in the audit trail

Abracadabra's public audit history shows repeated attention paid to new features while the core lending contracts went unreviewed.

• November 14, 2023: Guardian Audits reviewed the GMXV2 variant of CauldronV4 — a specialized version of the contract that was itself exploited for $13 million roughly sixteen months later.
• February 6, 2024: LockingMultiRewards audit.
• March 21, 2024: MIMSwap audit.
• December 16, 2024: BoundSpell audit.

Absent from that list is any recent review of the base CauldronV4 logic — the contracts actually processing borrows on Ethereum mainnet, and the same ones marked "deprecated" while remaining live. The last audit of standard CauldronV4 logic dates to November 2023, nearly two years prior to October's incident. In the interval, two other major exploits occurred — $6.5 million in January 2024 and $13 million in March 2025 — yet audit spending continued to favor new modules over the underlying infrastructure.

Code4rena's March 2024 review of MIMSwap identified 20 vulnerabilities, four of them rated high severity. Notably, that review was scoped only to the MIMSwap module and excluded the core CauldronV4 contracts that were later exploited in October 2025 — underscoring a broader pattern of security resources going toward new features rather than the foundational codebase.

A related episode involves Synnax Labs, an Abracadabra fork running the same vulnerable code. PeckShield audited Synnax in November 2024, did not catch the attack vector, reported only two medium- and two low-severity findings, and deemed the protocol secure. Three days ahead of the Abracadabra exploit, Synnax paused its own contracts, citing "security upgrades." Eighteen hours before the attack hit, PeckShield removed its Synnax audit report from GitHub, and Synnax subsequently requested and received a refund for the audit — though the deletion remains visible in the repository's commit history. William Li laid out the full timeline: the audit was published, the shared codebase was exploited, the report was pulled, a refund followed, and neither party commented further.

05Where this leaves the protocol

Between the two forks, warning signs existed in public before the attack: Synnax's precautionary pause came four days early, and PeckShield's report disappeared eighteen hours before the exploit. Abracadabra's own contracts, tagged "deprecated," were left running throughout.

Across three incidents, Abracadabra has now lost roughly $21 million: $6.5 million to a rounding error in January 2024, $13 million to phantom collateral in March 2025, and $1.8 million to a status-flag reset in October 2025. Each incident has been more elementary to execute than the one before it, while the protocol's public response has consistently emphasized treasury buybacks and the argument that DAO funds don't constitute "user" losses.

The protocol's audit records show extensive coverage of new products and comparatively little scrutiny of the mainnet lending contracts that generated three exploits. Even after this latest breach, the announced next step was a codebase review tied to "future upcoming deployments," rather than a dedicated remediation of the contracts already exploited.