# Unverified input trusted before validation

Check whether zero-confirmation, peer-supplied, or pre-populated data is trusted before it is verified

_Area: Smart contract access control and control flow. Seen in 3 disclosed reports; latest 2026-07-02. Updated 2026-10-24._

## How it works
A component accepts data it did not produce or confirm — a mempool output, a caller-supplied identifier, a peer's integrity value — and acts on it as if it were already validated. The broken assumption is that "input reaching this point has been checked." When the check is skipped, deferred, or left to a later stage that trusts earlier state, an attacker supplies the value and the system treats it as ground truth.

## Where it shows up
- Confirmation thresholds set to zero or omitted when fetching spendable inputs (e.g. `minConfirmations=0`).
- Parameters that identify a resource (address, key, offset) accepted without checking the resource exists or is allowed.
- State written under an attacker-chosen key that is later read as proof of validity.
- Protocols where all parties submit the same value but submission order is not enforced.
- Peer or mempool data used to build outbound transactions or proofs.

## How to review
Trace each externally supplied value to the point where it is trusted. The invariant: no value influences a decision (spend, proof acceptance, integrity verdict) until it has been confirmed against an authoritative source, and any state keyed on it cannot be pre-set by an unprivileged caller. For confirmation counts, verify the threshold is explicit and non-zero for third-party inputs. For identifiers, verify existence and allow-listing before state is written. For peer submissions, verify the value is bound to the submitter and cannot be observed before commitment.

## Variants seen
- Pre-populating validity state for a not-yet-existing resource via an unchecked identifier, later colliding when the resource is added [E1](https://bugbountylibrary.com/r/c4%3A2024-07-optimism%3AM-03.md).
- Counting unconfirmed mempool outputs as spendable, enabling griefing and replacement of outbound transactions [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-09.md).
- Accepting peer integrity hashes in any order with no binding to player data, allowing reflection of a legitimate peer's value [E3](https://bugbountylibrary.com/r/h1%3A3559522.md).

## Impact and severity
Consequences ranged from invalid proofs being accepted [E1](https://bugbountylibrary.com/r/c4%3A2024-07-optimism%3AM-03.md), to disrupted bridge outbound transactions [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-09.md), to a full integrity/anticheat bypass [E3](https://bugbountylibrary.com/r/h1%3A3559522.md). Severity rises when the trusted value gates funds or proof validity, and when the attacker can set it cheaply and repeatedly.

## Why fixes fail
Filtering only some inputs (e.g. unconfirmed UTXOs from self but not arbitrary senders) leaves the general case open; the fix must cover all unprivileged sources, not a subset [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-09.md).

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2024-07-optimism%3AM-03.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-09.md
- E3: https://bugbountylibrary.com/r/h1%3A3559522.md