DePayRouterV1 Exploit — Output-Only Balance Check + Repeated Plugin Execution Drains Router Funds

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2023-10-DePayRouter_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/DePayRouter_exp.sol.

Vulnerability classes: vuln/logic/missing-check · vuln/logic/incorrect-order-of-operations · vuln/access-control/missing-auth

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that do not whole-compile, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable sources: DePayRouterV1.sol and the swap plugin DePayRouterV1Uniswap01.sol.

Key info#

TL;DR#

DePayRouterV1.route() is a generic "swap-and-pay" router. It pulls in the input token once, runs a caller-supplied list of plugins, then checks only that the balance of the last token in the path did not go down (DePayRouterV1.sol:759-763).

Three composable design flaws turn that into a free drain of any token the router happens to be holding:

1. The post-condition check only protects path[last] (the output token), not path[0] (the input token) or any token the router custodies. A swap that consumes the router's own USDC passes the check as long as the (attacker-controlled) output token balance does not decrease.
2. plugins is a caller-supplied array that _execute() loops over with no de-duplication and no per-plugin accounting (:791-808). Passing the same Uniswap swap plugin twice performs two swapExactTokensForTokens(amounts[0], …) calls, each spending amounts[0] of the input token — but _ensureTransferIn() only collected amounts[0] once. The second swap is funded entirely by USDC that was already sitting in the router.
3. The output token and its liquidity pool are 100% attacker-controlled. The attacker mints a fake ERC-20, seeds a FakeToken/USDC Uniswap pair with 1e30 : 1 reserves, and routes USDC → FakeToken through it. Because the fake side is a near-infinite reserve and the USDC side is 1 wei, every swap dumps the router's USDC into a pool the attacker fully owns — then removeLiquidity() hands it all back.

Net: the attacker recovers the router's idle 877.96 USDC, paying only a Uniswap flash-loan fee of ~7.04 USDC, for +870.92 USDC profit in a single atomic transaction.

Background — what route() is supposed to do#

DePay is a crypto-payments protocol. DePayRouterV1.route() lets a payer hand over tokenIn, have it swapped on a DEX, and forward tokenOut to a merchant — all in one call, via a pluggable processor pipeline:

function route(
  address[] calldata path,     // e.g. [USDC, DAI]
  uint[]    calldata amounts,  // e.g. [amountIn, amountOut, deadline]
  address[] calldata addresses,// e.g. [receiver]
  address[] calldata plugins,  // ordered plugin list, e.g. [Uniswap, Payment]
  string[]  calldata data
) external payable returns(bool) {
  uint balanceBefore = _balanceBefore(path[path.length-1]); // ← snapshot OUTPUT token only
  _ensureTransferIn(path[0], amounts[0]);                   // ← pull INPUT token ONCE
  _execute(path, amounts, addresses, plugins, data);        // ← run EVERY plugin in the list
  _ensureBalance(path[path.length-1], balanceBefore);       // ← OUTPUT token must not decrease
  return true;
}

DePayRouterV1.sol:743-764

The only swap plugin involved here is DePayRouterV1Uniswap01, executed by delegatecall (it declares delegate = true). For a non-ETH path it simply calls:

IUniswapV2Router02(UniswapV2Router02).swapExactTokensForTokens(
  amounts[0],   // input amount  ← re-read on every plugin execution
  amounts[1],   // amountOutMin (= 0 here)
  uniPath,      // path
  address(this),// recipient = the router (because of delegatecall)
  amounts[2]    // deadline
);

DePayRouterV1Uniswap01.sol:521-529

Because the plugin runs under delegatecall, address(this) is the router, so the swapped-out tokens land in the router and the swapped-in tokens are pulled from the router's balance.

The vulnerable code#

1. Input token is collected once, but plugins run as many times as the caller asks#

