Back to Blog

The Retrospection of the Poly Network Hack from a Security Researcher Perspective

Code Auditing
August 15, 2021

In this blog, we want to review the whole process of the Poly Network Hack and discuss the lessons learnt.

We knew that the poly Network was being hacked on Aug 10, 2021 (we use +8 time zone in this blog). However, there is no clue of how the hack was happening, and what is the root cause of the hack. As a security research team, we started our investigation.

Step 1: Find the attack transaction

We replayed the attack transaction 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a in our transaction virtualization system (https://tx.blocksecteam.com).

The trace is quite simple, which is different from other attacks that manipulate the price. They usually have very complicated function invocations (See the Popsicle hack.)

Step 2: Analyze the contract code

After getting the attack trace, we need to review the source code of the contract. Surprisingly, the poly network does NOT have verified source code on Etherscan. However, we managed to find the released source code on github.

After reviewing the source code, we did not find any obvious code vulnerability. We also compared the attack trace with a legitimate transaction trace and found that they are similar.

Step 3: Recover the critical states

Then we recovered the critical states during the attack. Since the attack is launched from the invocation of VerifyHeaderAndExecuteTxEvent, we recovered several critical variable values, which we have shared in our first analysis [1].

During this process, we found that there is only one keeper (see the above figure). Since the value is obtained from the attack trace and the attack transaction has passed all the signature verification, we thought the potential reason could be the leakage of the private key or a bug in the signing process of the server [1].

However, we made a mistake here. Analyzing an attack is like peeling an onion. You peel it one layer at a time, until you locate the real “root root root” cause. At that time, we did not peel the onion further to see whether the keeper had been changed!

Step 4: New clue

A couple of hours later, Kelvin and slow mist gave new clues on Twitter, showing the keep has been changed. The change process abuses the hash collision to invoke a powerful function — a “smart” hack.

Now we realized that our first analysis is not complete. Based on the latest information, we replayed the transaction that changed the keeper. Still the trace is a very simple.

But remember that, during this transaction, there are four keepers (instead of one). All these keys are the same with other legitimate transactions — which means the keys are legitimate. Here comes the question: why the transaction that changes the keeper can be put on the chain and get executed in the first place?

Step 5: Locate the source transaction

We then try to locate the source transaction since the Poly network is a cross-chain bridge. There should exist a source transaction somewhere. We did this by decoding the critical variable (as shown in the following picture). It shows the transaction hash of the source chain and the poly chain.

There is a trick that has not been mentioned elsewhere. The tx hash value in the variable has a different representation with the official value in the poly chain. For instance, the tx hash of the poly chain in the figure is 0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721a。But in the poly chain brower, the hash value is 1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80（do you see the difference?). We shared our findings in the EthereumSecurity tg group on Aug 11 16:55.

Step 6: Locate the root cause

But still, we cannot answer the question “why the transaction to change the keeper” can be packed on the chain? To answer this question, we started from the Ontology chain and found the transaction flow:

Ontology transaction -> Ontology relayer -> Poly chain -> Ethereum relayer -> Ethereum

We then read the source code of the Ontology chain and the relayers. After a couple of hours, we found that the Ontology relayer does not have enough validation for the cross-chain transaction. This can let the malicious transaction pack on the poly chain. After that the system is pwned.

After internal discussion and challenging, we released our findings on Aug 12 02:41 on Twitter and medium[3].

Lessons

  • Security by design. Security should be in the whole process of the DeFi project. Users entrust their money to the project. In turn the project should deserve the trust. Unfortunately, we saw the ignorance of the security by the Poly network. For instance, the lack of validation is an old school security vulnerability, which I taught on the undergraduate class.

  • There is no verified source code for such as DeFi project with more than 600M TVL. The basis of the decentralized infrastructure is trust and the foundation of the trust is transparency. Unfortunately, users are willing to put their money into a blackbox project, which surprises and worries me. How to improve the security sense of user probably needs a new solution.

Reference

[1]https://blocksecteam.medium.com/the-initial-analysis-of-the-polynetwork-hack-270ac6072e2a

[2]https://twitter.com/kelvinfichter/status/1425290462076747777

[3]https://blocksecteam.medium.com/the-further-analysis-of-the-poly-network-attack-6c459199c057

Credits: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @ BlockSecTeam

BlockSec (@BlockSecTeam) / Twitter

Sign up for the latest updates
~$7.04M Lost: GiddyDefi, Volo Vault & More | BlockSec Weekly
Security Insights

~$7.04M Lost: GiddyDefi, Volo Vault & More | BlockSec Weekly

This BlockSec weekly security report covers eight attack incidents detected between April 20 and April 26, 2026, across Ethereum, Avalanche, Sui, Base, HyperLiquid, and MegaETH, with total estimated losses of approximately $7.04M. The highlighted incident is the $1.3M GiddyDefi exploit, where the attacker did not break any cryptography or use a flash loan but simply replayed an existing on-chain EIP-712 signature with the unsigned `aggregator` and `fromToken` fields swapped out for a malicious contract, demonstrating how partial signature coverage turns any historical signature into a generic permit. Other incidents include a $3.5M Volo Vault operator key compromise on Sui, a $1.5M Purrlend privileged-role takeover, a $413K SingularityFinance oracle misconfiguration, a $142.7K Scallop cross-pool index injection, a $72.35K Kipseli Router decimal mismatch, a $50.7K REVLoans (Juicebox) accounting pollution, and a $64K Custom Rebalancer arbitrary-call exploit.

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

This BlockSec weekly security report covers four attack incidents detected between April 13 and April 19, 2026, across multiple chains such as Ethereum, Unichain, Arbitrum, and NEAR, with total estimated losses of approximately $310M. The highlighted incident is the $290M KelpDAO rsETH bridge exploit, where an attacker poisoned the RPC infrastructure of the sole LayerZero DVN to fabricate a cross-chain message, triggering a cascading WETH freeze across five chains and an Arbitrum Security Council forced state transition that raises questions about the actual trust boundaries of decentralized systems. Other incidents include a $242K MMR proof forgery on Hyperbridge, a $1.5M signed integer abuse on Dango, and an $18.4M circular swap path exploit on Rhea Finance's Burrowland protocol.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit