Cowrie Research

wasabi-protocol-deployer-key-compromise-strategy-redirection-malicious-longpool-upgrade-drain-2026-04-30

13 min read

Wasabi Protocol Deployer-Key Compromise / Strategy-Redirection + Malicious LongPool-Upgrade Drain (2026-04-30)

  • Name: Wasabi Protocol deployer-key compromise / strategy-redirection + malicious LongPool-upgrade drain
  • Date: 2026-04-30
  • Protocol: Wasabi Protocol
  • Chain: Ethereum, Base, Berachain, Blast
  • Category: privileged upgrade abuse / deployer-key compromise / strategy redirection / malicious implementation swap
  • Loss: Early live estimates from Blockaid were about $4.55M, but later cross-chain tallies from incident responders and post-incident coverage put total losses around $5.9M across Ethereum, Base, Berachain, and Blast
  • Summary: Wasabi’s EVM perpetuals stack concentrated production authority in one deployer EOA, wasabideployer.eth (0x5c629f8c0b5368f523c85bfe79d2a8efb64fb0c8), which held ADMIN_ROLE over the PerpManager control plane across chains. After that key was compromised, the attacker used legitimate admin transactions to grant zero-delay authority to helper contracts, then drained vault collateral through the privileged strategyDeposit() path and separately UUPS-upgraded LongPool contracts to malicious logic that swept pool balances. This was not a user-callable bug in Wasabi’s ordinary leverage or vault math; it was a control-plane failure where one compromised operator key could redirect strategies, rewrite implementations, and empty live TVL across multiple deployments.
  • Trigger / entry point:
    • Public incident reporting consistently described the root event as compromise of Wasabi’s single deployer / admin EOA rather than discovery of a new contract-level logic flaw.
    • That EOA retained top-level ADMIN_ROLE on Wasabi’s PerpManager, the contract family that governed vault strategy routing, upgrade authorization, and further admin grants.
    • Because grantRole(uint64,address,uint32) allowed delay = 0, the compromised key could hand immediate production authority to fresh attacker helper contracts in the same block window as the drain.
    • Wasabi’s own documentation and incident coverage indicate the same admin surface existed across Ethereum, Base, Berachain, and Blast, so one compromised key exposed multiple live environments at once.
  • Root cause:
    • The true custody boundary for Wasabi’s EVM system was a single deployer/admin wallet rather than a multisig plus timelock or other delayed governance surface.
    • PerpManager admin authority spanned both upgradeability and direct asset-routing powers, so compromise of one key unlocked more than code replacement alone.
    • The vault drain path relied on privileged strategy redirection: once admin rights existed, strategyDeposit() could route collateral into attacker-controlled contracts.
    • The architecture provided no meaningful delay, second signer, or implementation / destination allowlist between admin-key compromise and live asset movement.
  • Exploit path:
    1. The attacker obtained control of Wasabi’s deployer/admin EOA 0x5c629f8c0b5368f523c85bfe79d2a8efb64fb0c8 (wasabideployer.eth), which already held ADMIN_ROLE on the live PerpManager surface.
    2. On Ethereum, in transaction 0x11ff84ffbd62d2f4f26b289d79938a899967fb69f4ef40bf7f0e36ef295f1ded, the compromised deployer called grantRole(0, 0x878E94142409DAFCC5CC83D5cD2e9DA2Bf0BF3bF, 0) on PerpManager proxy 0xc0b01a4f4a4459d5a7e13c2e8566cde93a010e7d, instantly making attacker helper contract 0x878E...F3bF a zero-delay admin.
    3. In drain transaction 0xcd77423f1bfa362c43f98356360c1f6c6e5fe989f18036e874884e9ad4a70116, the attacker used that helper to iterate across eight Ethereum vaults and call strategyDeposit() into attacker-controlled child contracts, pulling roughly $2M from the vault side in a single transaction according to incident analysis.
    4. The same admin-compromise pattern then propagated across Wasabi’s other EVM deployments; public tallies describe corresponding vault drains on Base, Berachain, and Blast, with Base suffering another roughly $2.5M in losses.
    5. The attacker deployed a second helper contract, 0x293e880166683e5fef9ca4295d208a235a1e98fc, then in transaction 0x985b4cde1075c67841d0f9fd897da34c9da53d77f6e23b5a19653ebff4a6fac1 used the compromised deployer key to grant it admin rights as well.
    6. In transaction 0xbabbfd5dc3a448244b1797928c69001726106c241f29e22b979a8bc01807c317, that second helper UUPS-upgraded Ethereum Long Pool 0x8e0edfd6d15f858adbb41677b82ab64797d5afc0 to malicious implementation 0x1f392a1f7c737aa4777ed3dc608ec153dfd39c7e and swept pool balances. Public reporting says the same LongPool-upgrade pattern also hit Base.
    7. The attacker additionally pushed hostile fee / receiver changes on adjacent Wasabi contracts, showing that the compromise covered ongoing protocol configuration as well as the initial drain path.
    8. Stolen assets were swapped and consolidated into ETH, then routed onward through secondary addresses and laundering infrastructure.
    9. Wasabi eventually used the still-live admin surface to grant recovery EOA 0x2eb7f20c38455ae3d5f21d01efea49988e043cc4 authority in transaction 0x8f036a3f660e1c58be87e1066a66da3d5ea2a0362386ee61519755b383850199, then revoked the attacker helper contracts in 0x8ec894cb401c54003b99e704f7ae01d72fcfc176d08b1a2727b03c1960cda865 and finally revoked the compromised deployer in 0x47bac91c6a4d8a7222b68313e0e8322cfb0686bfb41a4fc7640b40f39e6ac397.
  • What the attacker needed to be true:
    • One externally owned account had to remain the top-level admin for Wasabi’s production control plane across multiple chains.
    • Admin grants had to take effect immediately, with no delay for monitoring or user exit.
    • The same admin surface had to authorize both vault strategy routing and UUPS upgrades.
    • Vault collateral and pool balances had to remain directly reachable once privileged logic accepted attacker-controlled strategy or implementation destinations.
    • Cross-chain deployments had to share the same compromised trust anchor rather than isolate authority chain by chain.
  • Technical anatomy worth remembering:
    • Wasabi is a clean case where admin-key compromise -> zero-delay role grant -> privileged fund-routing calls -> malicious pool upgrade all happened without defeating the protocol’s user-facing logic checks.
    • The vault side and pool side were two different monetization paths unlocked by the same root credential: legitimate admin use of strategyDeposit() for vault extraction, and UUPS implementation replacement for LongPool extraction.
    • This is why upgrade authority should be modeled as custody, not maintenance. The attacker did not need an invariant bug if they could redefine which contract held authority and where assets should be sent.
    • The cross-chain blast radius mattered. A single compromised wallet controlled multiple EVM deployments, so the architecture turned one key compromise into a synchronized multi-chain incident.
  • Representative transactions and addresses:
    • Compromised deployer EOA: 0x5c629f8c0b5368f523c85bfe79d2a8efb64fb0c8
    • Attacker EOA: 0x02228b0afcdbEdf8180D96Fc181Da3AF5DD1d1ab
    • Ethereum PerpManager proxy: 0xc0b01a4f4a4459d5a7e13c2e8566cde93a010e7d
    • Ethereum Long Pool: 0x8e0edfd6d15f858adbb41677b82ab64797d5afc0
    • Attacker helper 1 / vault sweeper: 0x878E94142409DAFCC5CC83D5cD2e9DA2Bf0BF3bF
    • Attacker helper 2 / LongPool upgrader: 0x293e880166683e5fef9ca4295d208a235a1e98fc
    • Malicious LongPool implementation: 0x1f392a1f7c737aa4777ed3dc608ec153dfd39c7e
    • Recovery EOA: 0x2eb7f20c38455ae3d5f21d01efea49988e043cc4
    • Ethereum admin-grant tx: 0x11ff84ffbd62d2f4f26b289d79938a899967fb69f4ef40bf7f0e36ef295f1ded
    • Ethereum vault-drain tx: 0xcd77423f1bfa362c43f98356360c1f6c6e5fe989f18036e874884e9ad4a70116
    • Ethereum second admin-grant tx: 0x985b4cde1075c67841d0f9fd897da34c9da53d77f6e23b5a19653ebff4a6fac1
    • Ethereum LongPool malicious-upgrade tx: 0xbabbfd5dc3a448244b1797928c69001726106c241f29e22b979a8bc01807c317
    • Recovery grant / revoke sequence: 0x8f036a3f660e1c58be87e1066a66da3d5ea2a0362386ee61519755b383850199, 0x8ec894cb401c54003b99e704f7ae01d72fcfc176d08b1a2727b03c1960cda865, 0x47bac91c6a4d8a7222b68313e0e8322cfb0686bfb41a4fc7640b40f39e6ac397
  • Response / mitigation:
    • External monitors including Blockaid, CertiK, Hypernative, Cyvers, and others publicly identified the exploit mechanism and attacker infrastructure while the drain was still in progress.
    • Wasabi publicly warned users not to interact with contracts, then later said the EVM incident had been contained.
    • Onchain mitigation focused on rotating authority to a recovery EOA and revoking both attacker helper contracts and the compromised deployer.
    • The durable lesson is straightforward: a protocol that leaves live upgrade and strategy authority under one EOA has effectively left the whole system under one hot-wallet custody assumption.

