Worked example · 2024-01

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

Loss: approximately $3.3M at time of exploit (drained from Socket Protocol's Bungee bridge contracts on Ethereum). Industry write-ups (PeckShield, BlockSec, SlowMist) converge on the ~$3.3M figure across ETH and stablecoin positions held in the Socket bridge contracts.
OAK Techniques observed: OAK-T10.002 (Message Verification Bypass — the attacker exploited improper input validation in Socket's cross-chain swap contract that allowed crafting a swap message with a user-controlled route parameter that bypassed the intended destination-address verification) as the extraction mechanism; OAK-T9.004 (Access-Control / Logic Misconfiguration — the vulnerability was an input-validation omission in the swap-router logic: the contract failed to validate that the user-supplied route parameter pointed to a legitimate route rather than an attacker-controlled address, which, when combined with a call-based execution path, allowed the attacker to redirect swap proceeds to their own wallet).
Attribution: pseudonymous The attacker operated through a fresh wallet funded with ETH from a withdrawal from FixedFloat (a non-KYC instant exchange). No named individual or group was publicly identified. A portion of the proceeds was subsequently routed through Tornado Cash and cross-chain bridges, consistent with the standard post-exploit laundering pattern.
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 crafted a route that pointed to a contract they controlled, which executed a transferFrom using the bridge's own token approval to drain assets from the bridge. 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. The attacker exploited this by: (i) deploying a malicious contract at an address they controlled, (ii) crafting a swap message with the route parameter set to the address of their malicious contract, (iii) submitting the swap message to the SocketGateway contract, which executed the call to the attacker's contract, and (iv) the attacker's contract used the bridge's existing token approvals to call transferFrom on the tokens held by the bridge, draining ~$3.3M in ETH and stablecoins to the attacker's address.

The vulnerability was introduced in a contract upgrade on 2024-01-12 — four days before the exploit. The upgrade added new route-parameter handling logic that failed to include the route-whitelist validation that was present in pre-existing execution paths.

For OAK's purposes, the incident sits at the intersection of two Technique IDs. T10.002 (Message Verification Bypass) captures the root cause: the bridge accepted a user-supplied swap message without verifying that the route parameter pointed to a legitimate swap handler. T9.004 (Access-Control / Logic Misconfiguration) captures the specific failure mode: an input-validation check was omitted from the upgrade's new execution path. The Socket case is structurally similar to the Poly Network (August 2021) toContract overwrite exploit — in both cases, a user-controlled parameter in a cross-chain message was not validated against a permitted-values registry, and the bridge's own execution infrastructure was used to redirect funds to an attacker-controlled address.

Timeline (UTC)

When	Event	OAK ref
2024-01-12	Socket Protocol deploys a `SocketGateway` contract upgrade adding new route-parameter handling logic; the upgrade omits route-whitelist validation that existing execution paths enforce	T10.002 + T9.004 surface (latent)
2024-01-16 ~15:00 UTC	Attacker deploys a malicious contract; funds gas wallet via FixedFloat withdrawal	(pre-exploit setup)
2024-01-16 (single tx)	Attacker submits a swap message to `SocketGateway` with `route` set to the malicious contract address; the contract executes a `call` to the malicious contract; the malicious contract calls `transferFrom` using the bridge's token approvals; ~$3.3M in ETH and stablecoins drained	T10.002 + T9.004 extraction
2024-01-16 (within hours)	PeckShield and BlockSec detect the exploit on-chain; publish early-warning alerts	(community detection)
2024-01-16	Socket Protocol team acknowledges the exploit; pauses the affected `SocketGateway` contract; begins incident response	(operator response)
2024-01-17	Socket publishes post-mortem identifying the missing route-validation check as root cause; announces a compensation plan for affected users	(transparency + remediation)
2024-01 onward	Attacker begins laundering proceeds through Tornado Cash and cross-chain bridges (THORChain, FixedFloat); ~$1M routed through Tornado Cash in the first week	T7.001 + T7.003 laundering
Continuing	No public arrest or recovery; Socket continues operations with patched contracts	(unrecovered loss)

What defenders observed

The vulnerability was introduced four days before the exploit via a contract upgrade. The upgrade on 2024-01-12 added new route-parameter handling that omitted a validation check present in other execution paths. The time window between upgrade and exploit (4 days) is short enough that pre-upgrade audit review should have caught the omission, but the fact that the upgrade contained the bug 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.
The attacker's preparation indicated familiarity with the bridge's approval model. The attacker's malicious contract needed to call transferFrom on the bridge's token holdings, which required the bridge's token approvals to be in place. The Socket bridge held standing token approvals for the swap-handler contracts but not for an unregistered address. However, because the call was executed from the bridge contract's own context (via delegatecall or because the bridge contract itself held the token approvals), the attacker could use the bridge's own approval state to move tokens. The exploit assumed (correctly) that the bridge contract held direct token approvals or balances, and that executing a call to an attacker-controlled address from the bridge's context would grant the attacker access to those 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

T10.002 needs explicit sub-classification for input-validation-omission-on-execution-target versus signature-verification-bypass. The Socket exploit shape — a user-supplied address parameter passed unchecked into a call that controls fund flow — is structurally distinct from signature-verification bypass (e.g., a bridge accepting an improperly signed message). Both are T10.002 (the bridge accepted a message it should not have), but the root cause differs: input-validation omission vs. signature-verification logic error. The two sub-classes have different detection surfaces (route-to-whitelist comparison vs. signature cryptographic verification), different mitigations (permitted-values registry vs. signature-scheme audit), and different code-review patterns.
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 in an upgrade, not present in the original deployment. The upgrade added a new execution path with a new user-supplied parameter (route) that was not validated. The 4-day gap between upgrade and exploit is short enough that pre-upgrade review should have caught the omission, but the fact that it 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

[peckshieldsocket2024] — PeckShield post-incident analysis of the Socket/Bungee exploit, including the route-validation omission.
[blocksecsocket2024] — BlockSec transaction-trace breakdown of the Socket exploit chain.
[slowmistsocket2024] — SlowMist forensic analysis of the Socket Protocol exploit.
[socketprotocolpostmortem2024] — Socket Protocol's official post-mortem, including the upgrade timeline and the missing-validation root cause.
[rektnewssocket2024] — Rekt News Socket/Bungee incident write-up.

Citations

[peckshieldsocket2024] — PeckShield Socket forensic.
[blocksecsocket2024] — BlockSec Socket forensic.
[slowmistsocket2024] — SlowMist Socket forensic.
[socketprotocolpostmortem2024] — Socket Protocol post-mortem.
[rektnewssocket2024] — Rekt News Socket incident.

Discussion

Socket/Bungee is OAK's reference case for the input-validation-omission-on-execution-target sub-pattern of T10.002 (cross-chain bridge message-verification bypass). The incident is structurally identical to Poly Network (August 2021): a cross-chain message protocol accepts a user-supplied address parameter that controls fund-execution routing, the parameter is not validated against a permitted-values registry, and the attacker supplies an address pointing to a contract they control, redirecting bridge-held funds. The recurrence 2.5 years and two protocols later demonstrates that input-validation-on-execution-targets is a standing vulnerability class in cross-chain protocol design, not a per-protocol oversight.

The incident's introduction via upgrade (4 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 upgrade-review process did not catch the missing validation, and the exploit occurred within 4 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 loss is the smallest among OAK's T10-class bridge exploit worked examples (compare Poly Network $611M, Ronin $624M, BNB Bridge $566M, Wormhole $326M). The scale difference reflects the bridge's TVL, not the vulnerability surface — the same input-validation omission on a bridge with higher TVL would yield proportionally larger extraction. OAK's assessment of this vulnerability class should use the potential extraction ceiling (total bridge TVL under the vulnerable contract) rather than the realised extraction of any individual incident. The Socket case is the reference that demonstrates that even lower-TVL bridges are exposed to the same class-level vulnerability, and that the audit checklist applies uniformly across T10.002 regardless of bridge size.