"b5cb0555" Exploit — Permissionless `printMoney()` Forwarder Drains a Trusted Treasury (Confused Deputy)

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

Vulnerability classes: vuln/access-control/missing-auth · vuln/access-control/broken-logic · 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 together, so this one was extracted). Full verbose trace: output.txt. All three core contracts are unverified on BscScan — analysis below is reconstructed from the live execution trace and on-chain bytecode disassembly (see How sources were reconstructed).

Key info#

TL;DR#

The protocol is split into two contracts that share the b5cb0555 vanity-address family:

• a treasury 0xB5CB0555A1… that actually holds the protocol's tokens (WBNB, ETH, stables, BTCB) and guards its privileged token-moving function so it can only be called by one address, and
• a forwarder 0xB5CB0555c4… that the treasury trusts as that one address.

The fatal flaw is that the forwarder itself has no access control. Its function selector dispatcher falls through every unknown selector — including the attacker-chosen printMoney() (0x94655f2b) — into a generic, permissionless "execute these calls on these targets" routine (a multicall over CALL/DELEGATECALL). Anyone can therefore make the forwarder issue arbitrary calls, and because the treasury trusts the forwarder, those calls can instruct the treasury to transfer out all of its funds to the attacker.

The attacker simply called, for each token the treasury held, the equivalent of:

forwarder.execute(
    targets = [ treasury, helper ],
    data    = [ treasury.transferToken(token, fullBalance, attacker), helper.noop(...) ],
    values  = [ 0, 0 ]
)

Seven calls (one per token), each draining the treasury's full balance of that token to the attacker EOA. No flash loan, no price manipulation, no capital required — just a free, permissionless drain.

How sources were reconstructed#

The PoC file is named unverified_b5cb_exp.sol for a reason: the forwarder, the treasury, and the helper are all unverified on BscScan, so the PoC drives them with raw call(hex"…") calldata (test/unverified_b5cb_exp.sol:69-94). The analysis here was reconstructed three ways:

1. The live trace (output.txt) labels the forwarder's entrypoint printMoney() and shows the exact internal calls, Transfer events, amounts, and storage changes.
2. Bytecode disassembly (cast disassemble) of the forwarder and treasury, to read the dispatcher and the access-control checks.
3. Differential cast call at the fork block, to prove who is and isn't allowed to call the treasury's privileged function (see Root cause).

Background — the two-contract design#

At the fork block the treasury held, and the attacker drained, exactly these balances:

All seven balanceOf(treasury) reads in the trace (e.g. output.txt:1610-1611) equal the corresponding Transfer amounts to the attacker — i.e. the attacker drained 100% of each balance, leaving the treasury empty.

The vulnerable code (reconstructed from bytecode)#

1. The forwarder's dispatcher falls through to a permissionless executor#

The forwarder's selector table only recognises six selectors; anything else jumps to the default execution path at 0x0070, which decodes the calldata into (bytes[]/address[] targets, bytes[] data, uint256[] values) and runs a CALL/DELEGATECALL loop — with no CALLER check before the calls execute:

; forwarder dispatcher (cast disassemble)
0x000d  CALLDATALOAD / 0xe0 SHR          ; selector = msg.sig
0x0014  PUSH4 0x5c8f0489 ... EQ JUMPI    ; six named selectors
0x002a  PUSH4 0xb6a5d7de ... EQ JUMPI
0x0035  PUSH4 0xfe9fbb80 ... EQ JUMPI
0x0045  PUSH4 0x0243f5a2 ... EQ JUMPI
0x0050  PUSH4 0x268a066f ... EQ JUMPI
0x005b  PUSH4 0x33ae525a ... EQ JUMPI
0x003f  PUSH2 0x0070  JUMP               ; <-- DEFAULT: every other selector lands here
...
0x0070  JUMPDEST                          ; decode (targets, data, values) and ...
0x0190  ... 0x022e CALL ... 0x02db DELEGATECALL   ; ... execute the batch. No CALLER guard here.

printMoney()'s selector 0x94655f2b is not in the forwarder's table, so the attacker's printMoney(targets,data,values) calldata simply flows into this executor. (The trace labels it printMoney() because that selector resolves to that name in 4-byte databases, but functionally it is just "the default execute path".)

2. The treasury's token-mover IS guarded — but only against direct callers#

The treasury's privileged selector 0x0243f5a2 (the one the executor invokes to move tokens) contains a CALLER/EQ guard against the admin/forwarder:

; treasury 0x0243f5a2 handler (cast disassemble)
0x01cb  CALLER
0x01cc  EQ                                ; require(msg.sender == trusted)
0x03f7  CALLER ... EQ                     ; further guards vs 0x3801410dcea8...

This is why the treasury cannot be drained directly. The exploit works only because the call arrives through the trusted forwarder — which itself lets anybody in.

Root cause — why it was possible#

This is a textbook confused-deputy failure produced by splitting a privileged "deputy" (the forwarder) from the resource owner (the treasury), guarding the owner but forgetting to guard the deputy.

I proved the asymmetry with two differential calls at the fork block:

# Calling the treasury's token-mover DIRECTLY from a random EOA → REVERTS ("_!_")
cast call 0xB5CB0555A1…  0x0243f5a2<token=WBNB,amt=1,to=attacker,…> \
  --from 0x1111…1111 --block 52052679
