Rubic Exchange Exploit — Arbitrary External Call Drains User Allowances

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

Vulnerability classes: 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 whole-compile, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: contracts_RubicProxy.sol and its base rubic-bridge-base_contracts_BridgeBase.sol.

Key info#

TL;DR#

RubicProxy is a cross-chain aggregator. To bridge or swap, a user first approves the proxy to spend their tokens, then the proxy forwards the trade to an external "router" via a low-level call. The flaw: the function routerCallNative(...) takes both the call target (_params.router) and the raw calldata (_data) from the caller, and the only safety check is that _params.router is present in the availableRouters whitelist (contracts_RubicProxy.sol:96-118):

function routerCallNative(BaseCrossChainParams calldata _params, bytes calldata _data) external payable ... {
    if (!availableRouters.contains(_params.router)) { revert RouterNotAvailable(); }   // ← only gate
    ...
    AddressUpgradeable.functionCallWithValue(_params.router, _data, _amountIn);          // ← attacker target + data
}

The whitelist availableRouters contained the USDC token address itself (0xA0b8...eB48). Tokens are valid swap "routers" in many aggregators, so this was not obviously wrong — but it is fatal here. The attacker simply set _params.router = USDC and _data = transferFrom(victim, attacker, amount). Because the proxy is the msg.sender of that call, and victims had approved the proxy, USDC happily moved each victim's balance to the attacker.

Net effect: every standing allowance to either Rubic proxy became a free withdrawal for anyone who could craft the calldata. The PoC drains 26 victims for a total of 1,475,491.81 USDC in a single transaction.

Background — what RubicProxy does#

RubicProxy (source) is described in its own header as a "Universal proxy contract to Symbiosis, LiFi, deBridge and other cross-chain solutions." Its model is the standard aggregator pattern:

1. The user approve()s the proxy for the token they want to bridge/swap.
2. The user calls a routerCall* entry point, naming a destination DEX/bridge router and supplying the encoded swap calldata.
3. The proxy pulls the user's tokens (for the ERC20 path), accrues fees, approves the router, and forwards the call.

Two proxy contracts were live, differing only in their routerCallNative signature:

• v1 0x3335...3333 — routerCallNative(BaseCrossChainParams _params, bytes _data) (contracts_RubicProxy.sol:96).
• v2 0x3338...3333 — routerCallNative(string _providerInfo, BaseCrossChainParams _params, bytes _data) (contracts_RubicProxy.sol:102) — an extra leading string for analytics, identical security posture.

Both inherit OnlySourceFunctionality → BridgeBase. The router whitelist lives in BridgeBase as EnumerableSetUpgradeable.AddressSet internal availableRouters (BridgeBase.sol:48), mutated by addAvailableRouter / removeAvailableRouter (BridgeBase.sol:368-383). At the fork block this set contained ordinary token contracts — including USDC — alongside genuine DEX/bridge routers.

The on-chain facts that make the exploit possible:

The srcInputToken / srcInputAmount fields were left at address(0) / 0, so the native path (routerCallNative) was used — it never pulls tokens from msg.sender and never validates that _data corresponds to a legitimate swap. It is a pure "call this address with this data" primitive wrapped behind a whitelist that admits token contracts.

The vulnerable code#

1. routerCallNative forwards attacker calldata to an attacker-chosen target#

contracts_RubicProxy.sol:96-118:

function routerCallNative(BaseCrossChainParams calldata _params, bytes calldata _data)
    external
    payable
    nonReentrant
    whenNotPaused
    eventEmitter(_params)
{
    if (!availableRouters.contains(_params.router)) {
        revert RouterNotAvailable();          // ← THE ONLY CHECK ON _params.router
    }

    IntegratorFeeInfo memory _info = integratorToFeeInfo[_params.integrator];

    uint256 _amountIn = accrueTokenFees(
        _params.integrator,
        _info,
        accrueFixedCryptoFee(_params.integrator, _info),  // = msg.value - fixedCryptoFee (= 0 here)
        0,
        address(0)
    );

    AddressUpgradeable.functionCallWithValue(_params.router, _data, _amountIn);  // ⚠️ arbitrary call
}

