CryptoReal
CASE FILE — Dec 18, 2025

A Six-Day-Old Oracle Patch Let an Attacker Drain Aevo's Legacy Ribbon Vaults for $2.7M

EP By Elena Petrova Dec 18, 2025 7 min read

On December 12, Aevo's dormant Ribbon Finance vaults lost $2.7 million — not to some novel cryptographic break, but to a routine oracle configuration change that had quietly stripped access controls from the vaults six days earlier. Once discovered, the flaw let the attacker instruct the price oracle to report arbitrary, wildly inflated asset values, and the contracts simply complied.

Anton Cheng, a former Opyn developer, characterized the incident not as neglected legacy code but as a case where an incremental upgrade undid protections that had been deliberately built in earlier.

01Background: a merger, then a maintenance patch

Ribbon Finance was one of the earliest DeFi options protocols. In July 2023, its DAO voted to fold the project into Aevo, merging the brands and absorbing Ribbon's structured-product vaults into Aevo's broader platform. The governance proposal framed this as folding Ribbon into Aevo's suite of structured products — rebranding the existing Ethereum vaults and positioning them as the Layer-1 pillar of Aevo's "DeFi Super-App" strategy. It was billed as a unification, not a wind-down.

That rebrand didn't make the underlying contracts any more resilient. On December 6, Aevo's team deployed an upgrade to the oracle configuration used by the legacy Ribbon vaults, apparently intended as routine operational maintenance. In practice, the change left the price-feed proxy contracts exposed, with sensitive functions — including transferOwnership and setImplementation — carrying no access restrictions whatsoever.

The exposed contracts sat untouched for six days until, on December 12, someone found them.

Specter identified the exploit contract and tracked the initial outflows well before Aevo made any public statement. Aevo itself didn't confirm the incident until roughly 19 hours after the attack began, when it acknowledged that the legacy vaults had been "exploited following a vulnerability in a smart contract update."

02How the exploit worked

Researcher Liyi Zhou and Anton Cheng both published breakdowns of the attack mechanics.

The attack opened with a setup transaction in which the attacker minted an options product that mismatched its components: collateral denominated in wstETH, paired with AAVE as the underlying reference asset. Under Opyn's original Gamma protocol logic — which Ribbon's options infrastructure is built on — this combination should have been rejected, since Gamma enforces strict collateral-matching rules. Opyn's core code was not at fault; Ribbon's upgraded configuration simply failed to enforce those same rules. William Li's analysis found that the misconfiguration effectively let the attacker whitelist arbitrary option products as if they were legitimate.

The larger problem was in the price-feed proxies themselves. The oracle upgrade created a decimal mismatch between old and new parts of the system: the new configuration assumed 18-decimal precision, while a number of older listed assets still used 8 decimals. Compounding this, the proxy oracle stack contained an access-control gap that let anyone set the expiry price for newly created assets.

According to Halborn's writeup, the attacker weaponized the decimal gap directly: they constructed options with strike prices set far below real market value by deliberately mixing 18-decimal and 8-decimal assets. As one example, the attacker created an stETH call option carrying an 8-decimal-denominated strike price of 3,800 USDC, collateralized with 18-decimal WETH, and minted oTokens against it.

When those options expired on December 12, the mismatched decimal logic caused the system to read stETH's value as vastly higher than the 3,800 USDC strike. The attacker repeated this pattern to extract funds cheaply — in one case, burning just 225 oTokens yielded roughly 22.46 WETH — and cycled the process until the vaults were drained. Notably, the underlying Opyn protocol logic executed exactly as designed; it was Ribbon's own configuration that created the exploitable condition.

03Anatomy of the operation

On-chain analysis from Specter points to a coordinated operation rather than a single actor, with distinct wallets handling distinct roles across four phases.

Phase 1 — Preparation. A funding wallet, referred to here as the Mastermind, financed the operation's infrastructure without directly touching the exploit itself:

A second wallet, the "Specialist," built the mismatched options contract used to exploit the decimal gap:

A third wallet, the "Engineer," deployed the malicious oracle logic:

Sums referenced in this case file

