LixirPermitDrain exploit analysis

Lixir vault tokens implemented EIP-2612 permits with a weak signature check: a permit submitted with an invalid signature was treated as valid so long as ecrecover returned any nonzero address. The attacker could therefore sign a permit that authorised the attacker's own address with no valid signature, invoke permit() on every Lixir vault, and then call transferFrom() to drain each holder's full vault-token balance.

The attacker at 0x3Fa8cF7FeA68C8E76A9838d77889464DdFb6a6cf used the historical attack contract 0xEFd1b12F5E3c35D7daE0D1449674C247566f9b76 to call permit() against six vault-token contracts (LV_WETH_USDC_A, LV_LIX_WETH_A, LV_WETH_USDC_B, LV_LIX_WETH_B, LV_USDC_USDT_A, LV_USDC_USDT_B) and then drained them via transferFrom() from the targeted holders.

DeFiHackLabs reports a total loss of 2.60 ETH, 4,477.72 USDC, 3,609.95 USDT, and 24,182.56 LIX across those six vaults. The drain is in 0x17026faca0b8e4cb7531e4fb277c390eb165e81229628e0192923ad1d90a41da on Etherscan. The vulnerabilities read against the verified vault-token sources.

What would have prevented it: rejecting permit() calls where ecrecover returns the zero address, the standard condition OpenZeppelin's signature verifier already enforces. Adding a require on recovered != address(0) would have closed this without changing any valid-permit behaviour.