Cowrie Research

message-source-authentication-failure

16 min read

Message-Source Authentication Failure / Forged Emitter Provenance

  • Name: message-source authentication failure / forged emitter provenance
  • Category: exploit pattern / bridge security failure / source-side authenticity failure / event-provenance ambiguity
  • Summary: Some bridges treat a log, message payload, or relayer-visible deposit artifact as if its shape also proved its origin. The bug class appears when watchers, guardians, or relayers can be convinced to authenticate attacker-authored message material without proving that it came from the canonical bridge core contract, the canonical handler path, the canonical source channel, or a custody-changing call context. Once this looks like a bridge message drifts away from this was emitted by the real bridge source of truth, honest relayers or even legitimate guardian signatures can still release real value against fiction.
  • What it is:
    • A bridge consumes source-chain messages, events, or logs as the first step in cross-chain authenticity.
    • The verifier path checks message format, topic shape, or expected fields more strongly than it checks emitter identity, source-channel identity, and call-path provenance.
    • One attacker-reachable path can emit bridge-looking data from the wrong contract, the wrong handler, or a non-custody-changing context.
    • Offchain watchers, relayers, or guardians then convert that false provenance into a valid bridge action such as mint, release, or refund.
    • The destination side behaves exactly as designed because the bridge’s own source-authentication layer already accepted the lie.
  • Typical preconditions:
    • The protocol has offchain watchers, relayers, or guardians that parse source-chain events into bridge truth.
    • Different contracts or code paths can emit similar event shapes or message bodies.
    • The bridge does not bind message accepted tightly enough to emitted by canonical core contract plus executed in the custody-changing path plus arrived from the one source channel or endpoint that was actually entitled to speak for that asset.
    • Fallback validation, compatibility wrappers, router helpers, or native-asset convenience handlers weaken source authentication.
    • Operators assume that event schemas or topic patterns are self-authenticating.
  • Common vulnerable surfaces:
    • guardian stacks that watch generic logs instead of validating canonical emitter addresses and contract state
    • relayers that key off event signatures without proving which path emitted them
    • routers and refund helpers whose side paths can still produce deposit-looking artifacts
    • shared handler code where native-asset and ERC-20 flows reuse one event surface but only one path really moves value
    • fallback validation modes that relax the checks normally tying an observed message to the real bridge-core context
    • bridge architectures that describe watch the logs operationally but never specify which onchain post-conditions make those logs authentic
  • Exploit sequence:
    1. The attacker finds a way to emit or register bridge-looking message material from outside the canonical bridge source path.
    2. They make that message look structurally valid enough for watchers, relayers, or guardians to accept.
    3. The bridge’s source-authentication layer fails to prove canonical emitter identity, canonical call path, or real custody-changing context.
    4. Honest relayers or legitimate guardians convert the false message into a signed attestation, mint, refund, or withdrawal.
    5. Destination-side contracts release escrowed assets or mint wrapped assets against the forged provenance.
    6. The attacker cashes out before operators can pause the route or invalidate the counterfeit inventory.
  • Variants:
    • Fake emitter contract — attacker-controlled code emits Wormhole-style or bridge-style message material that the watcher stack mistakes for canonical output, as in Alephium and pNetwork.
    • Mixed authentic-and-counterfeit batch contamination — one real bridge request appears in the same transaction, receipt, or parsed log batch as several attacker-authored lookalikes, and the extractor authenticates the batch too coarsely to discard the forged siblings, as in pNetwork.
    • Shared event, different semantics — one event schema is emitted by both the real custody path and a weaker or zero-value path, as in Qubit.
    • Router-adjacent provenance confusion — a side path such as refund, return, or helper settlement can still emit a deposit-looking artifact that the relayer treats as a true inbound deposit, as in THORChain.
    • Wrong-channel provenance — the packet is real, but it arrived from a different channel or endpoint than the one whose escrow or mint authority later backs redemption, as in Secret / Axelar.
    • Fallback-validation downgrade — normal source-authentication checks exist, but failover or degraded mode stops proving the same provenance guarantees.
    • Canonical-path drift — upgrades, wrappers, or compatibility shims silently change which contracts, channels, or handler endpoints are allowed to author bridge truth.

