Cowrie Research

pnetwork-pbtc-on-bsc-fake-pegout-log-processing-drain-2021-09-19

15 min read

pNetwork pBTC-on-BSC Fake Peg-Out Log Processing Drain (2021-09-19)

  • Name: pNetwork pBTC-on-BSC fake peg-out log processing drain
  • Date: 2021-09-19
  • Protocol: pNetwork / pBTC-on-BSC bridge
  • Chain: BNB Chain + Bitcoin
  • Category: bridge verification failure / message-source authentication failure / fake peg-out log processing / offchain node event-validation bug
  • Loss: 277 BTC, roughly $12.7M at the time
  • Summary: pNetwork’s pBTC-on-BSC bridge did not lose funds because Bitcoin multisig keys were stolen or because Bitcoin-side collateral somehow vanished on its own. It lost funds because the bridge’s offchain node stack let attacker-authored BNB Chain logs speak in the same peg-out voice as the canonical pToken contracts. The attacker funded a BNB Chain account, deployed contracts crafted to emit peg-out-looking events, and mixed one legitimate peg-out request with several counterfeit ones emitted by attacker contracts rather than by the real bridge contracts. pNetwork’s own postmortem says the bug lived in the Rust section that extracted those logs, so the nodes processed both the real and forged requests together instead of proving, log by log, who was allowed to author each peg-out instruction. The exploit began around 17:20 UTC; by then the bridge was already turning one real peg-out request plus several counterfeit neighbors into live BTC-release authority. The result was not just bad indexing but real BTC outflow: one authentic request effectively sanitized its counterfeit neighbors, and pNetwork’s bridge machinery released 277 BTC from the pBTC-on-BSC collateral against attacker-authored source-side message material.
  • Trigger / entry point:
    • pNetwork’s pBTC-on-BSC bridge relied on offchain nodes that watched BNB Chain for peg-out instructions and then executed the corresponding BTC-side release flow.
    • The attacker funded BNB Chain address 0x2bf5693dd3a5cea1139c4510fdce120cf042c934 from Binance before deploying contracts tailored to the bridge’s peg-out-observation logic.
    • Those contracts emitted a series of peg-out-looking logs: one legitimate request plus several forged ones emitted by attacker-controlled contracts rather than by the canonical pToken contracts.
    • pNetwork later said the attacker tried the same general offensive against multiple routes — pBTC-on-BSC, TLOS-on-BSC, PNT-on-BSC, pBTC-on-ETH, TLOS-on-ETH, and pSAFEMOON-on-ETH — but only the pBTC-on-BSC route turned those forged logs into real collateral loss.
    • The bridge’s Rust log-extraction path failed to reject the forged emitter context, so pNetwork nodes accepted the fake events as processable peg-out instructions.
  • Root cause:
    • The decisive failure sat in pNetwork’s source-authentication layer, not in Bitcoin custody cryptography.
    • Public postmortem language says the bug lived in the Rust code responsible for extracting the log events that pNetwork nodes interpreted as peg-out requests.
    • That extraction path treated mixed log context too coarsely: it processed both the legitimate pToken peg-out log and the attacker-generated counterfeit logs in the same crafted batch instead of proving, artifact by artifact, that every accepted request came from the canonical bridge contracts and from the canonical peg-out-authoring surface.
    • Once the offchain nodes accepted those forged logs as authentic bridge messages, the rest of the bridge behaved as designed and released real BTC collateral.
  • Exploit path:
    1. The attacker withdrew BNB from Binance into 0x2bf5693dd3a5cea1139c4510fdce120cf042c934 in transaction 0x23db0ee27e10517dea0659a743fd6df92d482ad6796851c71127e5049e7bbd88.
    2. They deployed smart contracts on BNB Chain specifically crafted to abuse the peg-out instructions pNetwork nodes watched for.
    3. Those contracts emitted a set of bridge-looking event logs: one legitimate peg-out request and multiple forged peg-out requests emitted from attacker contracts rather than the real pToken contracts.
    4. Due to the bug in the Rust event-extraction logic, pNetwork nodes extracted and processed both the legitimate and counterfeit logs instead of discarding the forged ones.
    5. The bridge therefore accepted attacker-authored source-side message material as real pBTC-on-BSC withdrawal instructions.
    6. Starting with exploit transaction 0x0eb55e02bce39ec1d2d2e911eca7dcca54e74841b53412c078185e43c5a2a551, the attacker drove the bridge into releasing BTC collateral for peg-out requests that should never have been considered authentic.
    7. In total, 277 BTC left the pBTC-on-BSC collateral pool; pNetwork later said the attacker also attempted similar attacks against other bridge routes but only the pBTC-on-BSC route was successfully exploited.
  • What the attacker needed to be true:
    • pNetwork nodes had to treat parsed BNB Chain log events as sufficient peg-out truth.
    • The log-extraction code had to fail open on emitter provenance, so bridge-looking logs from attacker contracts were processed alongside legitimate ones.
    • The downstream BTC-release machinery had to trust the output of that extraction stage without a second canonical-emitter or bridge-state sanity check.
    • The pBTC-on-BSC bridge had to hold enough BTC collateral for the forged peg-outs to cash out into real value.
  • Technical anatomy worth remembering:
    • This is a clean bridge lesson in shape of message versus source of message. The fake requests apparently looked valid enough structurally, but the bridge failed to prove they came from the canonical pToken contracts.
    • The bug sat in offchain bridge software, yet it was still custody-critical code. Once those nodes processed the wrong logs, Bitcoin collateral moved for real.
    • pNetwork’s own postmortem makes the key point plainly: the exploit was not that all peg-out requests were fake, but that one real peg-out and several attacker-authored ones were all accepted by the same extraction pipeline.
    • That makes pNetwork a particularly useful mixed authentic + counterfeit batch contamination exemplar inside the broader message-source-authentication family: one legitimate bridge request did not make its neighboring lookalike logs safe to trust.
    • The sharper positive-design lesson is the one captured in bridge source-provenance bundle and authoring-surface discipline: peg-out requests needed one explicit provenance bundle — right BNB Chain route, right canonical contract, right peg-out path, right semantic claim — and each accepted artifact needed to satisfy that bundle on its own.
    • That makes this incident a useful cousin to Qubit and THORChain. The exact artifact differed — fake peg-out logs rather than a zero-value deposit event or refund-path router event — but the recurring mistake was the same: the bridge authenticated bridge-looking source material without proving canonical provenance.
  • Representative transactions and addresses:
    • Attacker-funded BNB Chain EOA: 0x2bf5693dd3a5cea1139c4510fdce120cf042c934
    • Additional attacker-linked EVM address cited by pNetwork: 0xD27b89B384Ef33EB17F6D98AfD98A47332543664
    • Funding transaction from Binance: 0x23db0ee27e10517dea0659a743fd6df92d482ad6796851c71127e5049e7bbd88
    • First exploit transaction: 0x0eb55e02bce39ec1d2d2e911eca7dcca54e74841b53412c078185e43c5a2a551
    • Onchain $1.5M return-bounty message transaction: 0x5937ba4b846dfdae2119ff674716db6b9dabd264eec2f7c7b3f1b25889006ccb
    • Attacker Telos account cited by pNetwork: testacct1234
  • Response / mitigation:
    • pNetwork detected suspicious activity within minutes, noticed the misbehavior at about 17:33 UTC, stopped the main bridges by about 17:40 UTC, and halted all bridges by about 17:59 UTC.
    • By about 18:40 UTC the team says it had identified the attacker BTC addresses and reported them to exchanges for blacklisting.
    • The team isolated the bug, implemented a fix for the exploited pBTC-on-BSC route at about 19:45 UTC, and kept the rest of the bridge system paused while reviewing other routes for similar issues.
    • As bridges were reactivated, pNetwork says it added extra signed-transaction checks and extra transaction-processing checks intended to trigger protective actions when similar conditions appeared, plus temporary extra pre-broadcast review.
    • The team also published attacker-linked addresses and offered a $1.5M return bounty, including an onchain message transaction to the attacker.