function _ensureTransferIn(address tokenIn, uint amountIn) private {
  if(tokenIn == ETH) {
    require(msg.value >= amountIn, 'DePay: Insufficient ETH amount payed in!');
  } else {
    Helper.safeTransferFrom(tokenIn, msg.sender, address(this), amountIn);  // ← ONE pull of amounts[0]
  }
}

function _execute(...) internal {
  for (uint i = 0; i < plugins.length; i++) {            // ← unbounded, no de-dup
    require(_isApproved(plugins[i]), 'DePay: Plugin not approved!');
    IDePayRouterV1Plugin plugin = IDePayRouterV1Plugin(configuration.approvedPlugins(plugins[i]));
    if(plugin.delegate()) {
      (bool success, bytes memory returnData) = address(plugin).delegatecall(abi.encodeWithSelector(
        plugin.execute.selector, path, amounts, addresses, data));   // ← each call re-spends amounts[0]
      require(success, string(returnData));
    } else { ... }
  }
}

DePayRouterV1.sol:775-808

Nothing prevents plugins = [SwapPlugin, SwapPlugin]. Each iteration calls swapExactTokensForTokens(amounts[0], …) and spends amounts[0] of the router's USDC. With amounts[0] = 877,961,918 collected once, two iterations spend 2 × 877,961,918. The extra 877,961,918 comes from USDC already custodied by the router.

2. The post-condition only protects the output token#

function _ensureBalance(address tokenOut, uint balanceBefore) private view {
  require(_balance(tokenOut) >= balanceBefore, 'DePay: Insufficient balance after payment!');
}

DePayRouterV1.sol:810-814

tokenOut is always path[path.length-1]. The attacker sets it to a fake token they minted, so the swaps increase the router's fake-token balance and the check passes trivially. The router's USDC balance is never compared — it can be drained to zero and route() still returns true. The comment above the function — "Prevents draining of the contract" — describes an invariant the code only enforces for one of the path's two tokens.

3. The plugin recipient is the router, and the output pool is attacker-owned#

Under delegatecall, the plugin's swapExactTokensForTokens(..., address(this), ...) deposits output to and pulls input from the router. The attacker chooses the swap pool: a freshly created FakeToken/USDC Uniswap V2 pair seeded 1e30 FakeToken : 1 wei USDC, so swapping ~878 USDC in returns ~1e30 fake tokens — a worthless output the attacker discards, used only to satisfy the output-balance check while sweeping the USDC the router will pay in.

Root cause#

The router enforces "the OUTPUT token balance must not decrease" but never enforces "no other token I custody may decrease", and it executes a caller-controlled, un-deduplicated plugin list that re-spends amounts[0] on every iteration while only collecting it once.

Concretely, the four decisions that compose into the drain:

1. Output-only balance guard. _ensureBalance checks path[last] only. Any token the router holds — including its own idle USDC, or path[0] — is unprotected. By making path[last] a token the attacker controls, the guard is neutered.
2. Repeated plugin execution funded by router custody. The plugins array is taken verbatim from the caller, looped with no uniqueness check, and each execute() re-reads amounts[0]. The input token is pulled in once; the second (and any further) swap consumes the router's pre-existing balance.
3. delegatecall makes the router both the payer and the payee of every swap. This is what lets a swap spend the router's funds rather than the caller's, while the proceeds also accrue to the router (where the attacker then reclaims them via the LP they own).
4. Attacker-controlled output token + pool. Both the output token and the AMM it swaps against are deployed and seeded by the attacker, so the "swap" is just a way to move the router's USDC into a pool the attacker can immediately removeLiquidity() from.

