Suzaku dust forceUpdateNodes leaves 600 stake that a rebalance should have moved

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 61229-dust-limit-attack-on-forceupdatenodes-allows-dos-of-rebalanc. Standalone Foundry PoC and full write-up: 61229-dust-limit-attack-on-forceupdatenodes-allows-dos-of-rebalanc_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/dos/permanent · vuln/logic/incorrect-state-transition

Key info#

Field	Value
Loss	600 stake stays on the node. The control moves 600
Vulnerable contract	`Middleware.forceUpdateNodes`
Attacker EOA	`0x1111111111111111111111111111111111111111`
Attack contract	`Exploit`
Attack tx	`Exploit.run()`
Chain / block / date	Ethereum model · block 0 · 2025-07
Compiler	solc 0.8.27, cancun, via IR
Bug class	Dust update sets pending without changing weight

TL;DR#

forceUpdateNodes is called with limitStake of 1 wei across two nodes. Weight is stake / 1e12, so 1 wei does not change it, but each node is still marked pending. rebalance(600) then returns 0 and the 600 stake stays on node 0. The control ignores an update whose weight does not change, so the same rebalance moves the 600.

The vulnerable code#

SOLIDITY

if (!ignoreDust || beforeW != afterW) {
    // @> VULN: pending is set even when the dust update does not change weight.
    nodes[i].setPending(true);
}

The loop is two iterations. The control requires beforeW != afterW before setting pending.

Root cause#

A pending flag is how the middleware stops a second stake update in the same epoch. The dust call sets that flag without moving stake and without changing the P-Chain weight. The real rebalance, which should pull excess stake back to the vault, sees the flag and does nothing.

Attack walkthrough#

Node 0 is funded with 600 stake.
forceUpdateNodes(1) runs the two-node loop. Weight before and after is equal.
Both nodes are marked pending.
rebalance(600) sets rebalanceReverted and returns 0. The node still holds 600.
The control middleware sees equal weights and does not set pending.
Its rebalance pulls 600. The control node ends at 0.

Diagrams#

flowchart TD A["Node holds 600 stake"] --> B["forceUpdateNodes called with 1 wei"] B --> C["Weight is unchanged"] C --> D["pending is set anyway"] D --> E["rebalance of 600 returns 0"] E --> F["600 stays on the node"] F --> G["Control ignores the dust and moves 600"]

Impact#

600 stake that the vault withdrawal required to be rebalanced stays on the operator node for the epoch. The control moves that 600.

PoC#

BASH

cd 61229-dust-limit-attack-on-forceupdatenodes-allows-dos-of-rebalanc_exp
forge test -vv

test_exploit_dust_blocks_rebalance asserts 600e18 stayed, the rebalance was blocked, and the control moved 600e18.

Sources#

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 61229-dust-limit-attack-on-forceupdatenodes-allows-dos-of-rebalanc_exp (evm-hack-registry mirror).
AuditVault finding: 61229-dust-limit-attack-on-forceupdatenodes-allows-dos-of-rebalanc.

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