Base Vault $6M wstETH Drain: A Signed Whitelist Change

TL;DR

At 08:53:51 UTC on October 4, 2026, a 3-of-7 Safe on Base executed a call that, by Blockaid's and Crypto Times' account, put a brand-new contract on the whitelist of the vault it administers. That contract had been deployed about 85 minutes earlier by the address that went on to drain the vault. Within 19 minutes of that call it had pulled 1,783.067 aBaswstETH out of the vault in six transfers. The attacker then redeemed it through Aave for wstETH and started bridging it to Ethereum. PeckShield and ExVul put the loss at about $6M. No smart contract bug has been identified, though the vault's unverified code means one cannot be ruled out. The Safe accepted three valid owner signatures, and Crypto Times reported the same three signing identities on both admin calls. Nobody has claimed the vault, and the signers are unidentified. A multisig is only as strong as what its signers believe they are approving, and here three approvals were enough to empty a position.

What Happened to the Base wstETH Vault?

An unnamed vault on Base lost its entire wstETH position. Blockaid raised the first public alert at 09:20 UTC, describing "a brand-new contract" added to the vault's whitelist that then took the vault's aBaswstETH: about $2.02M "across ~4 txs" at that point. PeckShield followed at 09:56 UTC with the full 1,783 wstETH, and ExVul counted 1,783.067 aBaswstETH "across six vault outflows".

The vault is an OpenZeppelin transparent proxy at 0xD1895f2019c2152FC2b9022D57f19198c4CFCABC, administered by a Safe at 0x6b27512a5943Ed327f6cb6C3EC1f0398229f42C4 that needs three of seven signatures, according to Bitcoin.com's reconstruction. The vault held its assets as Aave positions. aBaswstETH is the receipt token Aave on Base issues for supplied wstETH (Lido's wrapped staked ETH). Whoever holds it can redeem the underlying.

TokenPost reports that neither Base nor Aave's core contracts were identified as attacked, and that "the specific authorization weakness that enabled the transactions has not been established". On-chain, the Safe's signature check passed, so whatever failed sat with the signers or their signing setup.

How Did the Attacker Get on the Whitelist?

The vault's own admin let them in. A whitelist on a vault like this is a list of contracts allowed to call privileged functions, in this case one that moves the vault's aTokens to the caller. Adding an address to it is an admin action, and the admin is the Safe.

The Safe's transaction history shows two calls to the vault, 08:52:23 and 08:53:51 UTC. Both call the same vault function with the attacker's contract as the first argument, consistent with Blockaid's account of a whitelist addition. The first passes a flag of 0, the second a flag of 1. Crypto Times reads the pair as the Safe removing the contract from the whitelist and re-enabling it a minute later. Why anyone would "remove" a contract that was never listed is open: the vault implementation is not verified, so the function behind selector 0x38edc837 cannot be read from source. A dry run of the signing flow is one plausible reading, and it is only that. Each call carries three signatures, and each passed the Safe's own signature check, or the Safe would have reverted.

We ran ecrecover over both transactions' Safe hashes and got the same result Crypto Times reported: three of the seven owners signed both, as plain EIP-712 signatures over the transaction hash. Each signature carries a standard ECDSA recovery byte (27 or 28), so all three signers are ordinary externally owned accounts, not contract wallets. The two calls used consecutive Safe nonces, 262 and 263. No module, no delegatecall, no owner swap. In our check, none of the three signing addresses has ever sent a transaction on Base or holds any ETH there: they sign off-chain and someone else relays, so there is no signer-side trail on-chain to follow. As far as the Safe could tell, a quorum of its owners wanted this contract on the list.

Both calls were relayed by 0x4fF634EF57c2497C6cf9Eb415e326C5D8fc8c104, which created the vault in the first place and has been executing this Safe's transactions since at least July. Anyone can submit a fully signed Safe transaction. It does mean the malicious change arrived through the operator's normal pipeline.

Was This a Key Compromise, an Insider, or a Signing Trick?

Undecided, and nobody has published the answer. The chain shows three possible stories, and it cannot tell them apart:

Three keys were stolen. The attacker held three signing keys outright.
The signers were shown something else. The Radiant Capital post-mortem describes exactly this in October 2024: malware on three developers' devices made Safe display "legitimate transaction data while malicious transactions were signed and executed in the background", and Tenderly simulations looked normal. That cost more than $50M.
Someone inside approved it on purpose.

One on-chain detail narrows it a little. The attacker deployed the contract at 07:28:57 and initialized it at 08:10:53, 42 minutes before the Safe acted. Whoever built it knew the whitelist call was coming and knew which address it would name. That rules out an opportunist who spotted a misconfiguration after the fact. Our read, and it is only a read: preparation that far ahead fits an attacker who controlled or could see into the signing pipeline, the Radiant pattern or an insider, better than three keys stolen separately.

The Attack, Step by Step

All times UTC, October 4, 2026, from Base Blockscout.