Three bridge-truth promotions this incident collapsed

  1. Some peg-out-looking artifact existed on BNB Chain

    • The attacker could deploy contracts that emitted bridge-shaped log material, and one real peg-out request sat beside several forged siblings in the same broader extraction context.
    • That was already weaker than the pBTC bridge just received several real withdrawal requests: it only proved that one authentic request existed nearby and that multiple other artifacts had the right superficial grammar.

  2. Those extracted artifacts still counted as canonical pBTC-on-BSC peg-out truth

    • The dangerous promotion happened inside the Rust extractor: the bridge accepted the mixed set of logs as if each artifact had independently proved right emitter, right route, right peg-out semantics.
    • One legitimate request effectively laundered its counterfeit neighbors because the node pipeline authenticated the batch or receipt context more strongly than each log’s own provenance.

  3. That accepted peg-out truth still deserved immediate BTC-release authority

    • Once the forged siblings crossed the source-authentication boundary, the same parsed output still had ordinary line-of-sight to live Bitcoin collateral.
    • pNetwork did not have a narrower route-local quota, staged withdrawal lane, or signer-side provenance brake that could turn parser accepted one mixed batch into a smaller containable anomaly.

Pattern tags

  • message-source-authentication-failure
  • bridge-verification-failure
  • Mixed authentic-plus-counterfeit batch contamination / one legitimate peg-out request gave neighboring forged logs a shared extraction context they should never have inherited
  • Offchain event-ingestion code was itself a custody-critical authoring surface, because the Rust extractor decided which BNB Chain artifacts were allowed to become BTC-release instructions
  • Route-local source-authentication failure still had direct line-of-sight to live BTC collateral, so one parser mistake immediately became real reserve outflow rather than a quarantined queue anomaly

