Oku — Failure to reset unspent approval to the target address wipes the contract balance

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 44376-h-6-failure-to-reset-unspent-approval-to-the-target-address. Standalone Foundry PoC and full write-up: 44376-h-6-failure-to-reset-unspent-approval-to-the-target-address_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/approval/residual · vuln/logic/direct-drain · vuln/access/untrusted-target

Reproduction: a self-contained Foundry PoC that compiles & runs in an isolated project with only forge-std — no fork, no RPC, no anvil_state. Full trace: output.txt. PoC: test/44376-h-6-failure-to-reset-unspent-approval-to-the-target-address_exp.sol.

AuditVault taxonomy: lang/solidity · sector/dex · sector/oracle · sector/token · platform/sherlock · has/github · has/poc · severity/high · impact/loss-of-funds/direct-drain · genome: wrong-condition · direct-drain · fot-slippage · oracle-freshness

Key info#

TL;DR#

1. execute approves an arbitrary target for the full order.amountIn.
2. The target call need only move 1 wei of tokenIn / tokenOut to pass the minAmountOut / over-spend checks.
3. Residual allowance is never set to zero; the order creator is refunded unspent tokenIn, so inventory of other orders remains in the vault.
4. The malicious target later transferFroms the residual against the vault, wiping pending-order balances.

The vulnerable code#

//approve
order.tokenIn.approve(target, order.amountIn); // @> VULN: never reset after call

//perform the call
(bool success, bytes memory reason) = target.call(txData);
// MISSING: order.tokenIn.approve(target, 0);

Fix (per report):

+      order.tokenIn.safeApprove(target, 0);

Root cause#

Approvals to untrusted fill targets are not scoped to the amount actually spent. Combined with refunding unspent tokenIn to the order creator, residual allowance becomes a free option on the vault's remaining inventory.

Preconditions#

• Pending orders leave tokenIn inventory in the vault.
• Attacker can create an order and choose the fill target.

Attack walkthrough#

1. Victim creates a 100e18 tokenIn order (inventory sits in OracleLess).
2. Attacker creates a 100e18 order, fills via malicious target that pulls 1 wei and returns 1 wei tokenOut.
3. Residual allowance ≈ 100e18 − 1 remains for the target against the vault.
4. spendAllowance drains leftover into the attacker — wiping victim inventory.

Diagrams#

Impact#

Entire vault tokenIn balance (all pending orders of the approved token) can be stolen by repeating the residual-allowance drain.

Sources#

• AuditVault finding #44376
• Sherlock 2024-11-oku judging
• Reduced source: sherlock-audit/2024-11-oku oku-custom-order-types/contracts/automatedTrigger/OracleLess.sol (execute approval path)

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 44376-h-6-failure-to-reset-unspent-approval-to-the-target-address_exp (evm-hack-registry mirror).
• AuditVault finding: 44376-h-6-failure-to-reset-unspent-approval-to-the-target-address.

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.