#	Time	Actor	Action
1	06:49:43	Attacker EOA `0x0B5126...B034`	Receives 0.05 ETH bridged in from Ethereum, its first funding
2	07:17 to 07:28	Attacker EOA	Deploys three contracts; the last, at 07:28:57, is the transparent proxy `0xcdFE...569d`
3	08:10:53	Attacker EOA	Initializes the proxy
4	08:52:23	Vault Safe (3 of 7)	Calls the vault whitelist function on `0xcdFE...569d` with flag `0`
5	08:53:51	Vault Safe (3 of 7)	Same call, flag `1`; read by Blockaid and Crypto Times as the whitelisting, and the first pull follows 70 seconds later
6	08:55:01	Attacker contract	Test pull: 1 aBaswstETH from the vault, forwarded to the EOA at 08:56:25
7	08:59:39	Attacker EOA	Sends 0.03 ETH for gas to a second wallet, `0xC734...7f8D`
8	09:08:13 to 09:12:37	Attacker contract	Five more pulls: 100, 500, 500, 500 and 182.067 aBaswstETH
9	09:19:19	Second wallet	Gas.zip deposit, plausibly gas for the destination chain (our inference)
10	09:20	Blockaid	First public alert, eight minutes after the last vault outflow
11	09:23:13	Attacker EOA	Redeems 1,783.067 aBaswstETH through Aave for 1,783.067 wstETH
12	09:24 to 10:47	Attacker EOA	1 wstETH test, then 1,782.067 wstETH, to the second wallet
13	09:27:29 and 12:10:59	Second wallet	Bridges 1 wstETH, then 1,000 wstETH, toward Ethereum through Lido's L2ERC20TokenBridge

Two paths, one through the Safe's signers and one through the attacker's wallet, met at the vault:

rendering diagram…

The attacker ran one unit end to end (pull, forward, fund the exit wallet) and then waited 13 minutes from the test pull, eight of them after funding the exit wallet, before taking real size. Then the rest of the position, 1,782.067 units, left in four and a half minutes. By the time the first alert went public, the vault side was finished, and the redemption into wstETH followed within minutes.

Where Did the $6M Go?

Three places, as of block 52,184,444 at 23:57 UTC on October 4: 1 wstETH and then 1,000 wstETH into the bridge, and 782.067 wstETH still on Base. The bridge call routes through Lido's canonical bridge with superbridge104 in its data field, which looks like the tag a Superbridge frontend attaches. The second wallet's history shows a 1 wstETH test withdrawal at 09:27:29, a Gas.zip deposit at 09:19:19 (plausibly to fund gas on the destination chain, our inference), and the 1,000 wstETH withdrawal at 12:10:59. The remaining 782.067 wstETH was still sitting in that wallet on Base when we checked.

A withdrawal from Base is not instant. Base's withdrawal documentation puts the finalization window at 5 days for a single-proof dispute game and 1 day on the dual-proof fast path, after the withdrawal is proven on Ethereum. So the 1,001 wstETH is in transit, visible to everyone, for at least a day.

Two side plots, both on-chain. While the drain was under way, at 09:01:19, an address-poisoning bot sent a fake "ETH" token to the attacker's second wallet from 0x0B51D92c...DB034, an address minted to look like the attacker's own EOA. And a third party sent the attacker a series of on-chain messages, one at 11:16:33, urging them to go back for the vault's WETH position "before they removed your contract from whitelist", and asking for a cut.

The test pull's calldata takes a token address as its first argument, so nothing in it ties the contract to wstETH. Why the attacker stopped at the wstETH is unknown.

Is the Vault Still Exposed?

The vault still holds a large Aave position. Its token balances show about 11,761 aBasWETH as collateral (the balance grows as Aave interest accrues) against 7,248,717 of USDC debt and 275,741 of EURC debt. TokenPost puts the assets still at risk at roughly $31.7M, and notes that the Safe had not executed a transaction for 25 days before the attack, which makes two whitelist calls in 88 seconds stand out even more.

We found no Safe transaction after 08:53:51 UTC on October 4 through block 52,184,444 at 23:57 UTC, about 15 hours later, and no direct call to the vault since April. Neither path shows a revocation of the whitelist entry that drained the wstETH. Aave's health-factor check limits how much collateral can leave while the debt is open, which caps the exposure without removing it.

If you are one of the seven signers: revoke the entry, and do it from devices and a review path that had nothing to do with the October 4 signatures.

Why Do Valid Signatures Keep Being the Exploit?

A multisig checks a count. A Safe verifies that enough owners signed a specific transaction hash. It does not know whether the transaction is a routine rebalance or the handover of a $6M position to a contract born that morning.

Radiant lost more than $50M to three compromised signers in 2024. We covered the same failure shape in Bitget's spoofed withdrawal signing, and the module-permission version of it in the SquidRouterModule Safe exploit and the rsETH Safe module bypass.

