Cowrie Research

degraded-mode-authenticity-failure

14 min read

Degraded-Mode Authenticity Failure / Failover Trust-Boundary Broadening

  • Name: degraded-mode authenticity failure / failover trust-boundary broadening
  • Category: exploit pattern / bridge security failure / failover abuse / degraded-mode validation / availability-over-authenticity
  • Summary: A system can look acceptably strict in steady state yet become exploitable the moment operators prioritize liveness during an outage. This pattern appears when a bridge, guardian backend, DVN, or watcher stack silently broadens what counts as authentic under connectivity loss, DDoS pressure, or dependency failure. The attacker first pushes the system into degraded mode, then feeds the weaker path forged message material or poisoned source-chain state. The resulting signatures may be real, but the trust boundary that produced them is not the one users thought protected custody.
  • What it is:
    • The protocol has a normal authenticity path and a fallback or degraded path.
    • The degraded path is supposed to preserve continuity when nodes, RPC providers, or backend links fail.
    • That fallback path quietly weakens one of the invariants that mattered in the primary path: canonical emitter verification, independent source observation, provider diversity, or explicit operator review before custody moves.
    • An attacker deliberately creates or exploits the degraded condition.
    • Once the system has failed over, the attacker injects fabricated bridge messages or poisoned source-chain observations that the steady-state path would have rejected.
    • Honest guardians, watchers, or verifiers then sign or forward the forged result, and destination-side contracts release or mint real value against fiction.
  • Typical preconditions:
    • The bridge or verifier stack has explicit fallback validation, provider failover, or degraded-mode routing logic.
    • Operators value continuous bridge operation enough that degraded mode still authorizes high-value message flow instead of pausing.
    • The fallback path is less reviewed, less observable, or less tightly specified than the primary path.
    • The system does not prominently signal to users or downstream contracts that it is operating with weaker authenticity assumptions.
    • Per-route caps, circuit breakers, or destination-side sanity checks are too weak to contain one bad message once degraded mode is live.
  • Common vulnerable surfaces:
    • guardian backends with a “fallback validation path” that preserves delivery but weakens source-authentication checks
    • DVN or watcher stacks that automatically fail over across RPC providers without proving the new path preserves the same security assumptions
    • bridge deployments whose apparently multi-step verifier design collapses to one surviving provider cohort during DDoS or partial outage
    • failover trees that favor availability and speed over pause until authenticity is re-established
    • monitoring systems that query the same endpoints as the attacker-controlled infrastructure or that miss selective lies served only to verifier IP ranges
    • offchain runbooks where degraded mode is treated as operational plumbing rather than as a live custody-policy change
  • Failure sequence:
    1. The attacker maps the protocol’s steady-state verification path and its degraded-mode fallback behavior.
    2. They create or exploit a condition such as connectivity disruption, targeted DDoS, node outage, or backend partition.
    3. The bridge, guardian set, or verifier stack falls back to a weaker observation or validation path.
    4. The attacker feeds forged message material or poisoned source-chain state through that weaker path.
    5. Legitimate guardians, DVNs, or relayers attest to the counterfeit result because the degraded path still treats it as acceptable bridge truth.
    6. Destination-side contracts release escrowed assets or mint wrapped assets, and the attacker cashes out before operators restore the stricter path.
  • Variants:
    • Fallback source-authentication downgrade — the system still validates message shape, but degraded mode stops proving that the message came from the canonical source contract or custody-changing path, as in Alephium.
    • Poisoned-provider failover — the verifier’s clean observation sources are disabled or DDoS’d until it relies on compromised nodes, as in KelpDAO.
    • Silent degraded quorum collapse — a route looks multi-provider in normal operation, but partial outage leaves one provider family or one operator-admin domain effectively defining truth.
    • Availability-first bridge operation — instead of pausing when authenticity assumptions change, the bridge continues to process high-value messages through the weaker path.

Three degraded-mode bridge-truth promotions reviewers should not collapse

  1. Some fallback-capable bridge artifact exists

    • A guardian backend produced an attestation, a DVN answered, a watcher path stayed reachable, or a failover RPC still returned bridge-shaped source data.
    • That only proves some surviving path can still emit an authenticity-looking object.

  2. That surviving artifact still deserves to count as route-local bridge truth under degraded conditions

    • This is the hard question in this pattern: did the route preserve the same source-contract, source-channel, custody-change, and observation-independence guarantees, or did outage handling quietly broaden who or what was allowed to define reality?
    • If degraded mode changed the proof story, then the bridge has already promoted a weaker object into money-good route truth.

  3. That accepted degraded-mode truth still deserves this much destination-side authority

    • Even when a route keeps enough confidence to permit some continuation, it should not automatically inherit healthy-mode mint, release, rebalance, or admin authority.
    • This is where bounded continuity, exit-only policy, delayed execution, and sharply lower caps belong.

