Attacker: Unknown EOA 0x6e523866424220b3cb2cab88ba2195cfa5636b12 had taken over the Yapeswap DAO's control of the YapeFactory (0x46adc1c052fafd590f56c42e379d7d16622835a2). In this tx it used that control to pull the Yearn-farmed reserves of the first six Yapeswap pairs out of real Yearn vaults and into fake "vaults" its own contracts deployed.

Loss: About $22.0k reached the attacker contract 0x327bf6dfc38a79393f78866c705193c39b04be01 in this tx: 1,613 DAI, 1,607 USDC, 7,705 USDT, 4.205 WETH and 0.0141 WBTC. Counting the follow-up batch 0xf6af7db8… and the sweep 0x0eeaa8fd…, the attacker contract took in about $39.7k, which all ended up as 10.52 ETH in the attacker EOA. The losers are Yapeswap liquidity providers.

Root cause: an attacker-passed DAO timelock proposal ran a factory admin setter (a2e74af6) naming the attacker EOA. The EOA then set the factory's operator, registry and feeTo. The pairs' public updateRegistry() copied the attacker's fake registry with no validation, and rebalance() deposited reserves into whatever vault that registry returned.

What happened

• Earlier setup (other txs). On 10-16 the attacker swapped ETH for VISION (0x757bc268…), locked it with createLockUntil in the Yapeswap Voting Escrow (0x4b9500be…), called delegate, and called proposeTx(target=YapeFactory…) on governance/timelock contract 0x5d35809b…. A second call to 0x5d35809b… followed on 10-17 (selector bccd99e6, not decoded), schedule on 10-24, and execute at 02:15:47 on 10-25. The executed payload was YapeFactory a2e74af6(0x6e523866…): an admin setter handing the factory to the attacker EOA.
• In block 26266649 the attacker deployed 0x327b… (which deployed the fake registry 0xc620… and the fake vaults 0x5ec9…, 0x27a8…, 0xde16…, 0x6f88…). It then called the factory's setOperator(0x327b…), setRegistry(0xc620…) and setFeeTo(0x327b…).
• In this tx, 0x327b… looped over the pairs. For each one it called updateRegistry() (pair slot 0x11 changed from the real Yearn registry 0x50c1a2ea… to 0xc620…), then setFarmingRatio as operator (max ratio 8000→10000), then rebalance().
• rebalance withdrew the pair's yvDAI, yvUSDC, yvWBTC and yvWETH positions from genuine Yearn v2 and v3 vaults and deposited the assets into the fake vaults returned by latestVault(). Fees went to feeTo, which is the attacker contract.
• Follow-up tx 0xf6af7db8… repeated the loop for pairs 6–12 (~$2.85k more), and 0x0eeaa8fd… swept the rest. 10.52 ETH now sits in the attacker EOA.

Why this matters

This is a governance takeover turned into an asset redirect. The DAO's authority over the factory was captured with a recently bought and locked governance-token position. It was then used to point every pair's yield-farming at attacker-controlled sinks, so LP-owned reserves left through the protocol's own rebalance path.

Root cause

File: contracts/core/YapePair.sol
Function: updateRegistry() / rebalance() (factory admin set via DAO timelock)
Vulnerability class: access-control (governance capture drove privileged factory setters)
Broken invariant: Yapeswap assumed the factory registry and operator could only be changed by a broad, durably-aligned DAO majority, and that the registry always lists genuine Yearn vaults. The attacker bought and locked VISION, passed its own timelock proposal making itself factory admin, and installed a fake registry that the pairs trusted blindly.
Mechanism: YapePair.sol L57-58, function updateRegistry() public { _registry = IYapeFactory(factory).registry(); }, is callable by anyone and copies the registry unvalidated. L61 setFarmingRatio(...) external onlyOperator admitted the attacker contract once it was the factory operator. rebalance() (L81) then withdrew from real Yearn vaults and deposited into the fake registry's latestVault().

Context

The attacker EOA is 11.5 days old with 6 txs, funded by unlabelled 0x003106de…. The factory deployer is labelled 0xmayflower.eth (warehouse flag: Tornado Cash recipient); it is not linked to the attacker in the evidence.