Why the exploit worked

  • pNetwork’s own Sep. 2021 postmortem makes the crucial mechanism unusually explicit: the attacker produced a series of event logs containing one legitimate peg-out request plus several forged peg-out requests emitted by attacker contracts, and the Rust code responsible for extracting those logs processed both sets together. That means the bridge failed before any BTC-side custody logic mattered; the route’s source-authentication layer had already accepted the wrong author.
  • The dangerous semantic collapse was not merely event looked plausible; it was one authentic peg-out artifact and several counterfeit neighbors entered one extraction pipeline without each artifact re-proving canonical provenance on its own. A real peg-out request did not make surrounding bridge-looking logs safe, but the extractor effectively treated the batch or receipt context as stronger than each log’s own emitter identity.
  • That makes pNetwork a useful cousin to Qubit and THORChain for a narrower reason than generic bridge event bug: the bridge was willing to cash out BTC against source-side material that preserved bridge-like shape and nearby authentic context, but not the required right contract, right peg-out path, right semantic claim bundle.
  • The exploit also preserves the operational lesson that offchain bridge software is not glue. Once the Rust extractor authored a false this is a real peg-out instruction statement, the remaining bridge machinery behaved honestly and released genuine BTC collateral.
  • pNetwork’s partial route survivability matters too. The attacker probed several routes, but only pBTC-on-BSC turned the forged logs into loss. That is a reminder that route-specific parser assumptions, emitter allow-lists, and downstream release posture can decide whether a shared bridge stack degrades into incident or near miss.

Detection and audit pivots

  • Treat offchain log extraction and normalization code as part of the bridge verifier, not monitoring infrastructure. Ask exactly which contract addresses, topics, path constraints, and semantic claims each extracted peg-out instruction must satisfy before the BTC-side signer flow ever sees it.
  • Audit mixed-log and mixed-receipt scenarios explicitly. If one authentic event appears alongside forged lookalikes, the parser should still validate emitter provenance, route identity, and payload semantics log by log rather than inheriting trust from neighboring context.
  • Enumerate every route-specific authoring surface for peg-out truth: canonical pToken contracts, helper contracts, proxy layers, chain-specific wrappers, and any contract that can emit bridge-shaped logs. If bridge nodes rely on event shape more strongly than emitter identity, the route already has a source-authentication bug.
  • Ask whether downstream release machinery independently constrains what the parser can spend. If the extractor lies once, do signer workflows, per-route quotas, staged withdrawals, or human review narrow the blast radius, or does one bad parsed event still reach full collateral release authority?
  • Compare behavior across sibling routes when one route is exploited and others survive. Divergence often reveals the real security boundary faster than generic same bridge family labels do: specific emitter filters, route-local parser branches, or asset-specific release thresholds may be the difference between harmless counterfeit logs and live reserve loss.