An audit of this vault would have certified a reasonable design: privileged function, whitelist, admin is a 3-of-7 Safe. It would have said nothing about what the vault does when three of those seven sign the wrong thing on a Sunday (October 4, with the window running from 08:52 to 09:12 UTC).

The whitelist was the vault's real perimeter. As far as the transactions show, it changed with one call, behind the same three signatures as everything else, with no delay and no second check.

What Should Vault Operators Do Now?

Put a timelock between the Safe and the whitelist. Make the vault's owner a timelock contract with the Safe as proposer, so an allowlist addition is queued in public for hours before it takes effect, and pair it with the guardian in item 2 so a queued change can actually be cancelled. The Zodiac Delay modifier applies the same pattern to module-initiated Safe transactions: a cooldown during which "transactions can be marked as invalid by the Safe".
Separate the fast "no" from the slow "yes". Removing a whitelist entry or pausing outflows should take one guardian signature. Adding one should take the full quorum plus the delay. Here the remove and the add were the same function and the same threshold.
Enforce invariants in a Safe Guard. Safe Guards "can make checks before and after a Safe transaction". A guard can refuse any whitelist write that does not arrive through the timelock, or whose target is missing from a registry of reviewed contracts. The attacker's contract was about 85 minutes old.
Rate-limit what a whitelisted contract can move. No single caller should be able to take a full position in four and a half minutes. A per-caller or per-epoch outflow cap turns a 19-minute drain into a trickle someone notices.
Treat signing as an attack surface. Verify Safe transaction hashes on a separate device before signing, decode calldata independently of the Safe UI, and rotate any key that signed the October 4 transactions if you share signers with this Safe.
Alert on admin changes, not only on outflows. The whitelist change is the earliest observable event on the vault itself. The funding and the deploy came earlier, but they touched nothing the operator runs. The first write came about two and a half minutes before the first unit left.

Could Monitoring Have Changed the Outcome?

Partly. The vault's own admin path was the attack path. Its implementation is unverified, so whether it has any guardian or pause role that could act without those same three keys cannot be read from chain, and none was used. So an alert here buys warning, and what that warning is worth depends on having a fast way to act on it. The observable events were clear:

08:52:23: the Safe called the vault's whitelist function, naming a contract created at 07:28:57 by an address first funded at 06:49:43 the same morning. A second write at 08:53:51 made it effective. A rule on "admin change naming a contract younger than a day" fires on the first write, about two and a half minutes before the first unit left.
08:55:01: the first aBaswstETH outflow, to that same contract.
09:08:13: a 100-unit outflow, then three 500-unit ones. Four and a half minutes later the position was empty.

Tripwire watches exactly this class of event: admin and allowlist writes on contracts you operate, outflows to addresses with no history, and position balances dropping in a window. If the vault had a guardian that could pull a whitelist entry or pause outflows on one signature, an alert on the first write naming that contract, at 08:52:23, would have reached it before the first unit left and almost sixteen minutes before the drain took real size. The same rules keep reporting on an entry like this one for as long as it stays live, which is the exposure this vault is still carrying.

What We Still Do Not Know

The vault's operator has not come forward, and no protocol has claimed it. Nobody has published who the seven signers are, how the three signatures were produced, or why the attacker took the wstETH and has, so far, left the far larger WETH collateral alone. The 1,001 wstETH in Lido's bridge cannot finalize on Ethereum before its dispute window closes. We will update this post if the operator publishes a postmortem.

Frequently Asked Questions

Was Base or Aave hacked in the October 2026 vault drain?

No. TokenPost reports that neither Base nor Aave's core contracts were identified as attacked. The attacker used Aave only to redeem aBaswstETH that the vault's own whitelist let them take.

Were the Safe signatures on the whitelist change valid?

Yes. Both admin transactions carry three ECDSA signatures that recover to Safe owners, and the Safe would have reverted otherwise. Crypto Times and our own recovery found the same three signers on both calls.

How much was stolen from the Base vault?

About $6M: 1,783.067 aBaswstETH, redeemed for 1,783.067 wstETH. ExVul counts the six vault outflows and PeckShield gives the dollar figure. Blockaid's earlier $2.02M was a partial count: its alert went out after the last vault outflow but counted about four transactions.

Can the stolen wstETH be recovered?

Not yet. 1,001 wstETH is in two Base to Ethereum withdrawals that cannot finalize until their dispute windows pass, and 782.067 wstETH was still in the attacker's second wallet on Base at 23:57 UTC on October 4. No freeze or recovery has been announced.

Would a timelock alone have stopped this drain?

No. A timelock turns the 19 minutes between the effective whitelist call and the last outflow into hours of public warning, but cancelling a queued change still takes a route that does not depend on the same three keys, such as a guardian role, and the vault's unverified code leaves open whether it has one. None was used. With both in place, the attacker's whitelist entry would have sat in a public queue where one guardian signature could kill it before it took effect.

Base wstETH Vault: $6M Drained Through a Whitelist Its Own 3-of-7 Safe Signed