Pattern tags

  • privileged-upgrade-abuse
  • signer-quorum-compromise
  • Single-deployer-EOA control-plane concentration / one compromised root credential retained immediate authority to grant roles, redirect vault strategies, and replace live pool implementations across multiple chains
  • Same-block privilege expansion / zero-delay helper authorization let the attacker turn stolen admin rights into fresh privileged contracts before defenders had a realistic intervention window
  • Strategy-destination arbitrariness plus unreviewed UUPS upgrade authority meant captured admin rights already had direct line-of-sight to live collateral and pool balances rather than only to slow-moving governance settings
  • Cross-chain authority reuse amplified losses because the same compromised root key and PerpManager control model governed Ethereum, Base, Berachain, and Blast deployments plus more than 200 vault contracts documented by Wasabi

Why the exploit worked

  • Wasabi’s real custody boundary was not the vault or pool logic users interacted with; it was the single deployer EOA that retained ADMIN_ROLE on each PerpManager. Once that one wallet was compromised, the attacker inherited authentic authority over strategy routing, role grants, and upgrade paths across chains.
  • grantRole(..., delay = 0) compressed compromise and monetization into the same operational window. Hypernative’s writeup is especially useful here: the attacker could precompute helper-contract addresses, receive admin rights before code was even deployed there, and then deploy and call those helpers almost immediately.
  • The vault-drain path did not require a malicious code upgrade first. Hypernative notes that strategyDeposit() accepted arbitrary destination addresses with no strategy allowlist and no post-call check that assets still remained where the vault expected them. Once the attacker held real admin rights, privileged routing was already enough to extract collateral.
  • The pool-drain path showed the second half of the same authority problem: UUPS implementation replacement on LongPool contracts also required only admin approval, with no independent timelock, implementation allowlist, or second signer to slow a malicious swap.
  • Wasabi’s own docs matter to the blast-radius story: beyond the named pool contracts, the protocol documented over 200 individual vaults, all sitting under the same EVM control plane. That makes this incident a strong reminder that single admin wallet can really mean single credential sitting above an entire vault fleet, not just a couple of upgradeable proxies.
  • The attacker therefore did not need to beat any user-facing invariant. Wasabi had already concentrated enough legitimate authority in one credential that compromised admin use was economically equivalent to custody compromise.

