Pool accepts input when output token has no code — silent transfer failure

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 18260-transfer-operations-may-silently-fail-due-to-the-lack-of-con. Standalone Foundry PoC and full write-up: 18260-transfer-operations-may-silently-fail-due-to-the-lack-of-con_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/dependency/unchecked-return-value · vuln/input-validation/missing

Reproduction: self-contained synthetic Foundry reduction; see output.txt.

Key info#

Field	Value
Loss	A swapper loses input tokens without receiving output
Vulnerable contract	`Transfers.safeTransfer` / `safeTransferFrom`
Attacker EOA	`0x1111111111111111111111111111111111111111`
Attack contract	`Pool` and `MockToken` via `Exploit`
Attack tx	`Exploit.run()`
Chain / block / date	Ethereum model · block 0 · 2021-02
Compiler	`solc 0.8.24` (synthetic)
Bug class	Low-level call lacks contract-existence check

TL;DR#

Solidity low-level calls to an account with no code return success. The pool therefore accepts 1,000 input tokens while its “output token” call to a non-deployed address moves nothing.

Background#

The Primitive review calls out this exact Transfers/TransferHelper pattern. The local pool keeps the vulnerable call semantics and makes the loss observable.

The vulnerable code#

SOLIDITY

(bool success, bytes memory data) = token.call(
    abi.encodeWithSignature("transfer(address,uint256)", to, value)
);
require(success && (data.length == 0 || abi.decode(data, (bool))), "Transfer fail");

Root cause#

The helper validates only the boolean/return-data convention, not token.code.length > 0.

Preconditions#

The pool can be configured with a destroyed or not-yet-deployed token address.
A swap transfers input before attempting the output transfer.

Attack walkthrough#

Exploit mints 1,000 input tokens and swaps to address 0xBEEF.
The nonexistent output call returns success with empty data.
The Proof event at output.txt:380 shows 1,000 input tokens in the pool and zero output.

Diagrams#

sequenceDiagram participant U as Swapper participant P as Pool participant N as No-code address U->>P: transferFrom(input, 1000) P->>N: low-level transfer(1000) N-->>P: success, empty return data P-->>U: swap succeeds with no output

Remediation#

Require token.code.length > 0 before low-level calls, use vetted SafeERC20, and atomically validate both token addresses before taking input.

How to reproduce#

BASH

cd evm-hack-registry/18260-transfer-operations-may-silently-fail-due-to-the-lack-of-con_exp
forge test -vvvvv

Sources#

Reference: https://github.com/trailofbits/publications/blob/master/reviews/Primitive.pdf

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 18260-transfer-operations-may-silently-fail-due-to-the-lack-of-con_exp (evm-hack-registry mirror).
AuditVault finding: 18260-transfer-operations-may-silently-fail-due-to-the-lack-of-con.

Alerts & third-party analyses

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.

Source-level debugger — step opcodes and Solidity in sync