Three source-authorship promotions reviewers should not collapse

  1. Some bridge-looking artifact exists

    • A log, packet, memo-bearing router artifact, or message payload is visible and parseable somewhere in the source-domain workflow.
    • That only proves something bridge-shaped happened.

  2. That artifact deserves to count as canonical source-route bridge truth

    • The harder question is whether it came from the one exact contract, one exact channel or endpoint, one exact handler path, and one exact custody-changing or otherwise authorized state transition that was entitled to speak for this route.
    • Most forged-emitter losses happen here: the bridge promoted a weaker artifact into money-good source truth before it had really proved authorship.

  3. That accepted source truth deserves this much destination-side redeemability authority

    • Even source-route truth that looks authentic enough should not automatically inherit unlimited reserve reach, wrong-route redemption power, or broad same-window mint / release authority.
    • This is where route-local redeemability and bounded release still matter.

Healthy bridge review gets materially better once teams stop flattening those three promotions into one vague moment called the source message looked valid.

Case splits worth preserving

  • Alephium is the clean fake emitter plus degraded validation version: attacker-controlled Alephium-side contracts emitted bridge-looking LOG7 material, then connectivity pressure pushed the backend onto a weaker path that stopped proving canonical source provenance strictly enough. The important boundary question is not merely did guardians sign? but which exact Alephium-side contract and validation mode were still allowed to author VAA-worthy truth? Pair this with degraded-mode-authenticity-failure when the sharper lesson is that outage handling widened the author set.
  • pNetwork is the clean one real event laundered forged siblings version: the exploit path did not require a fully independent fake bridge universe, only a parser that authenticated a mixed batch too coarsely and let counterfeit peg-out logs inherit trust from one legitimate request in the same receipt. The healthy design question is whether provenance was proved per artifact rather than per transaction or per extracted batch.
  • Qubit is the clean same event signature, weaker path version: the generic deposit path emitted the Deposit surface relayers already trusted for the real ETH-locking path. The sharper analytical weight still often lives in deposit-signal-locked-value-mismatch because the source-side lie was also no value actually moved, but the provenance lesson remains useful: relayers could not distinguish which path had authored the event at all.
  • THORChain 2021-07-22 is the clean router-adjacent helper path still spoke with deposit authority version: returnVaultAssets() and refund-adjacent logic could still author a router artifact Bifrost treated as a fresh inbound deposit. The healthy question is which exact router-side functions were permitted to speak for inbound truth after helpers and recovery flows existed. For the stronger design framing, pair this with bridge-source-provenance-bundle-and-authoring-surface-discipline and bridge-canonical-path-exclusivity-and-stale-authoring-surface-deauthorization.
  • Secret / Axelar is the clean real packet, wrong source route version: the payloads were syntactically valid IBC traffic, but the Secret-side bridge failed to bind redeemability to Axelar’s canonical source channel. The healthy question is why packet arrived from some valid channel was allowed to collapse into packet arrived from the one channel whose balance sheet backs this asset.

These cousins all belong in the same family because the bridge authenticated the wrong speaker rather than merely the wrong payload shape, but they preserve different healthier review questions: who emitted this artifact?, which exact path emitted it?, was provenance proved per artifact or only per surrounding batch?, and which route or channel was actually entitled to spend this reserve?

  • Detection heuristics:
    • For every bridge message type, ask not only what fields must be present? but which exact contract, channel, and state transition are allowed to author this message?
    • Treat emitter identity, handler identity, and path-specific post-conditions as part of the authenticity proof, not as implementation detail.
    • Diff all code paths and source endpoints that can emit a given event signature or message body; if relayers cannot distinguish them, assume danger.
    • Review transaction- or receipt-level extraction code for one real event sanitized the whole batch mistakes: matching the right topic is not enough if sibling logs in the same receipt can come from attacker contracts.
    • Review fallback validation and degraded modes as independent trust boundaries, especially for offchain guardian stacks.
    • Trace whether a watcher proves both right contract and right semantics, or merely right-looking log.
  • Defenses:
    • Bind every bridge message type to a canonical emitter set and canonical source endpoint set, and reject lookalike emitters or wrong-channel packets even if the payload parses cleanly.
    • Authenticate provenance per event or packet, not per surrounding transaction, receipt, or mixed log batch. One legitimate bridge event must not make neighboring counterfeit artifacts inherit trust.
    • Emit bridge-significant events only after the custody-changing post-condition has succeeded, and use distinct event schemas for materially different paths.
    • Make router helper, refund, and recovery flows unable to emit artifacts that downstream components interpret as fresh deposits.
    • Treat fallback validation as security-critical code that must preserve the same emitter and state-transition guarantees as the primary path.
    • Have relayers and guardians verify canonical source-contract identity, canonical channel / endpoint identity, path-specific invariants, and where possible balance-change or state-change context before signing or forwarding.
    • Document the canonical message-authoring surface explicitly so upgrades and operators cannot silently broaden it.

