Poly Network — Cross-Chain Bridge — 2021-08-10

Summary

On August 10, 2021, an attacker exploited a privilege boundary between two Poly Network smart contracts: EthCrossChainManager (the manager contract authorised to dispatch cross-chain messages) and EthCrossChainData (the data contract storing, among other things, the keeper authority list that determines which signers are accepted as bridge validators). The manager contract was permitted to invoke arbitrary functions on the data contract. By constructing crafted call-data that, when relayed through the manager, resolved to a function-selector matching putCurEpochConPubKeyBytes on the data contract, the attacker overwrote the keeper authority list — granting an attacker-controlled key the right to authorise outbound cross-chain transfers. With keeper authority obtained, the attacker then issued seemingly legitimate withdrawal messages and drained ~$611M of assets across three chains.

Poly Network is structurally a cross-chain bridge, so contributors will reasonably ask whether this should be classified under OAK-T10 (Bridge & Cross-Chain Compromise). For OAK's purposes the failure mode is not at the validator-set or message-verification layer — the bridge's verification logic worked exactly as designed, accepting messages signed by whatever key the keeper list held. The failure is one layer earlier: the manager contract's privilege over the data contract was scoped too broadly, allowing keeper-list mutation through a path that the access-control model did not intend. That is the canonical T9.004 shape (privilege-boundary misconfiguration between contracts), and Poly Network is the most-cited large-loss case for it. The Wormhole worked example documents the adjacent T9.004 / T10.002 boundary case where cross-classification is warranted; Poly Network is the case that clarifies where cross-classification is not warranted, and is therefore equally useful as a contributor reference.

Timeline (UTC)

When	Event	OAK ref
2021-08-10 (T+0)	Attacker submits a transaction to EthCrossChainManager whose payload, when forwarded to EthCrossChainData, resolves to a call to putCurEpochConPubKeyBytes, overwriting the keeper public-key list with attacker-controlled values	T9.004 setup
2021-08-10 (T+0, same window)	Equivalent keeper-overwrite operations executed on Binance Smart Chain and Polygon Poly Network deployments	T9.004 setup (multi-chain)
2021-08-10 (immediately after)	Attacker, now an authorised keeper, issues outbound cross-chain transfer messages and extracts ~$611M aggregated across Ethereum, BSC, and Polygon	T9.004 extraction
2021-08-10 (within hours)	Tether freezes ~$33M of USDT on the Ethereum side, reducing the liquid attacker position	(response, asset-issuer)
2021-08-11	Attacker begins returning funds; publishes self-Q&A messages embedded in transaction call-data framing the action as a white-hat disclosure ("Mr. White Hat" persona)	(recovery begins)
2021-08-11 to 2021-08-25	Staged returns across all three chains; Poly Network publicly offers a $500K bug bounty and "chief security advisor" position, both declined	(recovery + governance response)
Approximately 2021-08-25	Final tranche of recoverable funds returned. Roughly $33M of frozen USDT remained inaccessible to both sides until issuer-side resolution	(recovery complete)

What defenders observed

• Pre-event (audit / formal-verification layer): the manager-to-data privilege boundary was a standing access-control flaw from deployment. A privilege-graph review asking "which functions on the data contract can be invoked, transitively, by externally-submitted manager call-data?" would have surfaced putCurEpochConPubKeyBytes as reachable through a path the design did not intend. This is the same family of finding that disciplined inter-contract privilege analysis is meant to catch and is the direct mitigation lesson generalisable beyond bridges.
• At-event: the keeper-list-overwrite transaction was on-chain visible in real time. The discriminating signal was a state-write to the keeper authority storage slot of the data contract from a non-governance, non-upgrade transaction path — an event that, in the contract's intended operation, should occur only via explicit governance or epoch-rotation flows. Per-contract invariant monitoring on "keeper-list mutations originate only from approved governance call-paths" would have detected the setup before extraction completed, but in practice no such monitoring was deployed at the time.
• Post-event: the extraction transactions themselves looked structurally legitimate from the bridge's verification standpoint — they were signed by the (newly attacker-controlled) keeper key. The unambiguous on-chain artefact distinguishing attack from normal operation is the keeper-list mutation in the preceding transaction, not the extraction transactions. This is a generalisable observation: in T9.004 cases the high-signal artefact is typically the privilege-state change, not the value-flow that follows.
• Recovery layer: asset-issuer freezes (Tether's USDT freeze) accounted for tens of millions; the remaining recovery was attacker-driven and depended entirely on the attacker's choice. The recovery is not a defensive baseline — it is an outcome that happened to occur and that defenders should not plan around.

What this example tells contributors writing future Technique pages

• Cross-chain ≠ T10. Poly Network sits in a cross-chain protocol but its failure is contract-layer access-control. Contributors writing T9.004 cases should not be deterred by the surrounding architecture; classify by failure mechanism, not by the protocol category. This is the inverse lesson of the Wormhole worked example, which documents the case where cross-classification with T10.002 is appropriate. Together, Poly Network and Wormhole calibrate the T9.004 / T10.002 boundary for future contributors.
• The high-signal artefact is the privilege-state change, not the value flow. Contributors writing T9.004 detection-signal sections should lead with privilege-state-mutation signals (storage-slot writes to authority lists, owner mutations, role-assignment events) and treat the subsequent value movement as a downstream confirmation rather than the primary detection point. Detection sections that lead with the value flow tend to fire late; sections that lead with the privilege-state change fire at the right point in the kill chain.
• White-hat-attacker self-framing is real and is not a defensive control. Contributors documenting outcomes should record what occurred without elevating attacker self-narrative into a category of mitigation. Recovery-by-attacker-return is a documented outcome class but not a defensive baseline. Future Technique pages should avoid implying that "the attacker may return funds" is a planning assumption — it is not.
• Cite forensic vendors, not attacker-authored Q&A. "Mr. White Hat" published self-Q&A embedded in transaction call-data. That call-data is part of the on-chain record and contributors may reference it as such, but the framing it provides is attacker self-narrative and must not be elevated above third-party forensic analysis. The CONTRIBUTING.md "cite or omit" rule applies with extra force in cases like this.

Public references

• Chainalysis — The Poly Network Hack: What We Know So Far — primary forensic post and asset-flow tracing during the recovery window.
• Elliptic — $600 Million Stolen From Poly Network — The Largest Crypto Theft Of All Time? — chain-by-chain breakdown and laundering-route analysis during the active phase.
• Kudelski Security — The Poly Network Hack Explained — technical post-mortem of the manager-to-data privilege boundary and the crafted call-data path.
• Merkle Science — Analysis of the Poly Network Hack — secondary technical analysis with on-chain transaction references.
• Poly Network — official incident statements (Twitter thread, 2021-08-10 onwards) — protocol-side disclosure and recovery announcements.

Discussion

Poly Network is an unusual data point in the OAK corpus because the loss-extraction phase was unambiguous and the recovery phase was effectively complete. Roughly $611M moved out of the bridge contracts within hours; roughly the same amount returned within fifteen days, modulo issuer-frozen USDT. Among large DeFi incidents up to OAK v0.1's coverage cut-off, this is one of the very few cases where post-event holdings approximated pre-event holdings within a short window. That outcome is structurally interesting but defensively useless: it depended entirely on the attacker's choice and on a small amount of asset-issuer cooperation. It is not an outcome defenders can plan toward, and OAK should not be read as endorsing the framing that Poly Network was "not really" a hack because the funds were returned.

The "Mr. White Hat" framing was contested in the security community at the time and remains contested. Treating an unauthorised ~$611M extraction as a vulnerability disclosure inverts the disclosure-vs-exploitation distinction that responsible-disclosure norms exist to maintain. Poly Network's offer of a $500K bug bounty and a "chief security advisor" role to the same actor — even though both were declined — set a governance precedent that has been cited unfavourably in subsequent incident responses, where protocols facing live extractions sometimes attempt analogous "negotiate-with-the-attacker" framings. OAK's position, consistent with the CONTRIBUTING.md writing-style rules, is to record the framing as documented behaviour without elevating it: this incident is a T9.004 access-control failure followed by an attacker-driven return, and it is filed under that classification.

For contributors: when a future incident involves an attacker-return outcome, follow this example's pattern. Document the return factually, attribute it to its actual cause (attacker choice, sometimes plus issuer-side freezes), and avoid treating the recovery as if it confirmed a defensive control. The defensive controls relevant to Poly Network are pre-deployment privilege-graph review and runtime privilege-state-mutation monitoring — neither of which was in place at the time, and both of which would have addressed the underlying T9.004 failure regardless of how the attacker subsequently chose to behave.