In-Depth Analysis: Morpho Vault Flash Loan NAV Manipulation Attack After USR Depegging

Written by: Spinach Spinach

On March 22, 2026, the Resolv protocol experienced a private key leak, allowing attackers to mint 80 million uncollateralized USR out of thin air, causing USR to plummet from $1 to $0.025.

The aftermath of this disaster didn’t just affect USR holders; a smarter group executed a sophisticated vault NAV manipulation attack on Morpho.

This article will break down the underlying logic of this attack step by step.

1. Understanding Morpho’s Two-Layer Architecture

Before discussing the attack, you must understand Morpho’s architecture design, or else the subsequent explanation will be incomprehensible.

Morpho’s ecosystem is divided into two layers:

Bottom Layer:

Morpho Blue (also called Morpho Core). This is a minimalist, non-upgradable lending protocol. Its design philosophy is “permissionless” — anyone can create a lending market, deposit, borrow, and liquidate.

Each market is uniquely identified by five parameters: loan asset, collateral asset, liquidation line (LLTV), oracle address, and interest rate model.

Markets are completely isolated; an issue in one market does not affect others.

Top Layer:

MetaMorpho Vault (the vault). This is an ERC-4626 standard vault, akin to a “fund product.”

Users deposit USDC into the vault, and the vault manager (Curator) allocates these funds across different Morpho Blue markets to lend and earn interest.

Users hold vault shares, whose value increases as interest accrues.

Core Formula — Net Asset Value (NAV / Price Per Share):
Net Asset Value per share = totalAssets / totalSupply

totalAssets is the sum of all the vault’s supply positions across markets (including borrowed amounts, as they are “accounts receivable”).
totalSupply is the total number of shares issued by the vault.
As interest accumulates, totalAssets grow while totalSupply remains unchanged, causing NAV per share to increase — this is how you profit.

2. supply(onBehalf) — Anyone Can Inject Funds on Behalf of the Vault

This is the first key point of the attack.

In Morpho Blue, the supply() function includes an onBehalf parameter. This design was intended for third-party payments — for example, automated strategy contracts depositing funds on behalf of users.

But it is permissionless: anyone can specify any address as onBehalf, including the vault address.

Morpho’s official documentation explicitly warns:
“Warning: Anyone can supply on behalf of the vault so the call to updateWithdrawQueue that expects a market to be empty can be griefed by a front-run.”

When you supply 10,000 USDC on behalf of the vault, the vault’s supply position in that market increases by 10,000, and totalAssets also increases by 10,000. But the vault’s total shares (totalSupply) do not change — because no one deposited new funds via deposit().

Result: the NAV per share is artificially inflated.

Normally, this is akin to “donating” to the vault — you’re increasing earnings for all shareholders at your own expense, which is foolish. But under certain conditions, this can be exploited.

3. Supply Cap = 0 ≠ Safety

After USR lost its peg, some vault managers hurriedly set the USR/USDC market’s Supply Cap to zero, meaning no more funds could be added to that market. Sounds like the problem was solved?

The issue is: Supply Cap is a vault-level restriction, not a Morpho Blue core-level restriction.

Vault managers can only control the internal function _supplyMorpho() within the vault.

But supply(onBehalf=vault) interacts directly with the Morpho Blue core contract, bypassing all vault-level logic: supply queue, supply cap, allocator permissions, etc.

To illustrate: the vault manager closes the front door (Cap=0), but an attacker can still directly deposit funds through Morpho Core’s back door.

4. Hardcoded Oracle — The Invisible Cloak of Bad Debt

This is the second critical condition.

The USR/USDC market’s oracle is fixed at a 1:1 ratio. That is, regardless of how much USR drops externally, within Morpho’s system, 1 USR always equals 1 USDC.

Why did vault managers use a fixed oracle? Because USR is a “stablecoin,” with normally small price fluctuations. Fixed oracles prevent “fake liquidations” caused by short-term liquidity shortages.

But when USR truly depegs, a fixed oracle becomes a disaster — borrowers can use worthless USR as collateral to borrow substantial USDC, and the protocol remains unaware.

Morpho’s bad debt handling mechanisms (real-time reflection in V1.0 and amortization in V1.1) rely on the protocol’s ability to recognize bad debt.

With a fixed oracle, nothing can be detected.

5. Full Attack Flow — A Five-Step Atomic Loop

Now all conditions are in place. The following is an atomic sequence of operations completed within a single transaction:

[Note: The original text seems to have omitted the detailed steps here, but the core idea is that the attacker uses the above vulnerabilities to artificially inflate totalAssets, then exploits the NAV increase to extract value.]

6. Why Are Flash Loans Essential?

This is a commonly overlooked point. The attack profits from “artificially increasing totalAssets and distributing the gains proportionally.” If the attacker does not use a flash loan, they hold 0% of the vault shares — even if totalAssets are inflated, the gains go to other shareholders, and they get nothing.

Therefore, flash loans are critical to quickly and cheaply manipulate totalAssets without risking their own capital.

7. Who Loses Money?

The extra 12,300 USDC the attacker siphons off didn’t appear out of thin air. It comes from the vault’s real liquidity in other healthy markets.

When the vault redeems, it pulls USDC from various markets in order of the withdraw queue. Since the USR market’s USDC has been borrowed out, it cannot supply funds. The redemption funds are drawn from other markets — e.g., wETH/USDC, cbBTC/USDC, and other functioning markets.

8. The Cumulative Effect of Three Vulnerabilities

This attack isn’t caused by a single flaw but by the combination of three design issues:

Conclusion

Morpho’s minimalist philosophy — permissionless, non-upgradable, minimal governance — is advantageous in most cases. But this incident shows that minimalism comes with greater responsibility for upper-layer participants.

The protocol does not verify oracles; administrators must do so themselves. It does not restrict supply(onBehalf); vaults need additional safeguards.

For depositors, choosing the right Curator is more important than choosing Morpho itself. The protocol is a tool; whether it’s safe depends on how it’s used.