DEXRouter Exploit — Unprotected `functionCallWithValue` Drains the Router's Native BNB

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-09-DEXRouter_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/DEXRouter_exp.sol.

Vulnerability classes: vuln/access-control/missing-auth · vuln/dependency/unsafe-external-call

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 compile under a whole-project build, so this one was extracted). Full verbose trace: output.txt. PoC: test/DEXRouter_exp.sol.

The victim contract is unverified on BscScan, so no Solidity source could be downloaded into sources/. Every claim below is reconstructed from the live -vvvvv execution trace, the function selectors, and direct cast reads of on-chain state at the fork block. Function names (update, functionCallWithValue, param names fcb/bnb/busd/router) are taken from the PoC author's reverse-engineered interface, not from verified source.

Key info#

TL;DR#

DEXRouter exposes a public function — functionCallWithValue(address target, bytes data, uint256 value) — that performs an arbitrary external call to a caller-chosen target, forwarding caller-chosen native value out of the contract's own balance, with no access control. There is also a public update(address,address,address,address) that lets anyone rewrite the four privileged "config" addresses the contract stores (the slots originally held the PancakeSwap V2 router and three project-specific addresses).

The attacker simply:

1. Calls update(attacker, attacker, attacker, attacker) to register itself in all four config slots (during this call the router calls back 0xe44a73b7(caller) to the new address to "confirm" it; the attacker's fallback answers true).
2. Calls functionCallWithValue(attacker, a(), address(DEXRouter).balance) — the router forwards its entire 20 BNB balance into a call to attacker.a(){value: 20 BNB}, which trivially succeeds.

There is no swap, no flash loan, no price manipulation, no oracle. It is a one-shot drain of an unguarded "execute arbitrary call and send my money" function. The attacker's BNB balance goes from 0 → 20 BNB in a single transaction.

Background — what the contract appears to be#

The contract is labelled DEXRouter (the name comes from a parameter in the attacker's helper code). From the storage layout that update() overwrites, it behaves like a small DEX-router wrapper / helper that caches four addresses it needs in order to route swaps and pull funds:

Slot @2 decoding to 0x10ED43C718714eb63d5aA57B78B54704E256024E — the canonical PancakeSwap V2 Router — confirms this is a router-integration helper that legitimately needs to make value-bearing external calls (e.g. to swap or to forward BNB). The fatal mistake is that the mechanism it uses to make those calls is exposed publicly without any caller check.

At the fork block the contract held exactly 20 BNB (confirmed by cast balance 0x1f7c…4fb7 --block 32161325 → 20000000000000000000). That balance is the prize.

The vulnerable code#

The victim is unverified, so there is no .sol to quote. The behaviour below is reconstructed directly from the execution trace in output.txt and from the function selectors.

1. functionCallWithValue — arbitrary call + arbitrary native value, no auth#

The attacker's reverse-engineered interface (test/DEXRouter_exp.sol:16-20):

interface IDEXRouter {
    function update(address fcb, address bnb, address busd, address router) external;
    function functionCallWithValue(address target, bytes memory data, uint256 value) external;
}

In the trace, the single call

DEXRouter::functionCallWithValue(ContractTest, 0x0dbe671f, 20000000000000000000)
  ├─ ContractTest::a{value: 20000000000000000000}()   // 0x0dbe671f == a()
  │   └─ ← [Return] true
  └─ ← [Return] 0x…0001

shows the router taking three caller-supplied arguments and executing, in effect:

// Reconstructed semantics (victim unverified):
function functionCallWithValue(address target, bytes memory data, uint256 value) external {
    // ❌ NO access control — any caller reaches this
    (bool ok, bytes memory ret) = target.call{value: value}(data);
    require(ok);
    // returns ret
}

The attacker passes target = attacker, data = a() selector (0x0dbe671f), and value = address(DEXRouter).balance (= 20 BNB). The router obediently forwards its own 20 BNB into the call to the attacker. (test/DEXRouter_exp.sol:38)

This is the textbook "unprotected forwarding / arbitrary call" anti-pattern: an address.call{value:…}(data) whose target, data, and value are all attacker-controlled and which spends the contract's balance rather than the caller's.

2. update — unprotected config setter (the enabler)#

DEXRouter::update(ContractTest, ContractTest, ContractTest, ContractTest)
  ├─ ContractTest::fallback(0xe44a73b7…7fa9385b…) [staticcall] → 0x…0001  // "authorized?" → true
  └─ storage changes: slots @1,@2,@3,@4 all set to ContractTest

update(...) lets any caller overwrite all four privileged config addresses (test/DEXRouter_exp.sol:35). Before writing, the contract performs a caller-controlled authorization callback: it issues a staticcall with selector 0xe44a73b7 and the caller's address as the argument to the address being written in (here, the attacker). The attacker's fallback recognizes selector 0xe44a73b7 and returns abi.encode(true) (test/DEXRouter_exp.sol:47-53):

fallback(bytes calldata data) external payable returns (bytes memory) {
    if (bytes4(data) == bytes4(0xe44a73b7)) {
        return abi.encode(true);   // "yes, I am authorized"
    }
}

So the contract's idea of "is this caller allowed?" is to ask an address the caller controls — a self-defeating check. The attacker registers itself, the check it controls says "yes," and the config is overwritten.

Root cause — why it was possible#

Two independent missing-access-control defects, either of which is fatal, compose into a trivial drain:

1. functionCallWithValue is a public, unguarded "spend my balance on an arbitrary call" primitive. target, data, and value are entirely attacker-controlled, and the native value is drawn from the contract's balance. A helper that needs to forward BNB to a known, trusted router must restrict either the caller (owner/role) or the target (hard-coded to the router) — this contract did neither. This alone is sufficient to steal the 20 BNB; the update() step is not strictly required to reach it.

2. update "authorizes" the caller by calling back into a caller-controlled address. Using a callback to a parameter-supplied address as the authorization oracle means the attacker provides both the question and the answer. The intended guard (selector 0xe44a73b7 → "are you allowed?") is inverted into an attacker-controlled true.

The deeper design flaw is treating caller-supplied data as a trust source: the call target, the value, and even the authorization verdict are all chosen by the untrusted caller. A privileged value-bearing call must derive its trust from on-chain state set by a trusted party (an owner/role mapping checked with msg.sender), never from arguments the caller passes in.

Preconditions#

• The router holds a non-zero native balance (it held 20 BNB at block 32,161,325). The drain takes exactly whatever balance is present, because value = address(DEXRouter).balance.
• functionCallWithValue is publicly callable (no onlyOwner/role modifier). Confirmed by the trace: the Foundry default test EOA (0x7FA9…1496) calls it directly and it executes.
• No capital, no flash loan, no token approvals, no market conditions are required. The attacker starts with 0 BNB (test/DEXRouter_exp.sol:32) and ends with 20 BNB.

Step-by-step attack walkthrough (ground truth from the trace)#

All figures are taken directly from output.txt.

Concretely from the log lines:

Attacker BNB balance before exploit: 0.000000000000000000
Attacker BNB balance after  exploit: 20.000000000000000000

The entire exploit is two external calls: one to neutralize/abuse the config check, one to walk off with the money. Step 1 is mostly ceremony — step 2's functionCallWithValue is the actual theft and, because it reads address(DEXRouter).balance itself, it scoops up whatever the router holds.

Profit / loss accounting#

Net attacker profit = 20 BNB (≈ $4,000 at the time), with zero capital at risk and no fees beyond gas. This matches the PoC's @KeyInfo - Total Lost : ~4K USD$.

Diagrams#

Sequence of the attack#

Control flow of the vulnerable primitive#

Why the update authorization check fails (self-referential trust)#

Remediation#

1. Never expose an arbitrary value-bearing call publicly. functionCallWithValue(target, data, value) must be either (a) onlyOwner/role-gated, or (b) restricted to a hard-coded, immutable trusted target (the known PancakeSwap router) — ideally both. A contract that forwards its own native balance to a caller-chosen address with no caller check is an unconditional drain primitive.
2. Authorize against on-chain state, not arguments. update() must check msg.sender against an owner/role mapping that was set by a trusted party at deployment. Asking a caller-supplied address "are you authorized?" lets the attacker answer its own question. Remove the 0xe44a73b7-style callback authorization entirely.
3. Do not let privileged config setters be permissionless. Overwriting the router/token/treasury addresses is a high-privilege action and must be gated by onlyOwner (or a timelock/multisig).
4. Hold zero idle native balance in a router helper. If the contract must transiently custody BNB, sweep it to a treasury at the end of each operation so there is nothing to steal between calls.
5. Apply checks-effects-interactions and reentrancy guards to any function that performs external call{value:…}, even after the access-control fix, to prevent secondary abuse.

How to reproduce#

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

_shared/run_poc.sh 2023-09-DEXRouter_exp --mt testExploit -vvvvv

• RPC: a BSC archive endpoint is required (fork block 32,161,325). foundry.toml uses https://bsc-mainnet.public.blastapi.io, which serves historical state at that block; most pruned public BSC RPCs fail with header not found / missing trie node.
• Result: [PASS] testExploit() — attacker BNB goes from 0 to 20.0.

Expected tail (output.txt):

Ran 1 test for test/DEXRouter_exp.sol:ContractTest
[PASS] testExploit() (gas: 45274)
Logs:
  Attacker BNB balance before exploit: 0.000000000000000000
  Attacker BNB balance after exploit: 20.000000000000000000

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

Victim contract is unverified on BscScan; the source-level behaviour above is reconstructed from the live -vvvvv trace, function selectors (0xe52809f8 update, 0x0dbe671f a()), and direct cast reads of on-chain state at the fork block. Reference: @DecurityHQ — https://twitter.com/DecurityHQ/status/1707851321909428688.

Sources & further analysis#

Reproductions & code

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

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "DEXRouter 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.