Detection and audit pivots

  • Draw the real authority graph first. For Wasabi-like architectures, ask which wallet can grant ADMIN_ROLE, which contract family that role controls, and how many vaults, pools, and upgradeable proxies sit downstream of that one authority edge.
  • Treat zero-delay role grants as emergency signals, not routine admin noise. A grant from a known admin wallet to an unrecognized address or even to a precomputed-yet-undeployed address should be assumed hostile until proven otherwise.
  • Review privileged routing functions as withdrawal surfaces. If an admin-only call like strategyDeposit() can send value to arbitrary destinations or strategies, it belongs in the same threat model as a direct sweep() or withdraw() function.
  • Separate authorized caller from authorized destination. Wasabi shows that access control alone is not enough when the caller, once compromised, can point funds or implementations at any address the system has never reviewed.
  • Inventory chain-by-chain blast radius before incidents happen. If one signer or one control-plane contract spans Ethereum, Base, Berachain, Blast, and hundreds of vaults, incident responders need that map before the first malicious tx lands.
  • Monitor suspicious admin choreography as a sequence: grant to fresh address → helper deployment → privileged vault-routing call or upgrade call. Each individual step may look ABI-valid; the sequence is the exploit.

Failure-prevention checklist

  • Remove deployer EOAs from production authority. Deployment wallets should not remain live root admins over strategy routing, upgrades, or role management once contracts are in service.
  • Split powers by function and by chain. Grant root roles, redirect vault strategy destinations, and upgrade pool implementations should not all sit behind the same signer set, and one chain’s compromise should not automatically expose every other chain.
  • Add real delay to dangerous admin actions, including role grants. A same-block or same-minute path from new admin created to funds moved leaves defenders no meaningful time to react.
  • Require destination allowlists or equivalent bounded routing for privileged strategy functions. Even valid admins should not be able to point vault collateral at arbitrary fresh contracts with no prior review.
  • Require implementation allowlists, bytecode commitments, or staged approvals for upgrades. Admin approved this upgrade is too weak if the approved implementation can be an attacker-authored drainer deployed moments earlier.
  • Monitor and gate grants to undeployed or unrecognized addresses. Precomputed contract addresses are useful attacker tools when the protocol is willing to bless an address before there is code to inspect.
  • Maintain a machine-readable inventory of every contract reachable from each root admin: pools, vaults, proxies, routers, and strategy destinations. Incident response should begin from a prepared blast-radius sheet, not live explorer archaeology.
  • Pair admin monitoring with automatic containment where feasible: pausing vaults, blocking unknown upgrades, freezing new strategy destinations, or narrowing collateral exposure when unexpected admin sequences appear.

