Oracle Price Manipulation Nets Sturdy Finance Attacker $800K

Sturdy Finance, an Ethereum lending protocol that lets yield farmers borrow against deposited staked-asset collateral, was drained of approximately $800,000 through a price manipulation attack.

Ancilia first raised the alarm, and Sturdy Finance's team quickly confirmed the incident: "We are aware of the reported exploit of the Sturdy protocol. All markets have been paused; no additional funds are at risk and no user actions are required at this time."

Ancilia pointed out that the technique closely resembled attacks previously seen against Midas Capital and dForce Network — a recurring vulnerability class that keeps resurfacing across the space.

The exploit relied on a flash loan to distort the pricing feed of Sturdy's own SturdyOracle, tricking it into reporting a false valuation for the B-stETH-STABLE collateral token. BlockSec published a full breakdown of the attack sequence.

The attacker operated from address 0x1e8419e724d51e87f78e222d935fbbdeb631a08b, deploying an attack contract at 0x0b09c86260c12294e3b967f0d523b4b2bcdfbeab that had been built with front-running protection baked in. The core exploit transaction can be found here.

The roughly 442 ETH (about $800k) in profit went straight into Tornado Cash — laundering was complete within 20 minutes of the funds first being received from the same source address.

The underlying flaw is a read-only reentrancy issue that has surfaced repeatedly over roughly the past year. Back in February, a Balancer forum post had already flagged certain Balancer pools as exposed to this exact vector — including the specific pools that ended up targeted here.

Sturdy had gone through three separate audits — from Certik, Quantstamp, and Code4rena — making it notable that a known exploit pattern still got through.

Edit, February 6, 2024: Quantstamp clarified that the LendingPool contract version containing the vulnerability fell outside their audit's scope; the leaderboard has since been corrected to reflect this.

The incident has renewed debate around designing lending systems that don't depend on oracles at all, a concept gaining traction in the wake of repeated oracle-based exploits — though some proposed alternatives may ultimately still need oracles of their own to function.