# Multi-step campaign overrides are anchored to the original campaign, making later overrides impossible

Merkl's overrideCampaign validates new overrides against the original campaign's startTimestamp, so once overridden, later overrides revert with InvalidOverride even before the effective start.

- Payout: Contest reward
- Severity: medium
- Program: Merkl
- Credited: v2110
- Disclosed: 2026-01-27
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-11-merkl#m-03
- Library page: https://bugbountylibrary.com/r/c4%3A2025-11-merkl%3AM-03
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity vuln:business-logic

**Target:** DistributionCreator.sol overrideCampaign
**Root cause:** overrideCampaign validates new override parameters against the original campaignList entry rather than the latest stored override, so the original startTimestamp/duration constrain every subsequent override.
**Steps:**
1. Create campaign with startTimestamp=1000, duration=3600.
2. Before start, call `overrideCampaign` to set start=2000, duration=7200.
3. At block.timestamp=1500, call `overrideCampaign` again with new start (e.g. 2000).
4. Check `(newCampaign.startTimestamp != _campaign.startTimestamp && block.timestamp > _campaign.startTimestamp)` evaluates true (1500>1000), reverting with `InvalidOverride`.
**How found:** Code reading of overrideCampaign's validation logic, noticing it compares against campaignList (original) instead of campaignOverrides, then constructing a timeline where the original start is past but the effective start is future.
**Insight:** When auditing override/update functions, check whether validation reads the base record or the latest override record; a single-use override bug appears when constraints are anchored to immutable original parameters.