There is no validation that _data is a swap, no check that the call only touches the caller's own assets, and no constraint relating _params.router to the function selector inside _data. The proxy will call any whitelisted address with any bytes the caller supplies.

2. The whitelist admits token contracts, so router = USDC passes#

availableRouters.contains(USDC) returned true at the fork block. Token addresses are plausible "routers" in an aggregator (some integrations route directly through a token's own logic), so this configuration was not an obvious misconfiguration — but it converts the arbitrary call into an arbitrary transferFrom against every user who has approved the proxy.

3. The ERC20 path has the same root flaw#

routerCall (contracts_RubicProxy.sol:61-94) is the sibling that pulls tokens first; it safeIncreaseAllowance(_gateway, _amountIn) then does the same AddressUpgradeable.functionCallWithValue(_params.router, _data, ...). It carries a DifferentAmountSpent balance check, but that only protects the proxy's own balance — it does nothing to stop _data from spending a third party's approval to the proxy. The native path used in the actual attack does not even have that check.

4. Why the fee/whitelist logic gives no protection#

accrueTokenFees / _calculateFee (BridgeBase.sol:174-224) operate only on msg.value for the native path; with msg.value = 0 and a zero-fee integrator, the forwarded value _amountIn is 0. The exploit needs no ETH — the value transferred is entirely the victim's USDC, moved by the callee (USDC) under the proxy's identity.

Root cause — why it was possible#

The proxy conflates two trust domains:

Who is allowed to be called (the whitelist) is checked, but what is allowed to be done in that call (the calldata, and whose assets it touches) is not. The proxy is the holder of every user's approval, and it lends that identity to arbitrary calldata.

Three design decisions compose into a critical bug:

1. Caller-supplied call target + caller-supplied calldata. functionCallWithValue(_params.router, _data, ...) is a generic "execute on my behalf" primitive. Once a contract holds user approvals, any such primitive is equivalent to "spend anyone's approved balance," unless the calldata is strictly constrained.
2. The whitelist is the wrong control. Whitelisting the target prevents calling a malicious contract, but it cannot prevent calling a benign contract maliciously. USDC is benign; calling USDC.transferFrom(victim, attacker, x) from an address that holds victim's approval is the attack. The whitelist needed to also bind the selector/semantics, or exclude any address that could be a token in which users hold proxy allowances.
3. The proxy is msg.sender for the forwarded call. ERC20 transferFrom authorizes by allowance[from][msg.sender]. Because the proxy makes the call, the proxy's standing allowances are spendable. Pulling user funds and immediately re-approving an external "gateway" is the entire business model, so the proxy necessarily accumulates infinite approvals — every one of which is now a liability.

Put differently: a user's approve(RubicProxy, ∞) is, in the presence of this function, equivalent to approve(everyone, ∞).

Preconditions#

• The victim has a non-zero, unspent allowance of some token to one of the Rubic proxies (USDC.allowance(victim, proxy) > 0). Infinite approvals (type(uint256).max) — the default for most aggregator UIs — maximize the loss.
• The token in question is present in availableRouters (USDC was).
• That is all. The attack is permissionless (anyone can call routerCallNative), needs no capital (msg.value = 0, no token deposit), and the attacker harvests exactly min(victim_balance, victim_allowance) per victim.

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

The PoC (test/Rubic_exp.sol:59-135) loops over 26 known victims. For each victim it reads balanceOf and allowance, takes the smaller, then calls the appropriate proxy's routerCallNative with router = USDC and data = transferFrom(victim, attacker, amount).

• Victims 0–7 are drained via v1 proxy 0x3335...3333 (test/Rubic_exp.sol:109-119).
• Victims 8–25 are drained via v2 proxy 0x3338...3333 (note the extra empty "" provider string) (test/Rubic_exp.sol:120-130).

For victim #0 the trace shows, in order:

FiatTokenV2_1::balanceOf(0x6b8D…e91b)  → 1000000000000        (1,000,000 USDC)
FiatTokenV2_1::allowance(0x6b8D…e91b, 0x3335…3333) → 2^256-1  (infinite approval)
0x3335…3333::routerCallNative({ ..., router: 0xA0b8…eB48 /*USDC*/ },
                              0x23b872dd…6b8d…e91b…7fa9…1496…00e8d4a51000)
   emit Transfer(from: 0x6b8D…e91b, to: ContractTest 0x7FA9…1496, value: 1000000000000)

0x23b872dd is the transferFrom(address,address,uint256) selector; 0x…00e8d4a51000 = 1_000_000_000_000 = 1,000,000 USDC. The proxy emits FixedCryptoFee(0,0,…) and TokenFee(0,0,…) — no fee was taken, confirming the proxy treated this as a legitimate forward.

Ground-truth victim ledger (all 26, from emit Transfer events in output.txt)#

The summed Transfer values equal the attacker's final balance to the wei: [End] Attacker USDC balance after exploit: 1475491.811413 (output.txt:1569).

Profit accounting (USDC)#

The exploit is pure theft of pre-existing approvals; there is no flash loan, no swap, no price impact.

Diagrams#

Sequence of the attack (one victim, repeated 26×)#

Trust-domain confusion inside routerCallNative#

Why the whitelist is the wrong control#

Remediation#

1. Never forward arbitrary calldata from a contract that holds user approvals. The router target AND the function being invoked must be constrained. If the proxy must call routers generically, it should only ever spend tokens it pulled within the same call from msg.sender, and must reject any _data whose effect could reach a third party's approval.
2. Exclude token contracts (and any address users approve the proxy for) from availableRouters. A "router" should never be an address against which the proxy holds standing allowances. Maintain a strict separation between "tokens we are approved for" and "contracts we may call."
3. Bind selector + target together. Whitelist (router, allowed_selectors) pairs, or better, replace the generic low-level call with typed integrations per supported router so the proxy constructs the calldata itself from validated parameters — the user supplies parameters, never raw _data.
4. Use a pull-then-spend-then-zero pattern scoped to the caller. Pull srcInputAmount from msg.sender, approve the gateway for exactly that amount, execute, then reset the allowance to 0 (the ERC20 path already resets to 0 — extend the scoping idea so the only funds ever movable are the caller's own deposit for this call).
5. Mitigation already used in the wild: Rubic's emergency response was to revoke the proxies' use and instruct users to revoke approvals; the durable fix is to redeploy without the arbitrary-call-to-whitelisted-token primitive. Users with infinite approvals to either proxy must revoke them.

How to reproduce#

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

_shared/run_poc.sh 2022-12-Rubic_exp --mt testExploit -vvvvv

• RPC: an Ethereum mainnet archive endpoint is required (fork block 16,260,580, Dec 25 2022). foundry.toml points mainnet at an Infura endpoint that serves historical state at that block.
• Result: [PASS] testExploit(); the attacker (ContractTest) ends holding 1,475,491.811413 USDC pulled from 26 victims' approvals.

Expected tail:

Ran 1 test for test/Rubic_exp.sol:ContractTest
[PASS] testExploit() (gas: 990693)
  [End] Attacker USDC balance after exploit: 1475491.811413
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 22.92s

References: PeckShield / BlockSec disclosures (Dec 25, 2022); SlowMist Hacked — https://hacked.slowmist.io/ (Rubic, Ethereum, ~$1.4M). Twitter threads cited in the PoC header: https://twitter.com/BlockSecTeam/status/1606993118901198849 , https://twitter.com/peckshield/status/1606937055761952770 .

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-12-Rubic_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Rubic_exp.sol.

Alerts & third-party analyses

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