In-Depth Analysis: USR De-anchoring and Morpho Vault Flash Loan NAV Manipulation Attack

On March 22, 2026, the Resolv protocol experienced a private key leak, allowing an attacker to mint 80 million uncollateralized USR out of thin air, causing USR’s price 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 world is divided into two layers:

Lower 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, interest rate model.

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

Upper 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 per Share (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 accrues, totalAssets grow but totalSupply remains unchanged, so NAV per share increases — this is how you earn money.

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

This is the first key point of the attack.

In Morpho Blue, the supply() function has an onBehalf parameter. This design was intended for third-party payments — for example, automated strategy contracts depositing 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 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 would be like “donating” to the vault — you’re increasing the earnings for all shareholders at your own expense, which is foolish. But under certain conditions, this can be exploited.

3. Supply Cap = 0 ≠ Safe

After USR de-pegged, some vault managers hurriedly set the USR/USDC market’s Supply Cap to 0, 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 restriction.

The vault manager can only control the vault’s internal _supplyMorpho() function.

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

To use an analogy: the vault manager closed the front door (Cap=0), but an attacker used the back door in Morpho Core to inject funds directly.

4. Hardcoded Oracle — The Hidden Armor of Bad Debt

This is the second critical condition.

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

Why did the vault manager use a fixed oracle? Because USR is a “stablecoin,” with normally small price fluctuations. A fixed oracle avoids false liquidations caused by short-term liquidity issues.

But when USR truly de-pegged, a fixed oracle became a disaster — borrowers could use worthless USR as collateral to borrow full USDC amounts, and the protocol would remain unaware.

Morpho’s bad debt handling mechanisms fail here — the real-time reflection in V1.0 and the amortization in V1.1 both rely on the protocol being able to recognize bad debt.

With a fixed oracle, nothing can be recognized.

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

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

6. Why Is a Flash Loan Necessary?

This is the most overlooked question. The attack’s profit comes from “artificially inflating totalAssets and distributing the increase proportionally to shares.” Without a flash loan, the attacker holds 0% of shares — even if totalAssets are increased sky-high, the gains go to other shareholders, and the attacker gets nothing.

7. Who Loses Money?

The extra 12,300 USDC taken by the attacker didn’t appear out of thin air. This money came 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. USDC in the USR market has already been borrowed out, so it cannot be withdrawn. The funds come from other markets — e.g., wETH/USDC, cbBTC/USDC, and other functioning markets.

8. The Superposition of Three Vulnerabilities

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

Conclusion

Morpho’s minimalist design philosophy — permissionless, non-upgradable, minimal governance — is advantageous most of the time. But this incident shows that the cost of minimalism is shifting greater responsibility onto upper-layer participants.

The protocol does not perform oracle validation; administrators must do it themselves. It does not restrict supply(onBehalf); the vault layer must implement additional protections.

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