Worked example · 2024-01

Socket/Bungee bridge exploit — Ethereum — 2024-01-16

Corrected 2026-10-11: route was added 3 days (not 4) before, losses came from users' approvals to SocketGateway (not the bridge's own approvals); unsupported FixedFloat-funding and Tornado laundering claims softened or removed; dangling Citations keys resolved against CertiK / Blockworks / The Defiant.
Loss: approximately $3.3M at time of exploit, taken from roughly 230 user wallets that had granted token approvals to the SocketGateway contract (about $2.5M of it USDC, per CertiK). The funds were not held in Socket's own contracts; they were users' approved balances.
OAK Techniques observed: OAK-T9.004 (Access-Control Misconfiguration — primary. SocketGateway executed caller-supplied swapExtraData calldata through a route added three days earlier without validating it, so an attacker could make the gateway call transferFrom on tokens that ~230 users had approved to it. The contract spent standing approvals without deriving authority from their owners — the shape of the TAXONOMY-GAPS candidate T9.004.001 (standing-authorisation residue in periphery contracts), alongside Exactly 2023, Gondi and BonfireSwap 2026. See techniques/T9.004-access-control-misconfiguration.md). Not T10.002: no cross-chain message was forged; the drain happened on Ethereum against approvals. Not T9.005: there was no re-entry.
Re-mapped 2026-10-11: primary Technique moved from T10.002 to T9.004-access-control-misconfiguration; merged with the duplicate entry 2024-01-socket-bungee-bridge (which filed it as T9.005).
Attribution: pseudonymous No named individual or group was publicly identified. CertiK's analysis traces the exploiter wallet's gas funding via FixedFloat and an indirect link (through an intermediate address) to a Tornado Cash withdrawal; it reports the stolen USDC/USDT were swapped to ETH and stayed in the exploit wallet at time of writing. No return of funds was found.
Key teaching point: Socket/Bungee is the canonical 2024 worked example of input-validation failure in cross-chain swap-router logic — a bug where an attacker-supplied parameter passed unchecked through the swap execution path, allowing the attacker to redirect swap output to an arbitrary address. The vulnerability was in the SocketGateway contract's handling of the route parameter in swap messages: the contract used a call to execute user-supplied route data without verifying that the route's destination was a registered/permitted swap handler. The attacker called the gateway so that execution reached a newly added route whose performAction used .call() on unvalidated user-supplied swapExtraData, issuing transferFrom against every wallet that had approved the SocketGateway. The incident demonstrates that cross-chain swap protocols have a compound input-validation surface: every user-supplied parameter that controls execution flow (route, swap path, destination address, fee recipient) must be validated against a permitted-values registry.

Summary

Socket Protocol (also known as Bungee) was a cross-chain liquidity aggregation and swap protocol deployed on Ethereum and several other EVM chains. Its SocketGateway contract accepted cross-chain swap messages — users would submit a swap request on a source chain specifying (among other parameters) a route that determined which swap handler contract would execute the swap on the destination chain. The swap handler would then execute the swap (typically through DEX aggregators like 1inch, ParaSwap, or 0x) and send the swap output tokens to the user's specified destination address.

On 2024-01-16, an attacker exploited a critical input-validation omission in the SocketGateway contract's swap execution path. The contract's performAction (or similarly named) function accepted a user-supplied route address and executed a low-level call to that address with user-supplied calldata. The contract did not validate that the route address was one of the permitted swap handlers. Per CertiK's analysis, the attacker (i) called the gateway's fallback with crafted data that reached the newly added route contract, (ii) supplied swapExtraData encoding a transferFrom from a victim wallet to the attacker, and (iii) repeated this for each wallet that had granted the SocketGateway an approval (about 230 wallets), draining roughly $3.3M in USDC, USDT, WETH and other tokens. The loss was therefore funded by users' standing approvals to the gateway, not by the bridge's own holdings. Socket then disabled the route.

The vulnerability was introduced when a contract admin added a new route (an addRoute transaction) about three days before the exploit (around 2024-01-13). The route was meant to extend SocketGateway but its performAction lacked validation of the user-supplied call data.

For OAK's purposes this is T9.004: SocketGateway executed attacker-supplied calldata on a newly added route without checking it, and that calldata spent token approvals users had granted to the gateway. Nothing cross-chain was forged — the drain happened on Ethereum against users' standing approvals, not against bridge-held funds. That makes Socket a member of the periphery-contract approval-spending family (Exactly 2023, Gondi 2026, BonfireSwap 2026) recorded in TAXONOMY-GAPS as candidate T9.004.001, rather than a bridge message-verification case.

Timeline (UTC)

When	Event	OAK ref
~2024-01-13	Socket admin adds a new route to SocketGateway (about three days before the exploit); its `performAction` omits validation of user-supplied `swapExtraData`	T9.004 surface (latent)
2024-01-16	Exploiter wallet funded (CertiK traces gas funding via FixedFloat)	(pre-exploit setup)
2024-01-16	Attacker calls the gateway so execution reaches the new route; injected `swapExtraData` issues `transferFrom` against ~230 wallets with SocketGateway approvals; ~$3.3M drained	T9.004 extraction
2024-01-16	Security firms and Socket itself flag the exploit; users are urged to revoke SocketGateway approvals	(community detection)
2024-01-16	Socket acknowledges the exploit, disables the vulnerable route and pauses affected contracts	(operator response)
2024-01 (days after)	Socket resumes operations after the incident; the date and content of any compensation plan are unverified here	(remediation)
Continuing	No public arrest or return of funds found in sources reviewed	(unrecovered loss)

What defenders observed