Audit prompts

  • Which exact EOAs, multisigs, or contracts can grant top-level Wasabi admin rights today, and are any of them still single-signer hot wallets?
  • Can a newly granted admin act immediately, or is there any enforced delay between role creation and privileged use?
  • Does any privileged routing function allow arbitrary destination addresses, fresh contracts, or unreviewed strategies to receive vault assets?
  • Are pool upgrades pinned to pre-approved implementations and expected storage effects, or can an admin point the proxy at any address with matching ABI selectors?
  • How many vaults, pools, and chains share each root authority object, and is that inventory documented somewhere responders can use under incident pressure?
  • Would monitoring distinguish planned maintenance from unexpected grant to fresh address + immediate privileged call, or does every admin action currently look equally normal?
  • If an attacker received admin on one chain today, what concrete control would stop the same credential from being used against sibling deployments on other chains within minutes?
  • What post-action invariant proves privileged strategy movement was legitimate: destination on approved list, assets still receivable by the vault, bounded accounting change, or nothing beyond caller had admin?

Lessons that should already be standard

  • A single deployer wallet with live ADMIN_ROLE is a custody model, not a convenience. If that wallet can still redefine where assets go or what code pools run, the protocol remains one key away from total compromise.
  • Role grants deserve the same paranoia as upgrades. Creating a fresh zero-delay admin helper is often just a more flexible way to perform the malicious upgrade or drain one step later.
  • Privileged routing is already a withdrawal surface. If an admin can redirect strategy deposits to arbitrary contracts, the protocol has effectively granted that admin a shaped sweep primitive.
  • Cross-chain deployments do not create diversification when they share one root credential. They create synchronized loss channels.
  • Monitoring has to understand sequences, not only signatures. Legitimate admin signed it is exactly what operator-key incidents look like onchain.
  • Documentation of blast radius matters operationally. When a protocol documents hundreds of vaults beneath one control plane, that should immediately raise the standard for authority isolation, monitoring, and emergency response.

Why this incident matters

  • It is a particularly clear multi-chain example of privileged-upgrade abuse where the same root admin surface enabled both direct vault extraction and malicious implementation replacement.
  • The incident is useful as a bridge case between pure upgrade abuse and broader privileged control-plane abuse, because the attacker monetized both admin-only routing functions and code replacement.
  • It also shows why a protocol can be “fully functional” and still catastrophically insecure if its hidden root authority is concentrated in a single wallet.

Internal linkages

  • Core recurring pattern: privileged-upgrade-abuse.
  • Adjacent pattern: signer-quorum-compromise — Wasabi used a single signer rather than a multisig quorum, but the economic lesson is the same: seize the real root authority and the rest of the protocol obeys.
  • Positive-design companion: execution-envelope-identity-pinning — useful when the sharper question is how role grants, upgrades, and privileged routing changes should have committed to exact helper addresses, implementation bytecode, and destination identity before signers could authorize them.
  • Positive-design companion: timelock-action-bundle-commitment — useful when the sharper question is how dangerous admin actions should have been delayed, reviewable, and challengeable instead of compressing compromise and drain into one same-block sequence.

Control surface

Graph View

Backlinks