SecHive.ai Book a demo →
● Patternreplay_authBusiness logicPublic-safe

Proof / Runtime authorization replay

CS.01 — Featured pattern

Runtime authorization replay.

A runtime authorization workflow accepted a signed one-time action. The signed material included a nonce-like value, but neither the validation layer nor the execution wrapper consumed that nonce in durable state. Possession of one valid authorization was enough to execute the same privileged action more than once.

Pattern IDreplay_auth
CategoryBusiness Logic
CVSS:4.0High / Critical
Detectionbizlogic_hunter
Validationpoc_validator
Disclosurepublic-safe
Public safety boundary. This page generalizes a real externally validated vulnerability pattern. Target names, production accounts, customer data, private repository paths, credentials, keys, domains, and exploitable production payloads are intentionally absent.

The invariant

One signed runtime authorization must authorize one execution.

The observed behavior violated that invariant. The system accepted the same signed bytes twice, applied the same privileged side effect twice, and produced two execution receipts that differed only in their digest.

The chain

1

Signed authorization issued

The required authorizers signed a single one-time action. The signed material included a nonce-like value (nonce, intent ID, request ID) intended to make the authorization unique.

2

First execution succeeds

The relayer submitted the signed authorization. The validation function ran a stateless check on signature freshness and authoriser membership. The execution wrapper performed the privileged side effect and produced a receipt.

3

Replay submitted

The same authorization bytes were submitted again, unmodified. The validation function returned OK because nonce was included in the digest but never recorded as consumed.

4

Second execution succeeds

The execution wrapper performed the privileged side effect a second time. The receipts diverged only in their post-state hash; the authorization was identical.

5

SecHive promotes

The candidate is promoted to a finding. The proof pack contains the signed payload, two execution receipts, side-effect deltas, the validation source path, a cosigned attestation, and a deterministic replay.sh.

Detection path

CVSS

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L

This vector is retained as public-safe scoring context. The point of the case study is not the exact score; it is the proof shape — a supposedly single-use authorization executes more than once.

Why it matters

Replayable runtime authorization breaks the trust boundary between approval and execution. In value movement, governance, repository, identity, or privileged administrative flows, this is the difference between a single approved action and a controllable repetition of that action by anyone who has seen the wire.

Remediation pattern

  1. Make nonce consumption durable: write it to state in the same atomic operation that executes the side effect.
  2. Move the consumption check inside the execution wrapper, not in a pre-flight validator.
  3. Add a regression test that submits the exact bytes twice and asserts the second submission fails.
  4. If multiple executors exist, consume the nonce in shared storage so distributed replay is also blocked.

Related patterns

This write-up is part of the SecHive bug bounty proof pack. Read the full proof pack for the broader inventory.