#  → execution reverted: _!_

# The SAME function called from the forwarder address → SUCCEEDS
cast call 0xB5CB0555A1…  0x0243f5a2<…> \
  --from 0xB5CB0555c4… --block 52052679
#  → 0x  (would transfer)

# Calling the forwarder's printMoney(...) from a totally random EOA → SUCCEEDS
cast call 0xB5CB0555c4…  0x94655f2b<targets,data,values> \
  --from 0x2222…2222 --block 52052679
#  → 0x  (permissionless; runs the batch)

So:

1. The treasury trusts the forwarder unconditionally (msg.sender == forwarder ⇒ allowed to move any token, any amount, to any recipient).
2. The forwarder trusts everyone — its default execution path has no caller check.
3. Composition: everyone can move the treasury's funds, by laundering the call through the forwarder.

Two design decisions made this a one-shot, zero-cost theft rather than a niche bug:

• The treasury's token-mover takes recipient and amount as caller-supplied parameters (it is not a fixed-destination sweep), so the attacker pointed it straight at their own EOA.
• The forwarder's executor is a fully general multicall (arbitrary target + arbitrary calldata), the maximal possible authority to hand an unauthenticated caller.

Preconditions#

• The treasury holds a non-zero balance of the target tokens (it did — see the balance table). The attacker first reads balanceOf(treasury) for each token, then requests exactly that amount.
• The forwarder is registered as a trusted caller of the treasury (it is — proven by the differential cast call).
• No capital, no flash loan, no specific timing. Anyone can call printMoney() at any block.

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

The attacker deploys AttackerC (test/unverified_b5cb_exp.sol:62-96); its constructor fires seven forwarder.printMoney(...) batches, one per token. Each batch: (a) reads forwarder-side balanceOf(treasury, token), (b) calls the forwarder's default executor, which (c) calls treasury.0243f5a2(token, fullBalance, attacker, …) → token.transfer(attacker, fullBalance), and (d) runs a no-op helper.c1b1ef56(0x4848…4848, 0).

The first WBNB transfer's storage diff (output.txt:1616-1618) shows the treasury's WBNB balance slot going 0x…1382294b6a25c95b6 → 0 (full drain) and the attacker's slot filling by the same amount — confirming the treasury was emptied, not partially skimmed.

Profit / loss accounting#

The attacker started this tx with ~0 of each token (only 0.00314 USDT of dust) and ended holding the entire treasury:

Before/after balances: output.txt:1558-1571. The ~$2M figure in the PoC header is the aggregate campaign loss — the attacker reran the same exploit against several cloned victim/treasury pairs (two more example txs are listed in the Key-info table); this single tx accounts for ~$35K of it.

Diagrams#

Sequence of one drain batch (repeated 7×)#

Trust topology — the confused deputy#

Treasury state evolution#

Remediation#

1. Add access control to the forwarder's executor. The forwarder's default/printMoney execution path must require msg.sender to be an authorized operator (the admin / a keeper role). An unauthenticated, fully-general "call arbitrary target with arbitrary data" entrypoint is the maximal authority and should never be exposed.
2. Don't make a contract a trusted deputy unless it is itself authenticated. The treasury treats the forwarder as fully trusted (msg.sender == forwarder ⇒ move any funds). That trust is only safe if the forwarder also authenticates its own callers. Audit both sides of every trust edge: a guard on the resource owner is worthless if the trusted caller is open.
3. Never let an externally-reachable path choose both recipient and amount of a treasury transfer. The treasury's token-mover took to/amount from caller-supplied calldata. Privileged sweeps should hard-code the destination (e.g. a treasury/governance address) and ideally bound the amount.
4. Make the dispatcher fail closed. A selector dispatcher that falls through unknown selectors into a privileged action is dangerous. Unknown selectors should revert, and any "execute batch" capability should be an explicit, named, access-controlled function — not the default branch.
5. Verify contracts. Deploying privileged fund-custody contracts unverified provides no security (the bytecode is public) and only delays detection; it does not prevent the attack.

How to reproduce#

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

_shared/run_poc.sh 2025-06-unverified_b5cb_exp -vvvvv

• RPC: a BSC archive endpoint is required (fork block 52,052,679). foundry.toml uses https://bsc-mainnet.public.blastapi.io, which serves historical state at that block; most public BSC RPCs prune it and fail with header not found / missing trie node.
• Result: [PASS] testPoC(). The "after attack" balances equal the full treasury balances drained to the attacker.

Expected tail:

  after attack: balance of attacker: 22.491703001170613686    (WBNB)
  after attack: balance of attacker: 1.507949072622558765     (ETH)
  after attack: balance of attacker: 5713.631371163521539333  (USDT)
  after attack: balance of attacker: 4253.611958524052045623  (TUSD)
  after attack: balance of attacker: 0.032017839076702731     (BTCB)
  after attack: balance of attacker: 2028.106822073140120333  (USDC)
  after attack: balance of attacker: 1523.817415577564055735  (FDUSD)

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

Reference: TenArmor post-mortem — https://x.com/TenArmorAlert/status/1937761064713941187 (b5cb0555, BSC, ~$2M aggregate).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2025-06-unverified_b5cb_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: unverified_b5cb_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

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