Failure-prevention checklist

  • Make peg-out truth route-local and explicit: one canonical contract allowlist, one canonical event signature set, one canonical chain+route identity, and one canonical semantic parser for each bridge lane. A bridge should never infer probably ours from receipt context or event shape alone.
  • Validate provenance log by log, not batch by batch. Every accepted event should independently prove right emitter, right route, right topic family, right payload semantics, right bridge state before it can influence release flow.
  • Treat offchain extraction and normalization code as custody code. Parser refactors, chain-integration changes, and route-specific helper logic should get the same review intensity as BTC signer or vault-release code.
  • Reject mixed-context contamination by default. If one transaction or receipt contains unexpected emitters, extra bridge-looking events, or route-incoherent combinations, fail closed and quarantine the whole artifact for review instead of inheriting trust from the one legitimate neighbor.
  • Bind downstream release to a narrower authenticated message object than parser said yes: route id, canonical source contract, nonce/request id, asset, recipient, and amount should survive into the signer path as one coherent provenance bundle.
  • Keep release authority blast-radius bounded even after parser failure: per-route quotas, delayed large withdrawals, signer-side route sanity checks, and fast pauses should stop one bad extraction result from immediately emptying live collateral.
  • Instrument for impossible parser outcomes: more than one peg-out request where only one should exist, unexpected emitter addresses, route-emitter mismatches, or one receipt producing multiple spendable BTC-release candidates.
  • Review sibling routes for parser drift proactively. pNetwork’s own incident shows that shared bridge families still fail route-locally, so each lane needs explicit emitter/provenance policy rather than generic family assumptions.

Audit prompts

  • What exact contract addresses are allowed to author peg-out truth on this route, and where is that allowlist enforced before any event reaches release logic?
  • If one real peg-out log appears next to forged lookalikes in the same transaction or receipt, what concrete code path forces each neighboring log to re-prove emitter provenance independently?
  • Does the extractor ever treat bridge-shaped event or same receipt as a legit event as stronger than event emitted by the canonical bridge contract?
  • What route-specific fields survive from log extraction into the BTC signer or release path: canonical source contract, nonce, asset, destination, amount, and route id, or only a looser parsed instruction object?
  • If the parser lies once, what downstream control still says no: signer-side contract allowlists, staged withdrawals, per-route quotas, delayed execution, or human review?
  • Can one source-chain artifact produce more than one spendable release instruction, and if so, what proves that multiplicity is intended rather than counterfeit batch contamination?
  • How would operators notice a pNetwork-style failure quickly: unexpected emitter addresses, multiple release candidates from one receipt, route-mismatch alerts, or large withdrawals following parser-edge cases?
  • Which parser branches differ across sibling bridge routes, and are those differences deliberate enough to explain why one route would be exploitable while another only sees a failed attempt?

Lessons that should already be standard

  • Offchain event-ingestion code is bridge custody code. Once it decides which source artifacts count as authentic, signer quorum quality no longer matters if the parser already chose the wrong author.
  • One legitimate bridge event does not sanitize neighboring lookalikes. Batch context and receipt adjacency are not authenticity proofs.
  • Event shape matched is weaker than canonical route author emitted this exact request. Bridges that forget that distinction are already letting parsers mint custody authority.
  • Route-local differences matter. A multi-route bridge can survive the same attacker on five lanes and still lose real collateral on the sixth because one parser branch, emitter filter, or release posture drifted.
  • Source-authentication failures need bounded release just as much as signature-verifier failures do. If one parser bug can immediately spend the full route treasury, the bridge has only one line of defense.
  • Mixed authentic-plus-counterfeit artifacts are not weird corner cases; they are exactly the kind of adversarial input bridge software should assume once attackers know the observed event grammar.

Why this incident matters

  • It preserves a bridge-failure mode that is easy to flatten into bridge bug but is analytically sharper as a source-authentication failure: the bridge nodes processed the wrong contract’s logs as if they were canonical peg-out instructions.
  • It is also a strong reminder that offchain parsers, log filters, and event-extraction code are part of the bridge’s live authenticity boundary, not just implementation glue.
  • pNetwork is especially valuable because it shows a narrower failure than wrong contract emitted a fake event: one real bridge request can also become dangerous if the extractor authenticates receipt context or batch context more strongly than each artifact’s own provenance.
  • Finally, pNetwork is a useful bridge-side comparison point because the exploit did not need to forge Bitcoin state or steal a signer quorum. It only needed to make the bridge’s own event-ingestion layer lie.
  • It also preserves the separate blast-radius question highlighted by bridge bounded release design: once one route’s log-authentication layer failed, that same mistake still had immediate line-of-sight to the route’s live BTC collateral instead of first hitting a tighter per-lane quota, staged release, or another narrow high-value brake.

Internal linkages

Control surface

Graph View

Backlinks