A vault that passes a smart contract audit can still be vulnerable to attacks. The reason is that a single deposit spans several security boundaries, and the failure usually happens at one of the joins rather than inside any one component. This article sets out where those boundaries sit in a vault, how Morpho's architecture changes the exposure at each of them, and what two real incidents show about the classes of failure that vault operators need to plan for.
Where Vault Risk Lives
A vault's deposit button can hide several distinct security boundaries. Share accounting belongs to the vault. Collateral valuation and liquidations belong to its underlying lending markets. Adapters and applications connect components. Operators control allocation and privileged changes. Losses can originate at any of these boundaries, even when individual contracts behave as designed.
That last point is what makes vault security harder than contract security. A review that only asks "is this code correct?" will miss the failure modes that live between components, in the way a vault is configured, and in the way its operators are permitted to act.
Four boundaries sit behind a single deposit, and each one fails differently:
- Share accounting: the vault's own logic for converting assets into shares and back again.
- Collateral valuation and liquidations: these belong to the underlying lending markets the vault supplies, not to the vault itself.
- Adapters and applications: the connective layer between components.
- Operators control allocation and privileged changes to the vault.
Morpho makes these distinctions particularly relevant. Depending on the deployed version, adapters and markets in use, exposure at each boundary can be small or large. As outlined in Morpho's documentation, legacy Vaults V1 and the newer Vaults V2 entail different features and different adapter architectures, and these should be reviewed before applying a generic ERC-4626 attack scenario to a specific deployment.
For any team implementing or reviewing a Morpho vault, this is a practical requirement, not a caveat. Confirm the deployed version, its adapters, its markets and its permissions before drawing conclusions from a generic vault threat model. A finding that is real for one deployment can be inapplicable to another with different adapters and different permissions.
Share Accounting and Integration Assumptions
ERC-4626 standardizes a tokenized vault interface, not its economic safety. The distinction matters because integrators often read standard compliance as a safety property. It is not one.
In susceptible implementations, donations can increase assets per share without minting corresponding shares. Combined with rounding, this can disadvantage depositors in nearly empty vaults. An integration can introduce a separate weakness by treating a manipulable share conversion rate as a reliable lending price. Reviewers should examine both vault accounting and the assumptions of applications consuming it.
Morpho documents a specific Vaults V1 edge case. An oracle that materially overvalues collateral in a market listed by a Vault V1 can combine with donations made on the vault's behalf to expose other depositors. A zero supply cap does not remove this exposure while the market remains in the withdraw queue. Morpho states that Vaults V2 supplying directly through MorphoMarketV1AdapterV2 avoid this particular edge case. A Vault V2 using MorphoVaultV1Adapter retains exposure up to its allocation to that V1 vault.
This is essential, because the framing matters for any risk register it ends up in. This describes a conditional risk, rather than establishing that a particular deployment has been exploited. The condition is the point: the exposure depends on the adapter in use and on the vault's allocation, both of which are deployment facts a reviewer can check. Morpho's security considerations for curators set out the same distinction.
Market Exposure and Operational Authority
At the market layer, three factors carry most of the risk:
- Whether oracle prices reflect realizable collateral value.
- Whether liquidators can execute economically.
- Whether liquidity will support withdrawals during stress.
Bad debt or a liquidity shortfall does not, by itself, prove a smart-contract exploit. This is a common misreading of a stressed vault, and it sends remediation in the wrong direction. A vault allocating across markets still needs to assess common collateral, oracle and liquidity dependencies, because diversification across markets does not diversify a shared dependency.
Administrative authority creates another exposure. Vault V2 separates Owner, Curator, Allocator and Sentinel capabilities, but that separation must be reflected in how keys and approvals are operated. Separation on paper is not separation in practice.
The documented powers are specific, and so are their limits:
- Owner: can replace the Curator.
- Allocator: operates within configured constraints.
- Sentinel: can revoke pending changes, lower caps and deallocate where the adapter and available liquidity permit.
Two limits deserve emphasis, because both are routinely overestimated in an incident plan. Lowering a cap alone does not withdraw funds. Timelocks provide a response window only where a nonzero delay applies. They do not guarantee detection of malicious changes or that depositors can exit in time.
Two Exploit Patterns in Practice
Two incidents from February 2025 show how differently these boundaries fail. Neither is a Morpho exploit. Both are directly relevant to anyone operating a vault.
The wUSDM donation attack on Venus's ZKsync deployment illustrates an integration failure. According to the published post-mortem, the attacker manipulated wUSDM's exchange rate by redeeming shares and donating underlying assets. Venus used that rate in lending calculations, enabling a sequence involving borrowing and self-liquidation that left bad debt. The lesson is to validate how a share rate can change before using it to price collateral or debt, and design appropriate valuation and exposure limits. This was a Venus/wUSDM incident, not a Morpho exploit.
The Bybit theft illustrates the signing boundary. The forensic investigation describes malicious JavaScript in the Safe interface that concealed altered transaction data. Signers approved a transaction granting the attacker control over the cold wallet, enabling the theft. This was a custody and transaction-authorization incident, not a vault-accounting or Morpho exploit.
Its relevance to vault operators is the danger of approving privileged transactions through a compromised interface. Multiple signatures do not establish that signers understood the actual effect. Verify transaction details through an independent trusted path.
Set side by side, the two incidents describe the range a vault security program has to cover. One failed in the arithmetic of share pricing. The other failed in the human approval of a single transaction, with the contracts behaving exactly as written.
Controls Matched to the Failure
Technical review should be paired with a tested operating plan. The controls below map to the failure classes above rather than to a generic checklist.
Validate the accounting and the assumptions built on it:
- Test share conversions, rounding and loss recognition.
- Challenge oracle and liquidity assumptions, rather than inheriting them from a listing decision.
- Verify the exact powers of every privileged role, as configured in the live deployment.
Protect the signing path for sensitive transactions:
- Independently decode the transaction. Check its chain, target contract, operation and parameters.
- Verify expected effects through a trusted path separate from the interface proposing it.
- Use simulation where applicable.
Operate the keys as carefully as the code: restrict key access, separate approval responsibilities, preserve audit trails, and rehearse compromise response. These operational controls complement smart-contract review and market-risk analysis.
Make detection and response accountable:
- Assign each alert an accountable owner and a tested action or escalation path.
- Rehearse role compromise, oracle failure and unavailable liquidity, including what happens if the usual interface or signer is unavailable.
- Verify that containment succeeded, rather than assuming it did.
- Document which actions the deployment actually permits and which remain constrained by timelocks or liquidity.
Recovery plans should establish safe authority and a controlled return to service without promising recovery of funds already lost.
Securing Vault Deployments with Halborn
Vault losses rarely trace to one broken contract. They trace to a boundary: a share rate trusted by an integration, an oracle trusted by a market, a role trusted with more authority than its operating practice supports, or an interface trusted at the moment of signing.
Halborn covers these boundaries through services such as Smart Contract Assessment, Custody and Key Management Assessment, and Risk Assessment. To review a vault deployment, its adapters, or the operating controls around its privileged roles, get in touch with Halborn.