Giddy hack — April 2026
Incident facts
| Date of incident | |
|---|---|
| Publicly disclosed | April 23, 2026 |
| Target type | Other |
| Loss | $1,300,000Price at time of incident |
| Method | Signature verification flawGiddyVaultV3 authorised swaps with a backend-issued EIP-712 signature, but the signed digest covered only the data field inside the SwapInfo struct. The aggregator address, fromToken, toToken and amount were left outside the hash and were therefore unauthenticated, so a valid historical signature could be replayed with those fields rewritten to point at an attacker-controlled contract and at assets the vault held. |
| Chains | Ethereum |
| Outcome | Unresolved |
What happened
GiddyVaultV3, an Ethereum yield vault operated by Giddy, was drained of approximately $1.3 million on 23 April 2026 through incomplete EIP-712 signature coverage. The vault relied on a backend-issued signature to authorise swaps, but the signed digest covered only the data field inside the SwapInfo struct. The aggregator address, fromToken, toToken and amount sat outside the hash and were never authenticated.
According to separate analyses by BlockSec and Verichains, the attacker took a legitimate authorisation signature from the contract's own transaction history, left the signed data field untouched so that validation still passed, and rewrote the unsigned fields. The aggregator was pointed at a contract the attacker controlled, fromToken was set to gauge tokens held by the strategy, toToken was set to a worthless token, and the amount was set to the maximum value. The vault then called forceApprove using those attacker-supplied parameters, granting the malicious contract an allowance over the vault's own assets, which that contract transferred out. Because the fake toToken satisfied the post-swap balance check, the transaction completed without reverting. BlockSec recorded the vault as 0x5f0a...4318 and the exploit transaction as 0x5edb66...5482e5.
Both firms identify the same root cause: in an approve-then-call architecture, every parameter that determines what the privileged call does, including the call target, the asset and the amount, has to sit inside the signed struct rather than alongside it.
Giddy has not published a post-mortem or public statement. No funds have been reported recovered, no reimbursement has been announced, and nobody has been named as responsible.
Sources
- BlockSecSecondary · retrieved 2026-08-01
- VerichainsSecondary · retrieved 2026-08-01
- RecoverisSecondary · retrieved 2026-08-01
Cite this
This data is published under CC BY 4.0. You may reuse it, including commercially, as long as you credit iTokenly and link back.
iTokenly Hack Registry, "Giddy hack — April 2026", iTokenly, accessed 2026-08-01, https://itokenly.com/hacks/giddyhttps://itokenly.com/hacks/giddyPermalinks never change. If an entry is renamed, the old address keeps working.
Spotted an error? Write to [email protected]. Corrections to published figures are logged on this page. See the methodology for how entries are checked.