The published audit note the constructor links to (Audit3.md#H02) hardened the configuration contract against delegatecall overlay attacks — but the balance accounting in route() was left guarding only one side of the path.

Preconditions#

• The router holds an idle balance of the input token. Here the router custodied 877,961,918 USDC (slot 0x46662b86… reads 0x3454a2be before the attack) — leftover/dust from prior payments. The drain is exactly this balance; an empty router yields no profit.
• At least one approved swap plugin exists. configuration.approvedPlugins(DePayUniV1) returns the plugin address (trace lines 124-127), so _isApproved passes. The attacker reuses the legitimate, already-approved Uniswap plugin — no malicious plugin needs to be approved.
• amounts[1] (amountOutMin) can be 0 so the worthless fake-token output is accepted.
• Working capital in USDC to fund the route input and the flash-loan repayment. It is fully recovered intra-transaction, hence flash-loanable — the PoC sources it from the Uniswap USDC/WETH pair via a flash swap.

Attack walkthrough (with on-chain numbers from the trace)#

All figures are taken directly from the events and storage diffs in output.txt. The "FakeToken" is the attacker test contract itself (ContractTest, address 0x7FA9…1496); its balanceOf/transfer are the minimal ERC-20 at DePayRouter_exp.sol:109-130.

Why the second swap is "free"#

The router pulled in 877,961,918 USDC once (step 3a) but the two plugin executions pushed out 2 × 877,961,918 = 1,755,923,836 USDC into the attacker's pool (steps 3b, 3c). The difference — exactly the router's pre-existing 877,961,918 USDC — is the stolen value. The pool's USDC reserve ends at 1,755,923,836 (step 3c, Sync L201), and removeLiquidity returns all of it to the attacker (step 4, L241).

Profit accounting (USDC, 6 decimals)#

Equivalently: profit ≈ router's drained USDC (877,961,918) − flash fee (7,044,829) ≈ 870.92 USDC.

Diagrams#

Sequence of the attack#

Pool / router USDC state evolution#

The flaw inside route() / _execute()#

Remediation#

1. Check ALL custodied balances, not just the output token. Snapshot and assert non-decrease for every token the router holds across route() — at minimum path[0] (the input token) and any token reachable by a plugin. The strongest form: forbid route() from ending with less of any token than it started with (after accounting for the legitimately-collected amounts[0]).
2. De-duplicate / bound the plugin list, and collect input per-execution. Either reject duplicate plugins, cap the list, or pull amounts[0] inside each plugin execution so a swap can never be funded by the router's pre-existing balance. The amount actually spent by plugins must be tied to the amount actually collected.
3. Do not let the router be the payer of arbitrary swaps. Because plugins run via delegatecall, address(this) is the router and swaps draw from its balance. Route swap inputs explicitly from msg.sender-provided funds tracked for this call, not from the router's standing balance.
4. Never leave idle funds in the router. The drained 877.96 USDC was leftover from prior payments. A payment router should hold no resting balances; sweep residuals to a treasury after each payment and treat any non-zero resting balance as an invariant violation.
5. Constrain path ↔ output semantics. Require amounts[1] (amountOutMin) to be a meaningful, caller-provided minimum and validate that the output token is the merchant's expected token, so a worthless attacker-minted token cannot stand in as path[last].

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail forge test's whole-project build):

_shared/run_poc.sh 2023-10-DePayRouter_exp --mt testExploit -vvvvv

• RPC: an Ethereum mainnet archive endpoint is required (vm.createSelectFork("mainnet", 18_281_130 - 1)). Configure the mainnet RPC alias in foundry.toml / env to an archive node serving historical state at block 18,281,129.
• Result: [PASS] testExploit() with Attack Exploit: 870.917088 USDC.

Expected tail:

Ran 1 test for test/DePayRouter_exp.sol:ContractTest
[PASS] testExploit() (gas: 2987325)
Logs:
  Before Start: 0 USDC
  Attack Exploit: 870.917088 USDC

Suite result: ok. 1 passed; 0 failed; 0 skipped

References: DeFiHackLabs PoC (src/test/2023-10/DePayRouter_exp.sol); CertiK Alert — https://twitter.com/CertiKAlert/status/1709764146324009268 ; SlowMist Hacked — https://hacked.slowmist.io/ (DePay, Ethereum).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-10-DePayRouter_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: DePayRouter_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "DePayRouterV1 Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.