The review habit here is simple: do not stop at fallback still works. Ask whether the route first confused artifact still exists with same bridge truth still holds, then confused even that accepted degraded truth with ordinary custody authority should stay live.

  • Detection heuristics:
    • Ask what exactly changes when the preferred node, RPC, or guardian-validation path fails?
    • Diff primary and fallback validation logic line by line; the dangerous bug is often not in steady-state verification at all.
    • Treat failover policy, node-selection order, and degraded-mode automation as part of the custody boundary.
    • Test whether the protocol pauses, rate-limits, or loudly escalates when it loses independent observation or canonical-emitter guarantees.
    • Inspect whether malicious infrastructure could lie only to verifier IPs while returning honest data to ordinary health checks.
    • Review outage runbooks with the same suspicion as contract upgrade code; both decide when the protocol is allowed to redefine truth.
  • Defenses:
    • Fail closed or sharply rate-limit when authenticity assumptions degrade; do not preserve full bridge throughput during validation uncertainty.
    • Require fallback paths to preserve the same emitter, state-transition, and source-observation guarantees as the primary path.
    • Make degraded mode explicit and operator-visible, with high-friction approval or an automatic pause before custody-moving messages resume.
    • Separate providers, node fleets, and cloud-admin domains so failover does not collapse to one hidden trust boundary.
    • Add destination-side caps, per-asset throttles, and route-level circuit breakers so one bad attestation cannot empty escrow while the protocol is in a degraded state.
    • Instrument monitoring to detect selective response spoofing, not just total outage.

What sound design looks like

  • A healthy bridge has one authenticity story and keeps it intact under stress. If the primary route proves canonical emitter, asset identity, amount, and custody change through one object, degraded mode should prove the same object rather than a cheaper approximation.
  • A healthy route should be able to answer three separate questions cleanly under stress: what fallback artifact survived?, why does it still count as the same route-local bridge truth?, and what narrower authority does that surviving truth earn right now? If those answers blur together operationally, degraded mode is already too permissive.
  • Liveness policy should be explicit about when it yields to solvency policy. High-value routes should pause, clamp, or delay when observer diversity, source-authentication guarantees, or provider integrity degrade, instead of silently continuing as if nothing material changed.
  • Healthy routes do not treat degraded mode as one vague yellow state. They pre-commit an operating ladder such as full trust, bounded, exit-only, and halted, with each lower rung carrying smaller per-asset caps, fewer message families, and less control-plane reach.
  • Exit-only should be a real bridge security mode, not a product euphemism. A route can preserve user unwinds, already-queued redemptions, or narrowly scoped withdrawals without also preserving fresh mint, rebalance, registry-edit, or privileged message authority.
  • Fallback infrastructure should be independently trustworthy in the way the architecture diagram claims. Separate providers only help if they stay separate under failover: different RPC cohorts, different cloud-admin domains, different emergency-access paths, and different operators who can actually disagree.
  • Degraded-state provenance should be preserved per message. Operators, downstream protocols, and incident responders should be able to tell which validation path authorized each release, what assumptions were weakened, which route mode was active, and whether route-level caps or acknowledgements were in force at the time.
  • Users and integrators should inherit a smaller blast radius, not a hidden trust expansion. A design is much healthier when degraded mode automatically narrows value at risk and surfaces the state change early enough for dependent systems to tighten their own limits too.

Failure-prevention checklist

  • Write down the bridge’s steady-state authenticity object and prove that degraded mode preserves the same source contract, channel, asset identity, amount, nonce, and destination bindings.
  • Treat every failover path as a custody-policy change. Fallback RPCs, observer pools, guardian backends, and manual override modes should have explicit approval rules, telemetry, and predeclared blast-radius limits.
  • Make degraded mode fail closed by default for high-value routes. If delivery must continue, lower route caps, add settlement delays, and require operator acknowledgement before any custody-moving message executes.
  • Pre-commit a route-mode ladder for degraded operation. Distinguish bounded continuity from exit-only continuity and from halted, and define ahead of time which message families survive each state: user withdrawals already in flight, delayed redemptions, fresh mints, treasury rebalances, admin dispatch, registry edits, and signer / DVN changes should not all inherit the same fallback authority.
  • Keep verifier diversity real under stress: separate providers, separate regions, separate cloud accounts, separate auth material, and separate admin teams for the paths that are supposed to cross-check one another.
  • Test selective-lie scenarios, not just hard outages. A verifier that sees attacker-tailored chain state while public explorers and ordinary health checks still look normal is already in the danger zone.
  • Bind fallback validation to canonical emitter and custody-change proofs, not to bridge-looking logs, partial traces, or weaker heuristics that only exist to keep traffic flowing.
  • Expose degraded-state signals onchain or to downstream operators when possible so routers, treasuries, and integrators can tighten their own controls before counterfeit releases socialize loss.
  • Put bounded-release controls under every route that can operate in degraded conditions: per-asset caps, rolling withdrawal ceilings, delayed large exits, and fast pause authority that does not depend on the same failing infra.
  • Rehearse outage runbooks with adversarial review. If the responder cannot say exactly which authenticity guarantees are lost during failover, the protocol is not ready to bridge real value through that mode.
  • Log and reconcile which provider set, verification path, and policy mode authorized each message so post-incident forensics can distinguish validator malice from degraded-path design failure.

