Cowrie Research

stored-privileged-approval-persistence

13 min read

Stored-Privileged-Approval Persistence / Harvested Admin-Intent Replay

  • Name: stored-privileged-approval persistence / harvested admin-intent replay
  • Category: exploit pattern / delayed-execution custody failure / stored-admin-authority lifecycle failure / signer-workflow compromise
  • Summary: This exploit family appears when a privileged approval survives beyond the review moment that made it legitimate. Durable nonces, queued multisig proposals, partially collected signature bundles, pre-signed admin transactions, and similar delayed-execution objects let attackers separate signature capture from cash-out. The attacker may first obtain real approvals through phishing, signer-endpoint compromise, a poisoned proposal surface, or plain operator error; the decisive second failure is that the harvested approval remains executable after the environment, signer set, or threat picture has changed. The sharper review split is not only was this once a valid approval object? but also does it still deserve to count as fresh privileged authority now? and if it still exists, how much live control should it still retain right now? Once that dormant authority stays live, attackers can wait for the best execution window, pair it with a later admin mutation, and turn one already-bad signing moment into future control over live funds. Drift is the purest current exemplar: valid Security Council approvals plus durable nonce semantics let attacker-harvested admin authority age into a later Solana broadcast that rewrote collateral truth and withdrew real assets.
  • What it is:
    • A protocol, exchange, or custody workflow creates privileged approvals that do not execute immediately.
    • Those approvals remain usable through durable nonces, stored proposal records, partially signed envelopes, delayed relays, or other sign now, execute later mechanics.
    • An attacker captures or influences a valid approval object during one moment in time.
    • The system fails to expire, revoke, quarantine, or re-attest that approval after signer anomalies, signer-set changes, environment compromise, or simple age.
    • The attacker later executes the still-valid approval when conditions are more favorable.
    • The eventual loss often comes through a second-step admin primitive such as ownership transfer, implementation swap, collateral admission, withdrawal-limit change, or treasury sweep.
  • Typical preconditions:
    • The system supports delayed privileged execution through durable nonces, queued multisig proposals, offline-signed admin bundles, or partially signed transactions that can later resume.
    • High-blast-radius actions share the same persistence model as routine transfers instead of expiring faster or requiring just-in-time re-review.
    • Incident response focuses on rotating keys, rebuilding UIs, or pausing markets but does not immediately enumerate and kill still-live privileged approval objects.
    • Signer-set changes, browser-bundle compromise, signer-endpoint anomalies, or proposal-service integrity scares do not automatically invalidate outstanding approvals.
    • The stored approval can still authorize a root-control mutation once executed.
    • Operators lack one machine-readable inventory of every pending privileged object that is still executable tonight.
  • Common vulnerable surfaces:
    • Solana durable-nonce governance and treasury flows
    • Safe, Squads, or other multisig proposal queues where partially collected signatures can survive a suspicious ceremony
    • offline-signed upgrade bundles, pre-authorized maintenance transactions, or relayer-held admin envelopes
    • custody workflows that store privileged proposals in coordinator databases or browser sessions without strong expiry or revocation
    • signer-set migration events where old queued proposals keep authority across the transition
    • recovery or retry workflows that normalize we will finish signing this later even for root-control actions
  • Failure sequence:
    1. The protocol creates a delayed-execution privileged object such as a durable-nonce transaction, queued multisig proposal, or partially signed admin bundle.
    2. The attacker obtains valid approvals for that object through phishing, signer compromise, proposal-surface deception, or some other signer-workflow failure.
    3. The approval does not execute immediately, so the issue looks containable or remains unnoticed.
    4. The environment changes — signers rotate, the team migrates the council, operators rebuild browsers, or staff simply move on.
    5. The system still treats the harvested approval as live authority because expiry, revocation, signer-set freshness, or security-event invalidation was missing.
    6. The attacker executes the stored approval at a chosen time.
    7. A second-step admin action converts that old authority into present-tense loss: ownership transfer, implementation rewrite, collateral admission, withdrawal-limit expansion, or direct reserve release.
  • Variants:
    • Durable-nonce persistence — the chain deliberately keeps one signed transaction valid across time until the nonce is advanced, as in Drift.
    • Queued-proposal resurrection — a suspicious or half-finished multisig ceremony leaves a proposal resumable later under calmer conditions.
    • Partial-signature inventory failure — responders kill sessions and rebuild UI state but do not invalidate already collected privileged signatures.
    • Signer-set migration freshness failure — old approvals survive council rotation, policy changes, or emergency role migration even though the review context that created them is no longer trusted.
    • Retry normalization — repeated signing glitches, device failures, or resubmissions during a privileged ceremony create several stored approval objects, any one of which may later remain executable.