What sound design looks like

  • A healthy bridge can answer one explicit authorship question for every relay-authoritative message type: which exact contract, which exact source chain or domain, which exact channel or endpoint, and which exact state transition are allowed to speak for the system? Bridge truth as a single security object is the broader companion for preserving that one canonical answer, while bridge source-provenance bundle and authoring-surface discipline is the narrower design note for keeping that authoring surface explicit.
  • The safest designs keep the canonical emitter surface narrow and boring: one bridge core, one handler family, one route mapping, and one post-condition that must already be true before a message becomes relay-authoritative. Compatibility wrappers, refund helpers, migration shims, and recovery flows do not get to author lookalike truth on cheaper terms.
  • Healthy bridges keep artifact visibility, accepted source-route truth, and destination-side redeemability as separate states. A parseable log, a route-authentic message, and an actually spendable release or mint right should not be the same bit under three names.
  • Source authentication should prove both right emitter and right semantics. An event from the correct contract but from the wrong helper path, wrong route, wrong source channel, or wrong custody-changing context is still forged bridge truth.
  • If multiple routes or channels carry the same nominal asset, provenance checks should feed into route-local redeemability rather than stopping at packet came from some compatible source. A wrong-channel packet should fail before it can touch the balance sheet behind a healthier route. Bridge route-local redeemability domain discipline is the companion for that narrower reserve-segregation question.
  • Offchain watchers, guardians, and relayers should not need folklore such as this topic usually means deposit or that packet probably came from the bridge we meant. They should be able to verify canonical emitter identity, canonical route identity, and path-specific invariants directly from the observed artifact.
  • Distinct message semantics deserve distinct authoring surfaces. If deposit, refund, migration, recovery, and admin flows can all produce relay-relevant artifacts, the bridge is already asking downstream components to guess intent instead of authenticate it.
  • Healthy bridges also assume one forged-authorship event may still get through and keep the blast radius bounded. Bridge bounded release design is the companion for the separate question even if a wrong emitter or wrong channel manages to author one accepted bridge fact, why was it still allowed to release so much so quickly?.

Failure-prevention checklist

  • Treat artifact exists, artifact counts as canonical source-route truth, and accepted source-route truth can spend this much destination-side value as separate promotions in code, relayers, ops, and monitoring; do not let one successful parse or one accepted channel check silently stand in for all three.
  • Enumerate the canonical message-authoring surface per message type: exact emitter contract, exact source chain or domain, exact channel / endpoint, exact handler path, and the exact custody-changing or state-changing post-condition that must have happened first.
  • Treat that authoring surface as protocol state, not operational folklore. Hard-code or tightly govern it, and make upgrades or route additions update the same machine-checked allowlist relayers actually enforce.
  • Use distinct event schemas, packet types, or message discriminants for materially different semantics such as deposit, refund, recovery, migration, or admin action. Do not ask relayers to recover meaning from the same generic artifact.
  • Ensure helper, fallback, refund, and recovery paths cannot emit artifacts that downstream components interpret as fresh mint or release authority.
  • Make relayers and guardians prove both emitter identity and message semantics: right contract, right channel, right handler, right route family, right state transition, and where possible the matching custody or balance-change context.
  • Parse and authenticate at the smallest meaningful unit. If one transaction or receipt can contain both a legitimate bridge log and attacker-authored lookalikes, downstream code must prove provenance for each artifact independently instead of trusting the surrounding batch.
  • Keep degraded-mode and failover validation on the same authenticity object as the primary path. If fallback mode cannot prove the same emitter and semantic guarantees, it should stop delivery rather than broaden authorship.
  • Diff every code path that can emit the same topic, packet shape, or message body and assume the weakest path will define security unless relayers can distinguish them mechanically.
  • Review resource remaps, wrapper introductions, compatibility shims, and channel migrations as changes to bridge truth itself. If they can widen who may author a bridge fact, they deserve the same scrutiny as verifier code changes.
  • Test for forged-provenance paths directly: attacker-owned emitter contracts, wrong-channel packets, helper-path emissions, refund-path artifacts, and lookalike events emitted without custody change.

Audit prompts

  • Which source-authorship promotion is happening at each step here: parseable bridge-looking artifact, accepted canonical source-route truth, or destination-side authority to mint / release against real value?
  • For each relay-authoritative message type, what exact tuple defines canonical provenance: contract address, chain / domain, channel / endpoint, function or handler path, and required post-condition?
  • Can any non-canonical contract, helper module, refund path, wrapper, or compatibility layer emit the same event signature or message shape relayers consume?
  • Do relayers prove right emitter only, or do they also prove right semantics — that the observed artifact came from the custody-changing or otherwise authorized path rather than from an adjacent flow?
  • If the protocol uses source-channel or endpoint allowlists, where are they enforced and can an attacker introduce packets from a different but still syntactically valid channel?
  • What happens in degraded mode, RPC failover, guardian outage handling, or manual replay tooling? Does any emergency path widen who can author bridge truth?
  • Can upgrades, resource remaps, factory changes, or wrapper deployments silently broaden the emitter set without forcing corresponding relayer-policy updates?
  • Are there shared event schemas across deposit, refund, withdrawal-return, migration, or recovery paths that require offchain components to guess which semantics they just saw?
  • Does any watcher or guardian pipeline rely on generic log scanning, topic matching, or payload shape without checking canonical contract address and path-specific state?
  • If one legitimate bridge event appears in a transaction alongside several attacker-authored lookalikes, does the parser authenticate each artifact independently or accidentally trust the whole receipt / batch?
  • If a forged source artifact were accepted today, what operational control actually stops downstream signing or execution: route-local pause, guardian denylist, emitter revocation, or only a full bridge halt after losses begin?

Lessons that should already be standard

  • Something bridge-looking happened, that artifact counts as canonical source-route truth, and that accepted truth now deserves live mint or release authority are three different claims.

  • Bridge messages are not authentic because they parse. They are authentic because one narrowly defined source of truth was allowed to author them.

  • The log came from our ecosystem is not a security property. Bridges need the log came from the one canonical contract, on the one canonical channel, in the one state transition that was allowed to create this fact.

  • Offchain relayers inherit the bridge’s semantics burden. If the onchain authoring surface is ambiguous, no amount of honest relaying repairs it.

  • Shared event schemas across deposit, refund, and helper paths are not cosmetic API choices; they are part of the authenticity boundary.

  • Fallback validation is verifier code. If degraded mode accepts a weaker provenance proof, the bridge has already changed what counts as truth under stress.

  • Upgrades and compatibility wrappers often break provenance before they break cryptography. We did not touch the verifier is not reassuring if the emitter surface quietly widened.

  • Source-authentication failures often look like relayer mistakes in hindsight, but the deeper protocol mistake is making authentic and lookalike source artifacts too hard to distinguish.

  • One real bridge event does not sanitize its neighbors. If a parser trusts a transaction, receipt, or mixed batch instead of each message artifact’s own provenance, attackers can hide counterfeit bridge truth beside authentic traffic.

  • The positive design target is boringly explicit authorship: one route, one message type, one canonical speaker, one semantically committed artifact.

  • 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)]] — a fake Alephium-side contract emitted forged bridge message material and a fallback guardian-validation path treated it as canonical enough for legitimate guardians to sign.
    • pNetwork pBTC-on-BSC fake peg-out log processing drain (2021-09-19) — pNetwork nodes processed peg-out-looking logs from attacker contracts alongside a legitimate request because the Rust extractor failed to prove canonical emitter provenance.
    • unbacked qXETH mint (2022-01-27) — the generic deposit() path could emit the same Deposit signal relayers expected from the real ETH-locking path even though no ETH had moved.
    • THORChain ETH Router fake-deposit refund drain (2021-07-22) — returnVaultAssets() could still produce a deposit-looking router event with attacker-chosen memo semantics, and Bifrost treated that artifact as authentic inbound bridge input.
    • unbacked saToken mint (2026-06-10) — the packets were real, but the Secret-side bridge forgot to prove they arrived from Axelar’s canonical channel, so an attacker-controlled chain could author mintable bridge truth for assets backed elsewhere.

Internal linkages

Control surface

Graph View

Backlinks