Summary

The clawback method in Sablier’s smart contract, designed to recover unclaimed tokens after a certain grace period, could be adversely affected by blockchain reorganizations (reorgs). Reorgs occur when competing chains are resolved in favor of a chain that does not include the originally accepted blocks. This could result in the clawback conditions being inconsistently applied, potentially leading to erroneous
token transfers or failed clawback attempts.

Vulnerability Details

Block reorganizations can alter the state of the blockchain, causing previously confirmed transactions to be invalidated and replaced by transactions from an alternative chain. This can impact the clawback method in the following ways:

The grace period for clawback is determined by comparing the current block timestamp with the timestamp of
the first claim (_firstClaimTime). A reorg could revert the block containing the first claim, resetting the _firstClaimTime and effectively extending the grace period beyond its intended duration.

The method checks if the campaign has expired based on the current block timestamp. A reorg could alter
the perceived expiration time, causing the hasExpired function to return an invalid result.
This might allow clawback to occur prematurely or prevent it when it should be allowed.

If a clawback transaction is included in a block that is later replaced due to a reorg, the transaction could be invalidated. This would require the admin to reattempt the clawback, potentially after a state change that invalidates the original clawback conditions.

Impact

Reorgs can cause fluctuations in the grace period, making the timing of clawbacks unpredictable and
possibly unfair to claimants.
The expiration checks could be bypassed or incorrectly enforced, resulting in premature clawbacks (recovering tokens before the intended period) or delayed clawbacks (failing to recover tokens when allowed).

POC

Chain reorgs are very prevalent in Ethereum mainnet, where the contract is deployed.
You can check https://etherscan.io/blocks_forked index of reorged blocks on etherscan.

Additionally, on Polygon this is even more prevalent.
https://protos.com/polygon-hit-by-157-block-reorg-despite-hard-fork-to-reduce-reorgs/
https://polygonscan.com/blocks_forked

Tools Used

Foundry

Recommendations

Implement additional measures, such as waiting for multiple confirmations before proceeding with the clawback, or implement a fallback mechanism in case of a block reorg.