The $11M Vulnerability Class Hiding in ERC-4626 Vaults
How a standardized interface became a standardized attack surface—and why the same exploit keeps draining DeFi protocols.

The $11M Vulnerability Class Hiding in ERC-4626 Vaults
How a standardized interface became a standardized attack surface—and why the same exploit keeps draining DeFi protocols.
The Numbers
Between January 2025 and May 2026, a single class of vulnerability drained over nearly $10.95 million from DeFi protocols:

These aren’t unrelated incidents. They share the same DNA: ERC-4626 vault share price manipulation.
The standard that was supposed to unify DeFi’s vault ecosystem instead created a common attack surface that adversaries exploit with mechanical precision.
Why ERC-4626 Creates a Systemic Risk
ERC-4626 (Tokenized Vault Standard) defines how yield-bearing vaults expose their shares. It standardized the interface—deposit, withdraw, convertToShares, and convertToAssets—so that any protocol could integrate any vault without custom adapters.
The problem is that standardized interfaces create standardized exploit patterns.
Every ERC-4626 vault computes its exchange rate from the same fundamental formula:
sharePrice = totalAssets() / totalSupply()
This ratio becomes the single source of truth for:
- How many shares a depositor receives
- How much collateral a lending protocol credits
- What price an oracle reports to downstream consumers
- Whether a borrower’s position is solvent
When this ratio is corrupted, everything downstream breaks simultaneously.
The Attack Taxonomy
ERC-4626 exploits clusters into three distinct subclasses, each targeting a different layer of the vault integration stack:

- Inflation Attacks
The mechanism: Manipulate totalAssets() by transferring tokens directly to the vault contract, bypassing deposit(). No new shares are minted, so existing shares inflate in value.
Why it works: ERC-4626 vaults typically compute totalAssets() from balanceOf(address(this)). A direct ERC20.transfer() to the vault increases this balance without triggering the share-minting logic.
When it’s catastrophic: When the vault is empty or nearly empty. With totalSupply = 1 (one share), even a modest donation creates an enormous per-share value. The attack cost scales linearly with total supply—an empty vault costs almost nothing to inflate.
2. Oracle Misuse
The mechanism: Downstream protocols (lending markets and liquidation engines) consume the vault’s raw convertToAssets() output as a price oracle—without any temporal smoothing.
**Why it works: **convertToAssets(1e18) returns the current share price at this exact block. If an attacker inflates the share price via donation in the same transaction (or even the same block), the oracle immediately reflects the manipulated value.
**The missing defense: **TWAP (Time-Weighted Average Price) or EMA (Exponential Moving Average) smoothing. These temporal filters resist single-block manipulation because the attacker would need to sustain the inflated price across many blocks, which is prohibitively expensive.
- Interface Implementation Flaws
The mechanism: Developers override standard ERC-4626 functions (withdraw, redeem) to add custom logic but accidentally drop critical safety checks from the base implementation.
Why it works: ERC-4626’s withdraw(assets, receiver, owner) function is designed to allow approved spenders to withdraw on behalf of an owner but only if they have sufficient allowance. The _spendAllowance(owner, caller, shares) check enforces this. When an override drops this check, anyone can burn anyone’s shares.
The Propagation Problem
The most devastating ERC-4626 exploits aren’t vault bugs — they’re composition bugs. The corrupted share price propagates through multiple protocol layers, amplifying at each step:

Each component in isolation might pass review, but the vulnerability only materializes when you trace the full data flow across contract boundaries.
- The vault doesn’t have virtual shares, but it’s low severity—the team will seed it
- The division doesn’t check for zero, but the denominator comes from an oracle
- The solvency check multiplies by the exchange rate, which is always positive
The Fundamental Math Flaw
At its core, every inflation attack exploits the same mathematical property:
sharePrice = totalAssets() / totalSupply()
When totalSupply is small (especially when it is 1), the attacker has direct control over sharePrice by manipulating totalAssets:
Before donation: sharePrice = 1 / 1 = 1
After donation: sharePrice = 2,000,000,000,000,000,000 / 1 = 2e18
OpenZeppelin’s defense adds “virtual” shares and assets that make the denominator always large:
sharePrice = (totalAssets() + 1) / (totalSupply() + 10**decimalsOffset())
With a decimal offset of 3:
Before donation: sharePrice = (1 + 1) / (1 + 1000) = 2/1001 ≈ 0
After donation: sharePrice = (2e18 + 1) / (1 + 1000) ≈ 2e15
The attacker donated 2e18 tokens but only inflated the price to 2e15—a 1000x reduction in effectiveness. The attack becomes unprofitable when the donation cost exceeds the extractable value.
Why This Keeps Happening
Five structural reasons explain why ERC-4626 exploits persist despite being well-documented:
- Teams still roll their own implementations: Even with OpenZeppelin’s battle-tested ERC-4626 available, many protocols continue building custom vault logic without protections like virtual share offsets—either due to lack of awareness of the inflation vector or underestimating its impact.
- The issue is often underestimated in audits: First-depositor inflation is frequently marked as LOW or INFORMATIONAL because teams intend to seed the vault immediately after deployment. In practice, deployment assumptions change, and even a short unseeded window can be exploited.
- Composability turns local bugs into systemic failures: What appears to be a low-severity vault accounting issue can escalate into a protocol-wide critical exploit once manipulated share prices propagate into oracles, collateral valuations, or solvency checks.
- Fresh empty vaults continue to appear: Every new market, collateral asset, or vault deployment introduces another uninitialized ERC-4626 instance vulnerable during its first-depositor phase. The Resupply exploit abused a vault that had gone live only days earlier.
- Custom modifications often break core safety assumptions: Teams overriding ERC-4626 internals for protocol-specific behavior frequently bypass or weaken built-in accounting protections, unintentionally reintroducing inflation attack surfaces.
What’s Next
This article defined the "what"—the vulnerability class, its subtypes, and why it persists. But understanding a vulnerability abstractly is different from seeing it weaponized.
In the next article, we dissect the Resupply Protocol exploit—a vulnerability composition where an attacker chained three individually minor flaws into a single transaction, a $10M drain, starting with nothing but a flash loan and 1 wei of collateral.
Next: *Pulling apart resupply exploit*
This is Part 1 of a three-part series on ERC-4626 vault security. Part 2 covers the Resupply exploit research. Part 3 covers building a static analysis tool to detect this vulnerability class.
메타데이터
- post_id
- 105cb9b4e33c
- slug
- the-11m-vulnerability-class-hiding-in-erc-4626-vaults-105cb9b4e33c
- url
- https://blog.blockmagnates.com/the-11m-vulnerability-class-hiding-in-erc-4626-vaults-105cb9b4e33c
- canonical_url
- https://blog.blockmagnates.com/the-11m-vulnerability-class-hiding-in-erc-4626-vaults-105cb9b4e33c
- author_url
- https://medium.com/@tanu_G
- status
- ok
- fetched_at
- 2026-06-09 15:37:30