A fourth wallet, the "Bagman," was the contract that ultimately interacted with the vault to receive stolen assets:

A fifth wallet — referred to as the "Fall Guy" — played a distinct setup role: it built a track record of ordinary, legitimate-looking transactions (whitelisting collateral, deploying a clean oracle) to establish an appearance of normal, compliant activity before the attack:

The effect was that when the malicious sequence finally executed, it appeared to the protocol as activity from an already-trusted party rather than a new adversary.

Phase 2 — Taking control of the oracle. Liyi Zhou identified the mechanism used to seize the oracle: a contract that repeatedly called the Proxy Admin to invoke transferOwnership and setImplementation at will.

Technical review of the Proxy Admin found the root defect: transferOwnership never verified which contract was making the call — it only checked for a permission flag against tx.origin. The "Fall Guy" wallet already held that flag from its earlier setup activity, meaning the system granted access not because it was overwhelmed, but because it recognized the caller as already-authorized.

Using an attack contract as a proxy, the attacker ran a looping script that abused this access repeatedly: for each targeted asset, it swapped the oracle's implementation to the malicious contract, forced an arbitrary price update, then swapped back to the legitimate implementation to obscure the intrusion.

In this single transaction, the AAVE price was set to an effectively infinite value, and the expiry timestamp was pinned to 1765526400 (December 12, 2025).

Phase 3 — Extraction. With prices manipulated and the timeline locked in, the Bagman contract began withdrawing funds. In the main drain transaction, it burned the mismatched oTokens to force a payout of 846 WETH and 178,000 USDC from the affected vault.

Phase 4 — Moving the funds. The stolen assets were then routed to a distributor wallet, which redistributed them across a set of additional addresses in uniform batches of 100.1 ETH (split as 99 + 1 + 0.1), apparently in preparation for use of Tornado Cash.

The organized, evenly-batched movement of funds suggests planning rather than an improvised cash-out.

04Aevo's response, and a reversed compensation plan

Once the exploit was public, Aevo decommissioned all Ribbon vaults rather than attempt a fix. The announcement tweet was later deleted, along with a subsequent post outlining a compensation plan that drew significant criticism before being withdrawn.

That initial plan would have let users withdraw funds subject to a 19% reduction relative to the value their position held at the time of the hack. Two elements underpinned the proposal: first, the Ribbon DAO would forfeit its own vault holdings — around $400,000 in assets — to help offset losses, though this covered only a portion of the $2.7 million shortfall. Second, the protocol noted that many of its largest depositors had been inactive for two to four years, effectively betting that these long-dormant accounts would never resurface to claim reimbursement.

That plan did not hold. Ribbon subsequently issued a correction, acknowledging that its original analysis had been "fundamentally flawed." The revised position removed the proposed haircut and replaced it with a binary outcome: depositors who had already queued a withdrawal before the exploit would be made whole, while those whose funds remained "active" in the vault at the time of the attack could lose them entirely.

05Context: a recurring pattern with legacy vaults

Aevo's incident follows a pattern also seen at Yearn and Balancer, where older, technically "deprecated" vaults remained funded and exploitable long after active development had moved elsewhere.

Ribbon's contracts had passed a 2021 security audit from OpenZeppelin, which tested the original Ribbon V2 logic thoroughly against the threat models of its time. That audit offered no protection against a 2025 maintenance change that introduced a new class of vulnerability into the same codebase — the years of prior hardening were effectively bypassed by a single configuration update.

The broader lesson pointed to by the incident: labeling a vault "deprecated" or "legacy" does not reduce the actual risk it carries so long as it still holds user funds and retains privileged, upgradeable components. As protocols shift attention and resources toward newer deployments — Layer 2s, v3 iterations, and similar — older contracts holding real value but receiving little ongoing scrutiny remain an open target.

AevoRibbon Finance
Investigation alerts

Get new scam files the moment we publish them — usually 2–3 emails a week.

Enter a valid email address.

No spam, unsubscribe anytime. We never sell your data. Crypto assets are volatile and high-risk; nothing here is financial advice.

You're on the list. Watch your inbox for the next scam file.