Audit prompts

  • What exactly changes when the preferred observer, RPC, indexer, or guardian-validation path fails, and which security properties are no longer being proven in the fallback path?
  • Can an attacker force the system into degraded mode with targeted DDoS, peer isolation, API quota exhaustion, region failure, or dependency poisoning?
  • Does degraded mode still authenticate the canonical source contract and custody-changing event, or does it accept a weaker signal such as log shape, partial receipt data, or one provider’s opinionated state view?
  • Are allegedly independent verifiers still independent after failover, or do they converge onto one provider family, one admin plane, one cache, or one emergency-access workflow?
  • How is degraded mode announced, approved, rate-limited, and exited? Is there any path where the system silently broadens bridge truth without operator friction or user-visible state change?
  • Does the route distinguish users may safely exit from the bridge may still mint, rebalance, or execute privileged control-plane messages, or does any surviving fallback path keep all old permissions alive?
  • Could a poisoned provider selectively lie only to verifier nodes while monitoring, dashboards, and public RPC users continue to see honest chain state?
  • What destination-side controls bound loss if one counterfeit message is accepted during degraded operation, and can those controls be triggered without relying on the same impaired infrastructure?
  • Are there route-specific differences where some assets, chains, or message types fall back to materially weaker validation than others?
  • Do runbooks and code agree on who may activate fallback paths, skip manual review, lower quorum, or bypass source-authentication checks under incident pressure?
  • For every historical failover or chaos-test event, can the team reconstruct which messages were validated by which observation stack and whether any trust-boundary broadening occurred?

Lessons that should already be standard

  • High availability is not a security property if the price is counterfeit authenticity. A bridge should pause before it quietly changes what counts as proof.

  • Fallback still emits an artifact, that artifact still means the same thing, and that surviving meaning still deserves ordinary release authority are three different claims. Bridges that flatten them will keep operating straight through their own trust-boundary failure.

  • Failover infrastructure is part of the custody system, not operational plumbing. Secondary RPCs, emergency observers, and degraded guardians deserve the same review depth as the primary verifier path.

  • Claimed verifier decentralization only matters in the exact conditions where it is supposed to save you. If outage pressure collapses the route to one provider family or one operator, the system was never meaningfully independent.

  • Selective observation attacks are more realistic than total darkness. Teams that only monitor for outages and not for verifier-specific lies are defending the wrong failure mode.

  • Degraded mode should shrink blast radius before it preserves throughput. A bridge that keeps full-value releases live while authenticity assumptions weaken is choosing speed over solvency.

  • Route still up is not the same thing as route still deserves unchanged custody authority. Continuity for user exits is often compatible with sharply smaller mint, rebalance, and admin powers.

  • Operator runbooks are executable security policy. If emergency procedures are vague, unpublished internally, or impossible to test safely, the real trust boundary already lives in improvisation.

  • Users and integrators need to know when a route is no longer enforcing its normal proof story. Silent trust-boundary broadening converts operator convenience into everyone else’s balance-sheet risk.

  • Good incident forensics require message-level provenance for which validation path actually authorized custody movement. Without that, every degraded-mode event becomes an opaque argument instead of a learnable failure.

  • Where this pattern stops:

    • Use message-source-authentication-failure when the bridge would have accepted the wrong emitter, router path, or source channel even without an outage or failover trigger. That note is about who was allowed to author bridge truth at all; degraded-mode authenticity failure is about that author set broadening under stress.
    • Use verifier-input-independence-failure when the verifier story was already fake-diverse in steady state and the real lesson is shared observation collapse, even if an outage or DDoS made the weakness visible sooner. KelpDAO sits on this seam: the exploit was operationally a failover event, but analytically it also proved the route never had real verifier independence.
    • Use bridge-verification-failure when the user only needs the parent frame for forged bridge truth rather than the narrower outage-handling mechanism.
    • Pair with bridge-truth-security-object when the design question is what exact authenticity object the bridge should have refused to broaden under stress, with bridge-source-provenance-bundle-and-authoring-surface-discipline when the sharper question is which emitter, route, channel, or helper path degraded mode accidentally allowed to speak for the bridge, with bridge-verifier-independence-inventory-and-degraded-mode-discipline when the design question is how the route should inventory verifier roots and pre-commit narrower degraded-state authority, and with bridge-bounded-release-design when the question becomes how to keep degraded operation from turning one bad attestation into uncapped bridge-wide loss.

  • High-signal incidents:

    • [[../../../incidents/bridges-crosschain/alephium-bridge-fake-log7-event-forged-guardian-vaa-drain-2026-05-30|Alephium Bridge fake LOG7 event / forged guardian VAA drain (2026-05-30)]] — the attacker disrupted bridge-node connectivity, pushed the backend onto a fallback validation path, and then fed forged LOG7-based bridge messages that legitimate guardians signed.
    • forged bridge release (2026-04-18) — clean RPC paths were DDoS’d until the sole required DVN relied on poisoned nodes, turning failover policy itself into the custody break.

Internal linkages

Control surface

Graph View

Backlinks