Matcha Meta / SwapNet Aggregator Arbitrary-Call Exploit (January 25, 2026)
- Date
- 2026-01-25
- Loss
- $13.4M
- Category
- DeFi aggregator exploit (approval abuse / arbitrary call)
- Attack vector
- An arbitrary-call vulnerability in SwapNet's closed-source aggregator router: unverified function 0x87395540() made a low-level call to a user-supplied address with user-controlled calldata and no target whitelist. By naming a token such as USDC as the call target and crafting transferFrom() calldata, the attacker abused victims' standing infinite approvals to the router to sweep balances across Ethereum, Arbitrum, Base, and BNB Chain.
- Attribution
- Analysts (AMLBot, BlockSec, Verichains, ExVul, CertiK) tied the operation to a sophisticated threat cluster specializing in infinite-approval abuse; a secondary/copycat address holding roughly $3.2M was funded via Tornado Cash more than a year earlier and overlapped on-chain with the Li.Fi/Jumper Exchange attacker network. No named individual or state actor was attributed. Matcha Meta is built by 0x, whose AllowanceHolder and Settler contracts were unaffected.
Overview
On January 25, 2026, users of Matcha Meta, the DeFi exchange meta-aggregator built by 0x, lost approximately $13.43M when an attacker exploited an arbitrary-call vulnerability in SwapNet, one of the third-party DEX aggregators wired into the Matcha Meta routing stack. The loss was highly concentrated: roughly 20 users were drained (the post-mortem later revised the confirmed count to 18), and a single account lost about $13.34M, meaning one victim accounted for the overwhelming majority of the total. Crucially, the incident did not touch 0x's own AllowanceHolder or Settler contracts, which secure the platform's default One-Time Approval flow and route roughly 90% of Matcha Meta transactions. The victims were exclusively users who had manually disabled One-Time Approval and instead granted infinite, direct token allowances to SwapNet's closed-source router contracts. The bug lived in an unverified function, 0x87395540(), which performed a low-level call to a user-supplied target with user-controlled calldata and no whitelist on the destination address. By substituting a token address such as USDC for the expected DEX router or pool, the attacker coerced the SwapNet contract into calling transferFrom() against victims who had pre-approved it, sweeping their balances. The exploit spread across Ethereum, Arbitrum, Base, and BNB Chain before SwapNet paused its Base contracts roughly 45 minutes after the first drain and halted the remaining chains shortly after. A near-identical arbitrary-call flaw hit Aperture Finance in the same window, pushing early combined loss estimates toward $17M and briefly muddying the SwapNet figure at $16.8M. Matcha Meta removed SwapNet as an aggregator, disabled the ability to turn off One-Time Approval, and forced all trades back through AllowanceHolder. The stolen funds were rapidly consolidated on Base and bridged to Ethereum via Relay and Superbridge, with analysts linking the operation to a threat cluster that specializes in infinite-approval abuse.
Timeline of events
The attack unfolded on January 25, 2026, beginning at approximately 17:10 GMT. On Base, on-chain reconstruction places an initial approval-style transaction at block 41,289,829, with the drain itself commencing twelve blocks later at block 41,289,841. From that entry point the attacker moved methodically, replicating the exploit against additional pre-approved users and fanning out across Base, Ethereum, Arbitrum, and BNB Chain. SwapNet detected the anomaly and paused its Base contracts roughly 45 minutes after the initial exploit, then halted the remaining chains shortly afterward, ending the active draining window. Matcha Meta publicly acknowledged the incident at about 21:47 GMT the same day, initially describing it as a security incident tied to an integrated aggregator and advising users to revoke approvals to individual aggregators as a precaution. Security firms weighed in within hours: CertiK sized the SwapNet loss at roughly $13.3M, while PeckShield's early $16.8M figure conflated SwapNet with the simultaneous roughly $3.4M Aperture Finance exploit. BlockSec published a bytecode-level technical analysis on January 28, and Matcha Meta released a formal SwapNet Incident Post Mortem on January 27, updating the confirmed affected-user count on January 29 to 18. The largest single victim, who lost about $13.34M, dominated the aggregate; the remaining losses were spread across a small set of accounts on three additional chains.
Attack mechanism
SwapNet's router contracts were closed-source, so analysts at BlockSec, Verichains, and ExVul reconstructed the flaw from decompiled bytecode. The vulnerable entry point was function 0x87395540(), which handled swap routing and, in the course of executing a trade, performed a low-level call to an address supplied in the transaction's calldata using further attacker-controlled calldata. The decompiled logic set a target-address variable (labeled v75 in Verichains' reconstruction) directly from user input, with no check that the destination was a legitimate DEX router or pool. Because the SwapNet router already held infinite ERC-20 approvals from the victims, an attacker did not need the victims' signatures or private keys; they only needed the router to make a call on their behalf. The attacker therefore set the call target to a token contract, with USDC as the canonical example, and crafted the calldata to invoke transferFrom(victim, attacker, amount). From the token's perspective the caller was the approved SwapNet router, so the transfer succeeded and the victim's balance was swept to the attacker. On the largest leg, roughly $10.5M of USDC was drained and immediately swapped into about 3,655 ETH. The same closed-source pattern, a user-controlled low-level call inside a contract holding standing approvals, was what made Aperture Finance's parallel exploit possible, in that case via function 0x67b34120() calling internal helper 0x1d33() to drain assets such as WBTC after a token-address substitution.
Root cause analysis
The root cause was insufficient input validation on a privileged execution path, compounded by a closed-source design that delayed external scrutiny. A contract that holds token approvals is, in effect, a custodian of user funds for the assets it can move; allowing that contract to make a low-level call to any address with any calldata converts a routing convenience into an arbitrary-call primitive. Two validation failures combined. First, there was no whitelist constraining the call target to known-good router or pool addresses, so a token contract could be named as the destination. Second, there was no constraint on the function selector or arguments of the outbound call, so transferFrom() could be invoked with attacker-chosen parameters. Either check alone would likely have blocked the exploit. The design decision that put users in harm's way was the option to bypass 0x's AllowanceHolder: Matcha Meta's post-mortem framed direct infinite approvals to aggregators as granting too much power at the expense of security. The default One-Time Approval flow, which routes spend authority through 0x's audited AllowanceHolder contract and covers roughly 90% of platform volume, was never at risk; the roughly 10% of users who opted out of it and approved SwapNet directly bore the entire loss. Closed-source bytecode meant the flaw could not be caught by ordinary public review and had to be decompiled into thousands of lines of nested branching before it could be understood.
Initial response and containment
SwapNet's on-chain response was fast relative to the exploit's spread. Roughly 45 minutes after the first drain the team paused its Base contracts, then paused the deployments on the remaining chains shortly after, which closed the active draining window. Matcha Meta and 0x moved to contain the platform-level exposure rather than the SwapNet contracts they did not control: they removed SwapNet as an available aggregator, disabled the user setting that allowed One-Time Approval to be turned off, and forced all Matcha Meta transactions back through the 0x AllowanceHolder contract. 0x was explicit that its own AllowanceHolder and Settler contracts were never implicated, isolating the failure to the third-party aggregator integration. The company urged all users, not only confirmed victims, to review and revoke standing approvals granted directly to individual aggregators, since the exposure was a function of lingering infinite allowances rather than any ongoing platform compromise. Matcha Meta said it was working with security firms and industry partners to collect data and trace the stolen funds. Notably, the disclosures did not commit to reimbursing affected users; as of the immediate aftermath, no insurance fund, treasury backstop, or compensation program had been announced, leaving the losses, dominated by the single roughly $13.34M account, with the victims pending any recovery from tracing efforts.
Funds tracking and laundering
On-chain tracers, including AMLBot, mapped a professional-grade laundering route. Proceeds were consolidated on Base at a primary hub address (0x6cAad74121bF602e71386505A4687f310e0D833e), where non-ETH assets were swapped into ether and roughly 3,655 ETH was staged. Notably, about $3M in USDC was left untouched at the hub, consistent with the attacker avoiding a stablecoin issuer's freeze capability. From Base, funds were bridged to Ethereum mainnet using Relay Protocol and Superbridge, then dispersed into fresh intermediary wallets that subsequently sat dormant, drawing only third-party address-poisoning spam. Investigators flagged a secondary, copycat address cluster, including a wallet holding about $3.2M, whose funding traced back through Tornado Cash more than a year earlier and overlapped on-chain with the threat network behind the Li.Fi and Jumper Exchange exploit, pointing to a sophisticated actor group that specializes in infinite-approval vulnerabilities rather than an opportunistic newcomer. Because the bulk of the loss was a single victim's large USDC and blue-chip positions, the laundering was concentrated rather than fragmented across many small accounts, and the decision to hold rather than immediately cash out the USDC left a meaningful portion of value visibly parked, giving tracers and cooperating venues potential choke points. No public freeze or clawback had been confirmed in the immediate aftermath, and the primary balances remained under monitoring for centralized-exchange deposit attempts.
Recovery and remediation
Recovery prospects were mixed and, for the largest victim, unresolved. The concrete remediation was architectural and preventive rather than restitutive: Matcha Meta eliminated the direct-approval pathway entirely, so users can no longer disable One-Time Approval and every trade routes through 0x's AllowanceHolder, which grants only transient, exact-amount spend authority instead of standing infinite allowances. SwapNet's paused contracts and removal from the aggregator set foreclosed further exploitation of the same code. The broader lesson embedded in the fix is that revoking or never granting infinite approvals is the user-side control that would have neutralized the attack: victims were exposed precisely because a dormant, unlimited allowance persisted long after the trade that created it. Security firms recommended that any router performing low-level calls maintain a strict whitelist of valid targets, validate function selectors, and separate approval-spender validation from execution-target validation, alongside open-sourcing contracts so the community can review privileged call paths before they are exploited. On the funds themselves, tracing continued through AMLBot and others, but with the proceeds bridged, partly converted to ETH, and dispersed into dormant wallets, and with no announced compensation program, the realistic recovery path narrowed to law-enforcement action or a voluntary return, neither of which had materialized in the weeks after the incident.
Industry implications
The SwapNet exploit crystallized several lessons about the aggregator era of DeFi. First, meta-aggregation multiplies trust surface: Matcha Meta's own contracts were sound, but routing users through third-party aggregators imported those aggregators' code risk, and a single integrated component's flaw became the platform's headline loss. Second, it was a stark demonstration that infinite token approvals are a latent, transferable liability: a signature granted once can be weaponized indefinitely by anyone who finds an arbitrary-call bug in the approved contract, independent of the user's keys. Weilin Li, a DeFi security researcher, characterized it as the largest approval attack he had seen excluding phishing. Third, the near-simultaneous Aperture Finance exploit using the identical pattern showed this was a class of vulnerability, not a one-off, and that closed-source router contracts are especially dangerous because the flaw hides in bytecode that only decompiles into thousands of lines of obfuscated logic. Fourth, the incident reinforced the value of secure defaults: 0x's AllowanceHolder design protected roughly 90% of users automatically, and the loss fell almost entirely on those who opted out, an argument for removing insecure options rather than merely warning against them. The event fed into a broader 2025 to 2026 narrative of rising approval-abuse and router-injection attacks across DeFi front-ends and aggregators.
Verdict and lessons
The Matcha Meta / SwapNet incident is a textbook arbitrary-call approval attack: a closed-source router holding infinite ERC-20 allowances exposed a low-level call with an unvalidated target and calldata, letting an attacker turn users' standing approvals into transferFrom() drains for about $13.43M, nearly all of it from one account. The failure was not cryptographic and not in 0x's audited contracts; it was ordinary missing input validation on a privileged execution path, magnified by a design that let users trade away a secure default for convenience. The lessons are concrete. First, contracts that hold approvals must whitelist call targets and constrain selectors, never allowing an arbitrary address and calldata combination on a path that can move approved tokens. Second, users and interfaces should treat infinite approvals as a persistent risk and prefer exact-amount, per-transaction authority; a granted allowance outlives the trade that created it. Third, secure defaults should be enforced, not optional: the safest posture is to remove the ability to disable protection, which is exactly what Matcha Meta did after the fact. Fourth, closed-source contracts in the critical path deserve heightened scrutiny, since the review that might catch such a bug cannot happen publicly. Finally, aggregators and meta-aggregators must own the risk of the integrations they route through, because to the user the loss is indistinguishable from a failure of the platform itself.
Recovery
No user compensation, insurance backstop, or on-chain clawback was announced in the immediate aftermath; the ~$13.43M loss, dominated by one ~$13.34M account, remained with victims pending tracing. Remediation was preventive: Matcha Meta removed SwapNet as an aggregator, disabled the option to turn off One-Time Approval, and forced all trades through 0x's AllowanceHolder. Proceeds were consolidated on Base, partly swapped to ~3,655 ETH, and bridged to Ethereum via Relay and Superbridge into dormant wallets; ~$3M USDC was left parked, likely to avoid a freeze. Tracing continued but no funds had been recovered.
Key lessons
- Contracts that hold token approvals must whitelist call targets and constrain function selectors; never allow arbitrary address-plus-calldata on a path that can move approved tokens
- Infinite approvals are a latent risk that outlives the trade that created them; prefer exact-amount, per-transaction spend authority and revoke dormant allowances
- Secure defaults should be enforced, not optional; removing the ability to disable protection (as Matcha Meta did after the fact) prevents users from trading away safety
- Closed-source contracts in the critical path deserve heightened scrutiny because the community review that might catch such bugs cannot happen publicly
- Meta-aggregators inherit the code risk of every integration they route through; to users, a partner's flaw is indistinguishable from a platform failure
Frequently asked questions
What happened in the Matcha Meta / SwapNet Aggregator Arbitrary-Call Exploit?
On January 25, 2026, an arbitrary-call bug in SwapNet, a closed-source DEX aggregator integrated into 0x's Matcha Meta, let an attacker drain ~$13.43M from about 20 users (revised to 18), with one victim losing ~$13.34M. Unverified function 0x87395540() made a low-level call to a user-supplied target with no whitelist, so naming a token like USDC and crafting transferFrom() calldata weaponized victims' standing infinite approvals across Ethereum, Arbitrum, Base, and BNB Chain. 0x's AllowanceHolder and the default One-Time Approval flow (~90% of users) were unaffected; only users who disabled it and approved SwapNet directly were hit. SwapNet paused Base ~45 minutes in; Matcha Meta removed SwapNet and disabled the opt-out. Funds were bridged Base to Ethereum via Relay/Superbridge with no compensation announced; a near-identical Aperture Finance exploit hit at the same time.
How much was lost?
Approximately $13.4M was lost on 2026-01-25.
How did the attack work?
An arbitrary-call vulnerability in SwapNet's closed-source aggregator router: unverified function 0x87395540() made a low-level call to a user-supplied address with user-controlled calldata and no target whitelist. By naming a token such as USDC as the call target and crafting transferFrom() calldata, the attacker abused victims' standing infinite approvals to the router to sweep balances across Ethereum, Arbitrum, Base, and BNB Chain.
Who was responsible?
Analysts (AMLBot, BlockSec, Verichains, ExVul, CertiK) tied the operation to a sophisticated threat cluster specializing in infinite-approval abuse; a secondary/copycat address holding roughly $3.2M was funded via Tornado Cash more than a year earlier and overlapped on-chain with the Li.Fi/Jumper Exchange attacker network. No named individual or state actor was attributed. Matcha Meta is built by 0x, whose AllowanceHolder and Settler contracts were unaffected.
Were the funds recovered?
No user compensation, insurance backstop, or on-chain clawback was announced in the immediate aftermath; the ~$13.43M loss, dominated by one ~$13.34M account, remained with victims pending tracing. Remediation was preventive: Matcha Meta removed SwapNet as an aggregator, disabled the option to turn off One-Time Approval, and forced all trades through 0x's AllowanceHolder. Proceeds were consolidated on Base, partly swapped to ~3,655 ETH, and bridged to Ethereum via Relay and Superbridge into dormant wallets; ~$3M USDC was left parked, likely to avoid a freeze. Tracing continued but no funds had been recovered.