Socket / Bungee incident, 2024-01-16
What happened to Socket / Bungee?
On 16 January 2024 an attacker exploited a newly added route in Socket's SocketGateway contract — used by the Bungee aggregator — to pull about $3.3M from roughly 200–230 wallets that had given it infinite token approvals. Socket disabled the route within about 14 minutes; funds in transit were not affected.
Key facts
- Date (UTC)
- Protocol
- Socket Protocol's SocketGateway contract, used by the Bungee bridge aggregator
- Reported loss
- ≈ $3.3M from wallets with infinite approvals to SocketGateway (≈ 200–230 wallets) HalbornCertiKDefiLlama
- Root cause
- Token-approval abuse — a new route's performAction passed unvalidated swapExtraData into a call, letting the attacker inject transferFrom against users' approvals HalbornCertiK
- Chains
- Ethereum
- Recovery
- Partly recovered
- Official post-mortem
- Socket Incident Report 16 Jan
Timeline
All dates and times in UTC.
- 2024-01-13 — New route module goes live (three days before the attack), outside previous audit scope. Halborn
- 2024-01-16 19:03 — Exploiter wallet funded; two exploit contracts deployed and executed against USDC and other approvals. CertiK
- 2024-01-16 — Socket disables the vulnerable route within ≈ 14 minutes of discovery and deploys a fix. Halborn
- 2024-01-18 / 19 — CertiK and Halborn publish analyses. CertiK
Where did the funds go, and was anything recovered?
The vulnerable route was disabled within about 14 minutes and a fix deployed (Halborn). CertiK traced the attacker's gas funding to a 10 BNB Tornado Cash withdrawal (CertiK).
Socket's incident report says the attack hit only wallets with infinite approvals to SocketGateway on Ethereum (Socket). After negotiations the attacker returned 1,032 ETH; Socket announced it would cover the shortfall with $1.1M in USD terms for the 232 affected wallets, claimable by signing a message without granting any approval (Blockworks; The Block). We have not found a notice that all claims were paid.
Which routes and bridges were affected?
Wallets that had granted infinite approvals to SocketGateway were drained; Socket's front-ends default to finite approvals, which limited the victims to roughly 200 (Halborn) or 230 wallets (CertiK). Bridging routes and funds in transit were not the target. The module had gone live three days earlier and was outside the scope of previous audits; Socket attributed it to a pre-review version being deployed by mistake (Halborn).
Our reviews of the bridges involved: Bungee (Socket)
Why did it happen?
SocketGateway is a router that executes a chosen "route" module for each swap or bridge. The new module's performAction took a swapExtraData parameter from the caller and used it directly in a low-level call. Calldata is attacker-controlled, so the attacker encoded a transferFrom(victim, attacker, amount) call, and because the call came from SocketGateway — which victims had approved — the token contract honoured it (Halborn; CertiK). A balance check on the native token did not catch it, because the drained assets were ERC-20s.
The process failure matters as much as the code: per Halborn, the module was three days old, unaudited, and a pre-review version had been deployed by mistake. Socket's fast response (route disabled in about 14 minutes) limited the window, and its finite-approval default limited the blast radius.
This is the same class of bug that hit LI.FI six months later. Aggregator routers hold standing approvals from many users, so every new module is effectively a change to the security of all of them. Pausable modules, enforced review before deployment and default finite approvals are the controls that worked here.
The comparison with intent bridges is useful. In an intent design such as Across, the user deposits a fixed amount for each transfer and no standing approval is needed beyond that transfer; in a router design with infinite approvals, the exposure lasts until the user revokes it. That difference in exposure time, rather than any single bug, is what turned a three-day-old module into a multi-million-dollar loss.
What should users have done then, and what should they do now?
At the time
The protective step was to revoke approvals to SocketGateway on Ethereum immediately after Socket's alert, using a token-approval revoke tool, and not to interact with any "claim" or "refund" site that appeared afterwards unless linked from Socket's official channels.
Now
Use exact-amount approvals for Bungee and any other aggregator, and revoke unused ones. Before bridging, check that the spender address shown in your wallet matches the address in the project's documentation. Note that upswap's Socket/Bungee quote sampling is currently paused while we wait for an API key.
What is still unverified?
- 待核实 Whether every compensation claim was paid (Socket announced the plan; we found no completion notice).
Sources
6 independent publishers. Links checked on the date shown.
- Explained: The Socket Protocol Hack (January 2024) — Halborn · Security firm · checked
- Socket Tech Incident Analysis — CertiK · Security firm · checked
- DefiLlama Hacks — Socket, 2024-01-16 — DefiLlama · Database · checked
- Socket Incident Report 16 Jan — Socket · Official · checked
- Socket bridge victims will be made whole — Blockworks · Media · checked
- Socket says it recovered 1,032 ETH following Bungee exploit last week — The Block · Media · checked
How do I cite this page?
Burn, A. / upswap.io (2026). Socket / Bungee incident (2024-01-16). Updated 2026-10-24. https://upswap.io/incidents/bungee-2024#summary. CC BY 4.0. Accessed ____.
Stable anchors: #summary #facts #timeline #funds #affected #analysis #then #now #sources #cite