The vulnerability was introduced about three days before the exploit by adding a new route. The route's performAction omitted validation of user-supplied call data. The short window between the route addition and the exploit suggests pre-deployment review is the practical intervention point, and argues for a specific defender practice: every upgrade that adds a new user-supplied parameter to an execution path should be tested against a regression suite that includes route-to-unpermitted-address test vectors.
The exploit pattern is structurally identical to Poly Network's toContract overwrite. In both cases: (i) a cross-chain bridge/message protocol accepted a user-supplied address parameter, (ii) the contract's execution logic used that parameter as the target of a call or fund-transfer instruction, (iii) the parameter was not validated against a permitted-values registry, and (iv) the attacker supplied their own contract address, redirecting bridge-held funds. The two incidents are 2.5 years apart (August 2021 to January 2024), and the recurrence of the same vulnerability shape on a different protocol demonstrates that input-validation-on-execution-targets is a standing vulnerability class in cross-chain protocols, not a per-protocol oversight.
Users' standing approvals to the gateway set the blast radius. The injected call executed from the SocketGateway's context, so transferFrom succeeded against any wallet that had approved the gateway. Roughly 230 wallets lost funds; wallets that had revoked their approvals were unaffected. This is why Socket urged users to revoke approvals.
The $3.3M loss is moderate relative to other bridge exploits but the vulnerability class is severe. The Socket exploit netted $3.3M versus the nine-figure losses of Poly Network (~~$611M), Ronin (~~$624M), BNB Bridge (~~$566M), and Wormhole (~~$326M). The smaller scale reflects Socket's lower bridge TVL, not a smaller vulnerability surface. The same vulnerability shape on a bridge with higher TVL would yield proportionally larger extraction. Defenders should evaluate this vulnerability class by its potential extraction ceiling (total bridge TVL under the vulnerable contract) rather than by the realised extraction of any single incident.

What this example tells contributors writing future Technique pages

Unvalidated calldata in a contract that holds users' approvals is the recurring shape. The gateway did not need to hold funds: every wallet that had approved it was exposed to whatever the gateway could be made to call. The control is the same as for any approval-spending periphery contract — derive authority from the token owner, never from caller-supplied parameters — and the user-side mitigation is bounded or one-time approvals.
The Poly Network-to-Socket lineage is a 2.5-year recurrence of the same vulnerability class. Both cases involve a cross-chain message protocol where a user-supplied address parameter controls execution flow and is not validated against a permitted-values registry. The recurrence across 2.5 years, two protocols, and two independent development teams is strong evidence that input-validation-on-execution-targets is a class-level vulnerability attractor in cross-chain protocol design. OAK Mitigations should enumerate "validate all user-supplied execution-target parameters against a permitted-values registry" as a category-level audit-checklist criterion for cross-chain protocols, with Poly Network and Socket as the primary worked-example references.
Contract upgrades that add new user-supplied parameters should be treated as new attack surface until proven otherwise. The Socket vulnerability was introduced by a newly added route, not present in the original deployment. The route added a new execution path with an unvalidated user-supplied parameter (swapExtraData). The roughly 3-day gap between the route addition and the exploit is short, and the fact that the omission was not caught argues that upgrade-review processes at the time did not systematically test new user-supplied parameters against input-validation criteria. Post-Socket, bridge protocol upgrade processes should include a mandatory input-validation checklist for every new user-supplied parameter.

Public references

[theblocksocket2024] — The Block, "Socket says Bungee protocol exploited as funds worth at least $3.3 million appear to be stolen" (2024-01-16): https://www.theblock.co/news/ecosystems/2024-01-16-socket-says-bungee-protocol-exploited-272986
[blockworkssocket2024] — Blockworks, "Socket Tech security breach affects multiple dapps and wallets" (2024-01): https://blockworks.com/news/socket-bridge-protocol-exploit
[certiksocket2024] — CertiK, "Socket Tech Incident Analysis" (2024): https://www.certik.com/resources/blog/socket-tech-incident-analysis
[defiantsocket2024] — The Defiant, "Socket Resumes Operations After Users Lost $3.3M To Exploit" (2024-01): https://thedefiant.io/news/defi/socket-resumes-operations-after-users-lost-usd3-3m-to-exploit

Citations

See Public references: [theblocksocket2024], [blockworkssocket2024], [defiantsocket2024], [certiksocket2024]. The previously listed PeckShield, BlockSec, SlowMist, Socket post-mortem and Rekt entries could not be verified with URLs and were removed.

Discussion

Socket/Bungee was previously filed here as a cross-chain message-verification bypass (T10.002) and compared to Poly Network 2021. The comparison does not hold: Poly Network's attacker forged a cross-chain message to rewrite the bridge's keeper; Socket's attacker sent an ordinary Ethereum transaction whose calldata the gateway executed against users' approvals. The incident is mapped to T9.004 since 2026-10-11 and was merged with a duplicate entry that had filed it as reentrancy (T9.005).

The incident's introduction via a newly added route (about 3 days before exploit) is a specific defender practice issue. Every contract upgrade that adds a new user-supplied parameter controlling execution flow creates a new attack surface. The Socket route-review process did not catch the missing validation, and the exploit occurred within about 3 days — fast enough that pre-upgrade review was the only practical intervention window. Post-Socket, the defensive baseline for bridge protocol upgrades should include a mandatory input-validation checklist for every new user-supplied parameter, with automated regression tests covering route-to-unpermitted-address vectors.

At $3.3M the realised loss was bounded by how much users had approved to SocketGateway, not by any bridge TVL — which is why revoking or bounding approvals, not bridge-side controls, is the mitigation that would have contained it.

Techniques demonstrated (1)

OAK-T9.004 Access-Control Misconfiguration