Security Advisory — Storage Aliasing in Priority Update Registry V1

What it is

Flashbots' advisory on a V1 storage-aliasing bug in the Priority Update Registry (PUR), an on-chain price feed. The vulnerability was found 2026-09-15 and fixed the same day; the fixed contract is live on Ethereum mainnet at 0xDa7AfEeD021EAFC1c1Af9C362dE477DaD0396B81. The fix itself is commit 8701e8e in the Priority Update Registry repo.

How it works

Lane slots were computed as keccak256(abi.encode(laneTarget, laneIndex)) with an unbounded, caller-controlled laneIndex. The authorization mapping isUpdater[target][updater] sat at storage slot 0, resolving to keccak256(abi.encode(updater, keccak256(abi.encode(target, 0)))) — the same two-argument keccak shape. Setting laneTarget to one's own address and laneIndex to keccak256(abi.encode(target, 0)) makes the "lane" slot land exactly on isUpdater[target][attacker]. No brute-force search was needed; any caller could compute the collision directly and write themselves in as an authorized updater, or overwrite (deauthorize) an existing one.

Preconditions / Affected

Any deployment using the original non-namespaced V1 lane layout is vulnerable — not just the primary registry. The advisory notes "several smaller V1-style instances share the same layout" and are also affected, though Flashbots found no value at risk in those. Absence of identified exposure is explicitly called not proof of safety; any instance with the original layout should be treated as vulnerable.

What to do

• Migrate off any V1-layout deployment to the fixed registry. This is not a drop-in address swap: because the storage layout changed, updater authorizations and lane state must be re-established from scratch on the new contract.
• Re-point both publishers and consumers at the new address; if a producer signs over a verifying-contract address, that signing domain must be updated too.
• Immutable consumer contracts that hardcode the old registry address cannot be reconfigured — they must be replaced.
• Separately, scope token allowances to minimum necessary and ensure emergency fund-recovery mechanisms exist.

The fix itself namespaces the lane preimage: laneSlot = keccak256(abi.encode(LANE_STORAGE_NAMESPACE, target, laneIndex)) where LANE_STORAGE_NAMESPACE = keccak256("PrioUpdateRegistry.lane"). This makes the lane preimage 96 bytes versus the authorization preimage's 64 bytes, so they can never match structurally — any overlap would require an infeasible Keccak-256 search rather than a direct computation.

Caveats

Flashbots states it found "no evidence" of exploitation pre-fix, but is explicit this is not proof of absence: the review covered direct transactions only, did not fully cover signed batches or internal calls, and the aliasing write itself emits no event. Anyone running a copy of the vulnerable contract is told to review their own storage and update history directly rather than rely on Flashbots' assessment. Separately, one propAMM team was privately notified of the issue a week earlier (2026-09-07) via SEAL 911, but that report wasn't escalated to Flashbots at the time because it was believed limited to that single system.