Frankencoin — Position owners can deny liquidations (unbounded price overflow)

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 20020-h-05-position-owners-can-deny-liquidations-code4rena-franken. Standalone Foundry PoC and full write-up: 20020-h-05-position-owners-can-deny-liquidations-code4rena-franken_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/arithmetic/overflow-dos · vuln/access-control/unbounded-parameter · vuln/loss-of-funds/frozen-funds

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/20020-h-05-position-owners-can-deny-liquidations-code4rena-franken.sol.

Key info#

This is an audit finding, not a historical on-chain incident. The PoC keeps the three blamed lines verbatim: the unbounded price = newPrice in adjustPrice, and the two overflowing multiplications in tryAvertChallenge and notifyChallengeSucceeded.

TL;DR#

1. A position owner can set the liquidation price arbitrarily high via adjustPrice (or the opening _liqPrice) — there is no upper bound.
2. Every challenge-resolution path multiplies price by a collateral amount: price * _collateralAmount in tryAvertChallenge, and _mulD18(price, _size) (i.e. price * _size / 1e18) in notifyChallengeSucceeded.
3. With price = type(uint256).max those products overflow, and Solidity 0.8 checked arithmetic reverts.
4. So no bid can ever avert the challenge, and MintingHub.end can never settle it. The collateral a challenger escrowed when launching the challenge is locked in the hub forever, and the challenger gets no reward.
5. This denies liquidation entirely: the owner keeps their minted ZCHF and simply abandons the (now worthless) collateral, pushing the loss onto challengers.

The vulnerable code#

The unbounded price (verbatim, Position.adjustPrice):

function adjustPrice(uint256 newPrice) public onlyOwner noChallenge {
    if (newPrice > price) {
        restrictMinting(3 days);
    } else {
        checkCollateral(collateralBalance(), newPrice);
    }
    price = newPrice; // @> no upper bound: can be type(uint256).max
    emitUpdate();
}

The averting-path overflow (verbatim, Position.tryAvertChallenge):

} else if (_bidAmountZCHF * ONE_DEC18 >= price * _collateralAmount){ // @> price * amount overflows

The settlement-path overflow (verbatim, Position.notifyChallengeSucceeded):

uint256 volumeZCHF = _mulD18(price, _size); // @> _mulD18 == price * _size / 1e18 -> price * _size overflows

Root cause#

The liquidation price is an owner-controlled value with no maximum, yet it is used as a multiplicand in checked arithmetic across every path that resolves a challenge. Setting it to type(uint256).max turns each of those multiplications into a guaranteed revert, so the challenge mechanism — the protocol's only tool for liquidating an under-collateralized position — becomes permanently inoperative for that position.

Preconditions#

• Anyone can open a position and raise its price via adjustPrice (owner-only, but the owner is the attacker) — permissionless.
• The position is not expired (so tryAvertChallenge reaches the overflowing comparison rather than the "expired" early return).
• A challenger has escrowed collateral against the position (the value that becomes locked).

Attack walkthrough#

From output.txt (two positions are used only because the browser PoC cannot advance time — one with a zero challenge period so end is callable immediately, one with an open window so a bid can be attempted):

1. The owner reprices both positions to type(uint256).max via adjustPrice.
2. A challenger escrows 1e18 collateral against each (launchChallenge pulls it into the hub).
3. end is called on the zero-period challenge. It first tries to return the escrow, then calls notifyChallengeSucceeded, where _mulD18(price, _size) overflows — reverting the whole end call and rolling back the return.
4. A bid is attempted on the open challenge; tryAvertChallenge overflows at price * _collateralAmount, so no bid can ever avert it.
5. HARM: both resolution paths revert permanently, and the challenger's full 2e18 escrow stays trapped in the hub with no way out. A control assertion shows that with a sane price the same end flow settles and returns the collateral — isolating the unbounded price as the root cause.

Diagrams#

Remediation#

Enforce an upper bound on the liquidation price (and/or the per-adjustment change), and restrict when a repriced position can be challenged so that a challenge can only target a position that was once validly priced. This prevents an owner from moving price into the range where the challenge-resolution arithmetic overflows.

How to reproduce#

cd ~/RustroverProjects/audits/evm-hack-registry/20020-h-05-position-owners-can-deny-liquidations-code4rena-franken_exp
forge test -vvv
# Fully local — no fork, no RPC, no anvil_state required.
# Expected: both tests PASS:
#   test_maxPrice_locks_challenger_collateral       (attack: end + bid both revert, escrow locked)
#   test_sanePrice_end_settles_and_returns_collateral (control: sane price -> end settles)

PoC source: test/20020-h-05-position-owners-can-deny-liquidations-code4rena-franken.sol — the verbatim adjustPrice, tryAvertChallenge, and notifyChallengeSucceeded lines plus the deny-liquidation attack and a control test.

Note: two positions and specific challenge sizes are reduced-model scaffolding chosen so the harm is observable without advancing time in-browser. The three blamed lines and the overflow-on-max-price behavior are faithful; the exact 2e18 locked magnitude validates the model. The lock (challenger collateral frozen, liquidation denied) is the impact accepted by the judge.

Reference: finding #20020 by JGcarv in the Code4rena Frankencoin audit (Apr 2023) · curated by AuditVault

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 20020-h-05-position-owners-can-deny-liquidations-code4rena-franken_exp (evm-hack-registry mirror).
• AuditVault finding: 20020-h-05-position-owners-can-deny-liquidations-code4rena-franken.

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.