Root Cause
The vault maintained a lending whitelist — a set of contracts authorised to borrow assets — enforced through a 3-of-7 Gnosis Safe multisig. A critical gap in access control allowed an attacker-controlled contract to be added to this whitelist, enabling unlimited borrowing of vault assets.
The whitelist management function did not enforce any time-delay, governance vote, or on-chain ownership proof before accepting a new borrower contract. Once whitelisted, any contract can call the vault's borrow() function and withdraw collateral-backed assets.
// Conceptual vulnerable pattern (reconstructed from on-chain behaviour)
// Vault's addToWhitelist() — no verification of the contract being legitimate
function addToWhitelist(address lender) external onlyMultisig {
whitelist[lender] = true; // No time-lock, no code hash check
}
// borrow() honours any whitelisted address unconditionally
function borrow(uint256 amount) external {
require(whitelist[msg.sender], "Not whitelisted");
IERC20(aBaswstETH).transfer(msg.sender, amount); // Full balance extractable
}
The fundamental flaw is that the multisig signers either approved a malicious contract knowingly (internal threat), were social-engineered into signing a fraudulent proposal, or had signing devices compromised. None of these scenarios has been confirmed; the vault operator remains unidentified as of October 6, 2026.
Attack Steps
| Step | Time (UTC) | Action |
|---|---|---|
| 1 | ~08:50 | Attacker deploys new malicious contract on Base |
| 2 | 08:52 | Safe multisig removes the malicious contract from whitelist (anomalous — contract had just been added) |
| 3 | 08:53 | Same Safe multisig re-adds the malicious contract to whitelist (3-of-7 signatures) |
| 4 | ~09:11 | Attacker calls borrow() from whitelisted contract |
| 5 | ~09:11 | 1,783.067 aBaswstETH (Aave receipt tokens) transferred to attacker |
| 6 | ~09:11 | Attacker redeems aBaswstETH through Aave V3 on Base for ~1,783 wstETH |
| 7 | Post-drain | Stolen wstETH consolidated; Aave's core protocol unaffected |
Source: Blockaid first flagged the exploit; CryptoTimes and mpost.io reconstructed the timeline.
Impact
- Loss: ~$6 million in wstETH (1,783 wstETH at October 4, 2026 prices).
- Remaining at risk: One analysis put an additional $31.7 million in the broader vault ecosystem at risk if the same pattern persists.
- Operator identity: No project team has publicly claimed the vault. GoPlus Security noted the contract was not attributed to any known protocol.
- Aave V3 unaffected: The attack used Aave receipt tokens already held by the vault; Aave's core lending markets were not exploited.
- Recovery: No recovery, freeze, or attacker contact reported as of October 6, 2026.
Lessons for Auditors
- Whitelist timelocks: Any function that grants borrowing or withdrawal privilege to a new address should enforce a mandatory time-delay (e.g., 24–48 h) so anomalous additions can be detected and vetoed before they take effect.
- Multisig signer hygiene: 3-of-7 is meaningless against collusion or compromise of three keys. High-value whitelists need hardware signing, separate communication channels for proposal verification, and ideally independent signers across organisations.
- Code-hash allowlisting: Vaults should verify the bytecode hash of any contract being whitelisted, preventing an attacker from swapping a legitimate contract for a malicious one after approval.
- Remove-then-re-add anomaly detection: The remove/re-add pattern in consecutive blocks (08:52–08:53 UTC) is a detectable on-chain signal. Monitoring systems should alert on whitelist modifications to high-value vaults within the same block or within a short window.
- Anonymous protocols carry rug-pull ambiguity: No post-mortem, no operator identity, and no communication make it impossible to distinguish exploit from insider exit.