$17M Closed-Source Smart Contract Exploit: Arbitrary-Call Vulnerability in SwapNet and Aperture Finance

$17M Closed-Source Smart Contract Exploit: Arbitrary-Call Vulnerability in SwapNet and Aperture Finance

On January 25, 2026, we detected a series of suspicious transactions targeting victim contracts deployed by SwapNet and Aperture Finance across Ethereum, Arbitrum, Base, and BSC, with total losses exceeding $17 million. At a high level, the root cause of both incidents is straightforward and was already outlined in our initial alerts [1, 2]: the victim contracts expose an arbitrary-call capability due to insufficient input validation, allowing attackers to abuse existing token approvals and invoke transferFrom to drain assets.

However, both sets of victim contracts are closed-source and, once decompiled, expand into thousands of lines of code with deeply nested and complex branching logic, significantly increasing the difficulty of analysis. Moreover, the subsequent post-mortems released by the affected projects [3, 4] primarily focused on remediation and recovery, with limited discussion of the underlying technical details. As a result, several important questions remain unanswered, including how the vulnerable call paths were constructed and why existing checks failed to prevent exploitation.

In this report, we provide a more detailed technical analysis based on decompiled bytecode and on-chain execution traces. While the lack of source code limits visibility, the bytecode-level analysis is sufficient to reconstruct the vulnerable logic and reveals several interesting observations about the contract design that are not immediately apparent from the high-level alerts.

We begin with a deep dive into the SwapNet incident, followed by a detailed analysis of the Aperture Finance incident.


SwapNet Incident

Background

SwapNet [5] is a DEX aggregator designed to find optimal swap routes by aggregating liquidity from multiple onchain sources, including AMMs and private market makers. The protocol also allows users to specify custom routers or pools when executing swaps, offering additional flexibility.

Root Cause Analysis

This incident stems from insufficient validation of user-supplied inputs, which allows an attacker to trigger transferFrom() calls with arbitrary parameters. As a result, assets that had been previously approved to the victim contracts (e.g., 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e) could be transferred to the attacker.

Based on decompiled bytecode, the function 0x87395540() appears to lack proper validation on critical inputs. By replacing the expected router or pool address with a token address (e.g., USDC), the contract incorrectly treats the token as a valid execution target. This leads to a low-level call being executed with attacker-controlled calldata.

Consequently, the victim contract performs calls of the form: approvedAsset.transferFrom(victim, attacker, amount), allowing the attacker to siphon all approved assets.

Attack Flow

Multiple attacks were observed against SwapNet. Here we use the Base transaction 0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57 as an example.

The attacker simply invoked the function 0x87395540() of the victim contract with malicious inputs. This invocation consists of two main steps.

  1. A key internal variable (e.g., v51) was set to USDC, bypassing intended routing logic.
  1. A low-level call was executed using attacker-controlled calldata, resulting in USDC.transferFrom() being invoked and all approved USDC being drained.

Loss Summary, Transactions, and Affected Contracts

The SwapNet incident caused an estimated ~$13.41M loss across multiple chains. The tables below summarize key exploit transactions and the victim contract addresses involved.


Aperture Finance Incident

Background

Aperture Finance [6] is a DeFi protocol that manages concentrated liquidity positions, such as Uniswap V3 LPs, on behalf of users. Its closed-source contracts (e.g., 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913) allow users to mint and manage Uniswap V3 positions using native tokens.

Intended Workflow for Minting UniswapV3 Positions

When minting Uniswap V3 positions via the 0x67b34120() function, the contract follows an intended three-step workflow:

  1. Wrap native tokens

  2. Swap native tokens via the internal function 0x1d33()

  3. Mint UniswapV3 positions

The issue arises in Step 2: 0x1d33() performs a customized swap through a low-level call, where critical parameters (e.g., the call target and calldata) appear to be user-controlled and insufficiently validated, enabling unintended external calls. More details are provided in the following sections.

Root Cause Analysis

Similar to the SwapNet case, the Aperture Finance incident is caused by insufficient input validation on low-level calls. When 0x67b34120() is invoked, the internal function 0x1d33() executes a low-level call using calldata supplied by the user, without enforcing strict constraints on the call target or function selector.

As shown in the figure below, the calldata used to trigger the low-level call is purely based on the attacker's inputs.

This enables attackers to construct malicious calldata that results in: approvedToken.transferFrom(victim, attacker, amount) executed in the context of the victim contract. As a result, not only ERC20 tokens but also approved Uniswap V3 position NFTs can be siphoned.

Attack Flow

Multiple attacks were observed against Aperture Finance. In this section, we use the Ethereum transaction 0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a as a representative example.

  1. The attacker created an attack contract 0x5c92884dFE0795db5ee095E68414d6aaBf398130.

  2. The attack contract invoked the function 0x67b34120() with malicious inputs and 100 wei ETHs (i.e., msg.value == 100).

  • a) The native ETHs was wrapped into WETHs via the function WETH.deposit().
  • b) The internal function 0x1d33() was invoked to perform a low-level call. In this step, a call of WBTC.transferFrom(victim, attacker, amount) is invoked in the context of the victim contract, allowing the attacker to siphon approved tokens. It is worth noting that a balance check was passed at the end of the function 0x1d33(). Specifically, the function 0x1d33() compared the balance changes with the a swap output value (i.e., varg2.word2) specified by the attacker as well. As a result, were executed successfully by receving nothing.
  1. Lastly, the function NonfungiblePositionManager.mint()was invoked to mint a position for the attacker using 100 wei WETH.

Interesting Findings

By comparing normal and abnormal minting transactions, we observed that both approved tokens to the same spender (e.g., OKX DEX: TokenApprove) but specified different router addresses (i.e., DexRouterand WBTC). This suggests that the contract may enforce validation on the approval spender while failing to validate the actual execution target, leaving a critical gap exploitable via arbitrary calls.

Normal transaction: https://app.blocksec.com/phalcon/explorer/tx/eth/0xc823b703c716fa9078e1d71714b734557bd540ddd1e41590dd73da7c5aba0200

Abnormal transaction: https://app.blocksec.com/phalcon/explorer/tx/eth/0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a

Loss Summary, Transactions, and Affected Contracts

The Aperture Finance incident resulted in an estimated total loss of ~$3.67M across multiple chains. The tables below summarize key exploit transactions and the associated victim contract addresses.


Conculsion

Although the SwapNet and Aperture Finance incidents affected different protocols and chains, the underlying issue in both cases is not complex: user-controlled low-level calls combined with insufficient input validation in contracts holding token approvals. These incidents serve as a reminder that flexibility in contract design must be carefully balanced with strict call constraints, especially in closed-source systems where external review is limited.

Reference

[1] https://x.com/Phalcon_xyz/status/2015614087443697738

[2] https://x.com/Phalcon_xyz/status/2015624519898234997

[3] https://meta.matcha.xyz/SwapNet-Incident-Post-Mortem

[4] https://x.com/ApertureFinance/status/2015938720453820752

[5] https://x.com/0xswapnet

[6] https://x.com/ApertureFinance

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.

Sign up for the latest updates