Three stored-approval promotions healthy systems should not collapse

  1. A privileged approval object exists at all

    • A durable-nonce transaction, queued Safe or Squads proposal, partially signed bundle, or offline-signed admin envelope is sitting somewhere in the system.
    • This is only the weakest fact: some root-capable object is still reachable.

  2. That object still deserves to count as fresh privileged authority now

    • The harder question is whether today’s signer set, coordinator state, browser/runtime integrity, nonce context, proposal shell, and incident state still justify treating that object as current authority rather than merely once-valid residue.
    • Most delayed-execution failures happen here: responders prove the object is still the same bytes but never re-prove that it still belongs to today’s trust boundary.

  3. That accepted authority still deserves this much live control right now

    • Even a still-fresh object should not automatically retain yesterday’s full upgrade, ownership-transfer, withdrawal, listing, or treasury-sweep budget.
    • This is where lane separation, privilege shrinking, expiry by action class, and bounded-loss design start to matter.

Healthy review gets materially better once teams stop flattening those three promotions into one binary signature valid fact.

  • Detection heuristics:
    • Treat every durable nonce account, queued multisig proposal, partially signed admin object, and stored privileged envelope as live root-authority inventory, not background workflow residue.
    • Alert on privileged approvals that remain live across signer-set changes, browser-bundle incidents, proposal-service outages, or unusually long aging windows.
    • After any signer-intent anomaly, ask what still-executable approval object survived? before asking only did the attacker already broadcast?
    • Compare the review-time signer set, nonce context, proposal hash, and execution-time environment; stored authority that outlives those shifts deserves suspicion by default.
    • Investigate retries, abandoned proposals, and resubmission storms during privileged ceremonies as possible approval-harvest evidence.
    • Preserve coordinator records, nonce accounts, proposal ids, partial-signature artifacts, and revocation logs; this family often turns on what remained executable after the obvious session ended.
  • Defenses:
    • Prefer just-in-time approval for upgrades, owner changes, module installs, market listings, oracle rewrites, mint-right grants, and similar root actions.
    • Put explicit TTLs, signer-set versioning, and security-event invalidation on every stored privileged approval.
    • Make cancellation faster and easier than execution: one operator or emergency quorum should be able to enumerate and kill outstanding privileged objects quickly.
    • Separate routine transfer persistence from root-action persistence. The admin path should have the shortest lifetime and the highest re-attestation burden.
    • Automatically quarantine outstanding proposals and partial signatures after signer-endpoint compromise, browser compromise, proposal-hash mismatch, or unexplained retry anomalies.
    • Bind stored approvals to one exact machine-checkable execution envelope so responders know what is still live and what it can still mutate.
    • Rehearse harvested but not yet executed approval as a first-class incident type.
    • Keep monitoring focused on pending authority, not only executed authority.

What sound design looks like

  • Privileged approvals are perishable capabilities, not timeless root authority.
  • High-blast-radius actions prefer fresh review close to execution rather than long-lived stored authority.
  • A stored approval is three different things, not one: a reachable privileged object, a still-fresh authority claim under today’s environment, and a still-acceptable live control budget. A queued approval that still matches the reviewed payload should not automatically keep yesterday’s signer-set assumptions or yesterday’s full admin reach.
  • Outstanding approval inventory is one real operator object: responders can list it, reason about it, and cancel it quickly under stress.
  • Signer-set rotation, browser compromise, proposal-service compromise, suspicious retries, or custody-environment drift automatically invalidate or quarantine pending root actions.
  • Delayed approvals stay bound to one exact execution envelope and one signer / environment version rather than surviving as open-ended admin capability.
  • Teams monitor what still can execute later with the same seriousness they monitor what executed already.

Failure-prevention checklist

  • Inventory every delayed-execution privileged surface: durable nonces, pending Safe or Squads transactions, partially signed multisig payloads, offline-signed admin bundles, delayed relays, and recovery-time stored approvals.
  • Assign maximum lifetimes by action class, with the shortest horizons for upgrades, owner changes, signer-set rewrites, market listings, oracle updates, minter grants, and withdrawal-limit changes.
  • Bind each stored approval to signer-set version, policy version, target, call primitive, payload hash, nonce semantics, and explicit expiry state.
  • Check identity, freshness, and surviving authority budget independently. Same payload as before should not by itself preserve still live or still root-powerful conclusions.
  • Automatically invalidate or quarantine outstanding privileged approvals after signer compromise suspicion, proposal-surface integrity failure, browser-bundle compromise, device loss, or emergency signer rotation.
  • Make list live privileged approvals and cancel live privileged approvals core incident-response capabilities, not forensic afterthoughts.
  • Alert on aged pending root actions, especially those that remain live across personnel, signer, or environment changes.
  • Keep routine transfer queues and root-control queues separate so everyday operational persistence cannot silently carry upgrade or ownership authority.
  • Require fresh re-attestation when the signer set, execution window, nonce context, proposal shell, or review surface changes materially.
  • Rehearse containment for captured signatures, no broadcast yet as explicitly as keys stolen, funds moving now.

