Written by: Spinach Spinach

On March 22, 2026, the Resolv protocol experienced a private key leak, with attackers minting 80 million unsecured USR, causing USR to plummet from $1 to $0.025.

The aftermath of this disaster did not just affect USR holders, a group of smarter individuals executed a sophisticated vault NAV manipulation attack on Morpho.

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

1. First, understand Morpho’s two-layer architecture

Before discussing the attack, you must first understand the architecture of Morpho; otherwise, the following content will be incomprehensible.

The world of Morpho is divided into two layers:

Lower Layer:

Morpho Blue (also known as Morpho Core).This is a minimal, non-upgradable lending protocol. Its design philosophy is "permissionless" -- anyone can create lending markets, and anyone can deposit, borrow, and liquidate.

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

Markets are completely isolated; one market's issues do not affect other markets.

Upper Layer:

MetaMorpho Vault (vault).This is an ERC-4626 standard vault, equivalent to a "fund product."

Users deposit USDC into the vault, and the vault manager (Curator) is responsible for allocating these funds to different Morpho Blue markets to earn interest.

Users hold shares of the vault, and the value of the shares increases as interest accumulates.

Core formula -- net asset value (NAV / Price Per Share):NAV per share = totalAssets / totalSupply

totalAssets is the total supply position of the vault across all markets (including the borrowed portion, since those are "receivables"). totalSupply is the total number of shares issued by the vault. As interest accumulates, totalAssets increases, but totalSupply remains unchanged, thus NAV per share rises -- 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 entire attack.

In Morpho Blue, the supply() function has an onBehalf parameter. The original intention of this design is to facilitate third parties to make deposits -- for instance, automated strategy contracts can deposit money on behalf of users.

But it iscompletely 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 this market increases by 10,000, and totalAssets also increases by 10,000. However, the vault's total supply (totalSupply) does not change -- because no one has deposited new funds through the vault's deposit() function.

As a result: NAV per share is inflated.

Under normal circumstances, this would essentially be donating money to the vault -- you are increasing the gains for all shareholders out of your own pocket, only a fool would do that. But under specific conditions, this can be exploited.

3. Supply Cap = 0 ≠ Safe

After USR decoupled, some vault managers urgently set the Supply Cap of the USR/USDC market to 0, meaning the managers can no longer invest money into this market. Sounds like the problem is solved?

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

What vault managers can control is the vault's own _supplyMorpho() internal function.

However, supply(onBehalf=vault) directly interacts with the Morpho Blue Core contract, completely bypassing all logic at the vault level: supply queue, supply cap, allocator permission checks, all are ignored.

To use a metaphor: the vault manager closed the front door (Cap=0), but attackers stuffed money in through the back door of Morpho Core.

4. Hardcoded Oracle -- The Cloak of Bad Debt

This is the second key condition.

The oracle for the USR/USDC market was set to a fixed 1:1. This means that, no matter how much USR falls in external markets, in the world of Morpho, 1 USR is always equal to 1 USDC.

Why would vault managers use a fixed oracle? Because USR is a "stablecoin," typically with little price fluctuation. A fixed oracle can prevent "false liquidations" due to short-term liquidity shortages.

But when USR really decouples, a fixed oracle becomes disastrous -- borrowers use worthless USR as collateral to borrow sufficient USDC, while the protocol remains unaware.

Morpho's bad debt handling mechanism completely fails here -- both V1.0's real-time reflection and V1.1's spread mechanism presume that the protocol can recognize bad debt.

With the oracle hardcoded, nothing can be recognized.

5. Entire Attack Process -- Five Steps Closed Loop

Now all conditions are met. Below are the atomic operations completed in a single transaction:

6. Why is a Flash Loan necessary?

This is the easiest issue to overlook. The profit from the attack comes from "inflating totalAssets and then distributing the appreciation proportionally to the shares." If the attacker does not provide a flash loan, they hold 0% of the shares -- even if they artificially inflate totalAssets to the sky, all appreciation goes to other shareholders, leaving them with nothing.

7. Who lost money?

The 12,300 USDC taken by the attacker did not just appear out of thin air. This money came from the vault's real liquidity in other healthy markets.

When the vault redeems, it withdraws USDC from various markets in the order of the withdraw queue. The USDC in the USR market has already been borrowed out, so no money can be withdrawn. Therefore, the redeemed funds come from other markets -- such as wETH/USDC, cbBTC/USDC, and other normally functioning markets.

8. The cumulative effect of three-layer vulnerabilities

This attack is not a single vulnerability, but a combination of three design issues:

Conclusion

Morpho's minimalist design philosophy -- permissionless, non-upgradable, minimal governance -- is an advantage most of the time. But this incident shows thatthe cost of minimal design is pushing greater responsibility onto upper-level participants.

If the protocol does not perform oracle validations, the managers must do it themselves. If the protocol does not restrict supply(onBehalf), the vault level needs additionalprotection.

For depositors, "choosing the right Curator" is more important than "choosing Morpho" itself. The protocol is a tool, and whether the tool is safe depends on the person using it.