Fix: withdrawEarningsFromSponsorships trusted the return value of arbitrary withdraw() calls

[hpihkala]

Summary

On 2026-10-09 an attacker drained the free (unstaked) DATA of many Operators by passing a fake "sponsorship" contract to Operator.withdrawEarningsFromSponsorships. This PR fixes the root cause in StakeModule._withdrawEarnings, adds regression tests that reproduce the attack, and bumps Operator.version() to 4.

Root cause

StakeModule._withdrawEarnings is reachable by anyone and did:

sumEarnings += sponsorshipAddresses[i].withdraw(); // never checked

There was no check that the address is a Sponsorship this Operator is staked in, and the earnings were taken from the number returned by withdraw() rather than from DATA actually received.

An attacker-controlled contract returning X = freeBalance / 0.30 from withdraw() caused:

• _splitEarnings to send 5% × X (protocol fee) out of the Operator's own DATA balance
• the fisherman branch in Operator.withdrawEarningsFromSponsorships to fire (X > 5% of Operator value), burning the owner's self-delegation and sending 25% × X to the caller

5% + 25% = 30% of X is the entire free balance. Staked DATA was not reachable since only token.balanceOf(operator) pays out. Once self-delegation was exhausted, the loss fell on delegators.

Fix

StakeModule._withdrawEarnings now has two independent guards:

1. Only staked Sponsorships are accepted. Every address must satisfy indexOfSponsorships[sponsorship] != 0, otherwise it reverts with the existing NotMyStakedSponsorship error. indexOfSponsorships is only set in _stake, which already requires the Sponsorship to be deployed by SponsorshipFactory. This alone blocks the exploit.
2. Earnings are measured from the DATA balance change, not from withdraw()'s return value. This matches the pattern already used in _unstake, _forceUnstake and QueueModule._triggerAnotherOperatorWithdraw, and also closes a latent issue: Sponsorship._withdraw wraps transferAndCall in try/catch, so even a genuine Sponsorship can return a non-zero payout when no DATA was sent.

Operator.version() is bumped from 3 to 4 so patched Operators can be distinguished on-chain (subgraph / UI / scripts).

Tests

New tests in Operator.test.ts → "Withdrawing and profit sharing":

• fake sponsorship → NotMyStakedSponsorship: alone, mixed in with a real staked Sponsorship, and via triggerAnotherOperatorWithdraw; all balances unchanged
• real factory-deployed Sponsorship the Operator is not staked in → NotMyStakedSponsorship
• staked Sponsorship whose withdraw() reports a payout that never arrives (new TestAllocationPolicy case 11) → NoEarnings, nothing paid out

All three were verified to fail against the old StakeModule (the drain succeeded) and pass with the fix. Full OperatorTokenomics suite passes (287 tests); solhint and eslint are clean.

Supporting test contracts:

• testcontracts/TestFakeSponsorship.sol (new) — mirrors the attacker's contract: withdraw() returns a settable number, never sends DATA
• testcontracts/TestAllocationPolicy.sol — added case 11 (onWithdraw reports more than the Sponsorship holds)

Deployment / redeployment

• Changed production bytecode: StakeModule (fix) and Operator (version bump only).
• Existing Operators cannot be patched. They are EIP-1167 clones that store their stakeModule address at initialize(); there is no setter, and DEFAULT_ADMIN_ROLE is renounced by the factory. Existing Operators remain vulnerable while they hold unstaked DATA and must eventually migrate to new Operator contracts. Until then, owners should stake or withdraw free DATA.
• OperatorFactory does not need redeploying/upgrading. Use the existing scripts/upgradeOperatorTemplate.ts flow: deploy new Operator template, NodeModule, QueueModule, StakeModule, then call OperatorFactory.updateTemplates(...) on every chain where the factory is live.
• Not affected: Sponsorship, SponsorshipFactory, StreamrConfig, all policies.

[jtakalai]

Did a bit of archeology. The bug was introduced in this 2023-04-05 commit, older code counts the tokens as in this fix. That commit was way before the 2023-11-03 main audit, so... bad luck I guess. The audit was thorough by that time's standards, i.e. before current LLMs.

Might be good to ask LLM to walk through the trust boundary of the Operator: check all incoming data (function arguments, return values) if there are assumptions where it comes from, and are those assumptions checked. Another task could be to just directly ask for "red-teaming" i.e. can one of the participants extract tokens that they don't have the right to; and of course (while more unlikely) if an outsider can extract tokens, like what happened here.

The fix itself looks very targeted and clean. Deployment strategy LGTM.

[hpihkala]

Thanks for the review @jtakalai!

Might be good to ask LLM to walk through the trust boundary of the Operator

That's pretty much what I did, and it came up with the findings and fixes in #1093