fix(proof): assert derived block matches claim after derivation

[mw2000]

Closes GHSA-5jh4-3p33-85xc. advance_to_target silently downgrades the local target on EndOfSource, allowing an adversary to bind a valid output root to a future block number. Add a postcondition in WitnessExecutor::run() that rejects execution when the derived safe head block number differs from the claimed L2 block number.

Includes a gated exploit-regression integration test (RUN_GHSA_EXPLOIT_REGRESSION=1) reproducing the attack shape.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
base	Ignored	Preview	May 7, 2026 8:52pm

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 1 Sum 2

[mw2000]

This is a port of succinctlabs/op-succinct#899

[github-actions]

Review Summary

PR: fix(proof): assert derived block matches claim after derivation

The fix is correct. The postcondition in WitnessExecutor::run() closes the GHSA-5jh4-3p33-85xc vulnerability by asserting that the derived safe-head block number equals the claimed L2 block number after derivation completes.

Why the fix works: The vulnerability exploits advance_to_target's silent downgrade on EndOfSource — when the pipeline runs out of L1 data, it adjusts the target to the current safe head and continues, eventually returning successfully at block N even though block T was requested. Because claimed_l2_output_root was left as root(N), the existing output root check passes. The new ensure_derived_block_matches_claim postcondition catches this: safe_head.block_info.number (= N) != boot.claimed_l2_block_number (= T).

What I verified:

• The check placement after the output root comparison is correct — both checks are needed and the order doesn't affect the security outcome (the output root check passes in the exploit scenario, so the block number check is what rejects)
• advance_to_target uses >= (line 81 of client.rs) but block-by-block derivation means the safe head will be exactly the target on exit, so the == check in the postcondition is not overly strict
• The ensure_derived_block_matches_claim function is unit-tested for match, below, and above cases
• The integration test correctly reproduces the exploit shape (tightened L1 head + inflated claim block number) and validates the postcondition rejection via stderr parsing
• The integration test is properly gated behind RUN_GHSA_EXPLOIT_REGRESSION=1 and #![cfg(unix)]

No issues found.

[linear]

CHAIN-4349