A removed operator still claims 1,000 rewards because removal does not touch the balance

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 26461-c-02-operator-can-still-claim-rewards-after-being-removed-fr. Standalone Foundry PoC and full write-up: 26461-c-02-operator-can-still-claim-rewards-after-being-removed-fr_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/logic/reward-calculation · vuln/access-control/broken-logic

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

Key info#

TL;DR#

The operator has 1,000 unclaimed rewards. Governance removes them. isOperator becomes false and operatorRewards is still 1,000. claim transfers the 1,000. The control removal zeroes the balance, sends the 1,000 to the pool, and the same claim pays 0.

Background#

Pashov, Smoothly, C-02, 1 August 2023. deleteOperators is the path used when an operator is slashed or has gone inactive. It removes the account from PoolGovernance and does not move operatorRewards. A malicious operator who was removed can still claim. An inactive operator's balance stays in the contract with no one to sweep it. The report's fix is to transfer the rewards to a chosen account, for example SmoothlyPool, as part of removal.

The vulnerable code#

function deleteOperators(address op) external {
    // @> VULN: the operator is removed from governance but operatorRewards[op] is left intact, so the removed operator can still claim.
    isOperator[op] = false;
}

claim then pays operatorRewards[op] and zeroes it. Removal never reaches that mapping.

Root cause#

The operator flag and the reward balance are separate, and only the flag is updated. Claim does not check isOperator. Whoever is still in the mapping gets paid.

Preconditions#

• The operator has a non-zero operatorRewards balance. Here it is 1,000, and the governance contract holds the tokens.
• Governance calls deleteOperators. That is the intended slash path, not a malicious admin. The harm is the removed operator calling claim afterwards.

Attack walkthrough#

1. Accrued rewards are 1,000 (output.txt:9).
2. After removal the balance on the books is still 1,000 (output.txt:11).
3. The removed operator claims 1,000 (output.txt:13).
4. Control seizes 1,000 to the pool (output.txt:15). The later claim pays 0 (output.txt:17).
5. [PASS] (output.txt:6).

Diagrams#

Impact#

Rewards that were supposed to be slashed are paid to the removed operator. The pool is short 1,000. On the control path the pool receives the 1,000 and the operator receives 0.

Remediation#

On removal, read operatorRewards[op], set it to zero, and transfer that amount to the pool before the operator can claim.

How to reproduce#

cd 26461-c-02-operator-can-still-claim-rewards-after-being-removed-fr_exp
forge test -vv

Sources#

• AuditVault finding: 26461-c-02-operator-can-still-claim-rewards-after-being-removed-fr
• Pashov Audit Group, Smoothly, 1 August 2023: https://github.com/solodit/solodit_content/blob/main/reports/Pashov/2023-08-01-Smoothly.md

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 26461-c-02-operator-can-still-claim-rewards-after-being-removed-fr_exp (evm-hack-registry mirror).
• AuditVault finding: 26461-c-02-operator-can-still-claim-rewards-after-being-removed-fr.

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.