Audit prompts

  • Which exact privileged actions can remain executable after the original signing session ends, and where do those pending objects live?
  • What proves a stored privileged approval is still fresh rather than merely once valid?
  • Even if it is still fresh, what exact control shrinks or partitions the authority it retains over time, by lane, or after security-state drift?
  • Which signer-set, browser, proposal-service, or coordinator compromise events automatically invalidate outstanding privileged approvals?
  • Can responders enumerate every still-live privileged object tonight without relying on tribal memory?
  • How quickly can operators cancel suspicious pending authority relative to the fastest attacker broadcast path?
  • Do high-blast-radius actions share the same persistence model as ordinary transfers, and if so why?
  • After retries, signer glitches, or abandoned ceremonies, what exact control proves no partial privileged bundle remained resumable later?
  • If the system rotates signers or migrates governance, what prevents old queued authority from surviving into the new regime?
  • Are identity, freshness, and remaining authority budget checked independently, or did the workflow collapse them into one binary signature valid property?

Lessons that should already be standard

  • Valid signature and currently acceptable authority are different properties.

  • A privileged object exists, that object is still fresh under today's environment, and that accepted object still deserves this much authority are different properties too.

  • Delayed privileged approvals are dormant root authority, not harmless operational residue.

  • Rotating signers without invalidating queued root actions may preserve most of the real blast radius.

  • Approval freshness is part of the same security object as approval identity, but freshness still is not the same thing as surviving privilege budget.

  • Incident response that clears browsers and rotates keys but leaves pending admin authority alive is incomplete.

  • The right post-ceremony question is often not was anything executed? but what dangerous thing is still executable now?

  • High-signal incidents:

    • CVT counterfeit-collateral drain (2026-04-01) — the clearest direct exemplar, where attacker-harvested Security Council approvals remained live through Solana durable-nonce mechanics until the chosen admin-takeover window.
    • [[../../../incidents/operator-compromise-custody/bybit-eth-cold-wallet-safe-ui-compromise-malicious-mastercopy-swap-drain-2025-02-21|Bybit ETH cold wallet Safe UI compromise / malicious masterCopy swap drain (2025-02-21)]] — the strongest proposal-stack reminder that once signer-intent integrity is in doubt, every pending privileged Safe object and partial signature bundle becomes the next control surface to neutralize.
    • malicious ownership-transfer upgrade drain (2024-10-16) — a strong recovery-side exemplar where suspicious retries and partially collected root-action signatures should have been treated as dormant authority rather than resumable admin work.
    • malicious implementation swap drain (2024-07-18) — the custody-middleware version of the same operational lesson: once signer-facing review is suspect, queued or partially signed privileged objects need to die immediately.

Where this pattern stops

  • Use blind-sign-payload-substitution when the decisive question is still how were signers tricked about the object they approved? That family ends at the compromised review moment. This family starts after some privileged approval object already exists and the sharper security question becomes why it was still executable later.
  • Use authorized-action-origination-compromise when the fatal authority sat upstream in the workflow that authored a legitimate withdrawal or admin request. There the stored object may look perfectly fresh because the real compromise is already in the request-authoring system. This family is narrower: the stored approval itself outlived the trust context that justified it.
  • Use operator-boundary-opacity when the main lesson is that a smaller hidden operator set or residual admin path already outranked the visible signer threshold. This family can coexist with that hidden-boundary story, but it only becomes the best label once a time-separated pending approval inventory is itself the exploitable control surface.
  • Use signer-quorum-compromise when enough real signing authority was simply captured and exercised directly. If the attacker only needed current threshold control, the delayed-approval lifecycle is secondary. This note is for cases where the dangerous authority was harvested earlier and remained live across time.
  • Use execution-envelope identity pinning when the decisive healthy-side question is what exact privileged envelope should have stayed bound to one implementation, owner, module, or control-plane target. That note describes the positive-design object. This note describes the exploit family where an already-approved privileged envelope should have expired, been version-bound, or been revoked before later execution.
  • In short: this pattern begins once delayed privileged authority becomes its own custody surface, and it stops once the more precise story is instead about how approval was deceived, how requests were authored, or how a hidden operator boundary already dominated even without approval persistence.

Internal linkages

Control surface

Graph View

Backlinks