The Initial Analysis of the PolyNetwork Hack

The Initial Analysis of the PolyNetwork Hack

The PolyNetwork has been hacked and more than 300 million USDs have been stolen. The attacker performed the attack on multiple chains. In this blog, we use the attack transaction on Ethereum (0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a ) to analyze the possible reason of the hack. Our initial analysis shows that one possible reason could be either the leakage of the private key that is used to sign the cross-chain message, or there is a bug in the signing process of the PolyNetwork that has been abused to sign a crafted message.

Disclaimer: This blog only contains the result of our initial analysis based on the onchain data on Ethereum. We cannot verify our findings without further information from Poly Network.

Update 2021/08/12: The further information shows that the cause of the attack is because the keeper has been modified by the attacker (not because of the leakage of the private key). We have a further analysis to answer the question why the transaction to change the keeper can be executed in the first place.

Transaction and call trace

We use our transaction analysis system to recover the trace.

Attacker -> EthCrossChainManager -> EthCrossChainData -> LockProxy -> managerProxyContractforLockProxy

  • 0xc8a65fadf0e0ddaf421f28feab69bf6e2e589963: Attacker
  • 0x838bf9e95cb12dd76a54c9f9d2e3082eaf928270: EthCrossChainManager
  • 0xcf2afe102057ba5c16f899271045a0a37fcb10f2: EthCrossChainData
  • 0x250e76987d838a75310c34bf422ea9f1ac4cc906: LockProxy
  • 0x5a51e2ebf8d136926b9ca7b59b60464e7c44d2eb: managerProxyContract for LockProxy

Function Signatures:

  • d450e04c (verifyHeaderAndExecuteTx)
  • 69d48074 (getCurEpochConPubKeyBytes)
  • 5ac40790 (getCurEpochStartHeight)
  • 0586763c (checkIfFromChainTxExist)
  • e90bfdcf (markFromChainTxExist(uint64,bytes32))

The main process of the attack

The main process of the attack is that the attacker passed the signed data to the function verifyHeaderAndExecuteTx(). This function will decode the data and verify the signatures that are used to sign the data. If this process passes, the method (and the contract address) specified in the message will be executed. During this attack, the unlock function of the smart contract 0x250e76987d838a75310c34bf422ea9f1ac4cc906 is invoked to transfer the Fei to the attacker.

In summary, the attack is due to the valid parameters passed to the verifyHeaderAndExecuteTx function. And the parameters can pass the signature verification process. After that, the transaction specified in the message will be executed (like the arbitrary command execution in software security.)

To better understand this process, we recover the critical values of the call trace.

Function: verifyHeaderAndExecuteTx:

verifySig

unlock

The variable of managerProxyContract in the LockProxy. It matches the value of the caller address of the unlock function.

Conclusion

From the recovered values, we find that:

  1. The attacker provides a valid signed message to the function verifyHeaderAndExecuteTx
  2. The onlyManagerContract modifier in the LockProxy smart contract is NOT bypassed.

Based on these two observations, we suspect that

  1. The attacker may have the legitimate keys to sign the messages, which indicate the signing keys may have been leaked.

Or

  1. There is a bug in the signing process of the PolyNetwork that has been abused to sign a crafted message.

However, we do not have further offchain data to verify our findings. We hope our analysis can be helpful for further investigation.

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

Twitter: https://twitter.com/BlockSecTeam

Sign up for the latest updates
#1 Cetus Incident: One Unchecked Shift Drains $223M in the Largest DeFi Hack of 2025

#1 Cetus Incident: One Unchecked Shift Drains $223M in the Largest DeFi Hack of 2025

Cetus Protocol, the largest concentrated-liquidity DEX on Sui, was exploited on May 22, 2025, resulting in an estimated ~$223M loss across multiple liquidity pools. The attacker leveraged a flaw in checked_shlw(), a custom overflow-prevention helper used in fixed-point u256 math, where an incorrect constant and comparison failed to block unsafe left shifts and caused silent truncation of high bits during liquidity delta calculations. By crafting specific liquidity and tick/price-range parameters, the exploit made required deposits appear near-zero while minting an oversized liquidity position, which was later withdrawn to drain real pool reserves.

#2 Bybit Incident: A Web2 Breach Enables the Largest Crypto Hack in History

#2 Bybit Incident: A Web2 Breach Enables the Largest Crypto Hack in History

The largest crypto hack ever, the February 21, 2025 Bybit breach stole about $1.5B after attackers used social engineering to compromise a Safe{Wallet} workflow, injected malicious JavaScript into an AWS S3 bucket, tampered with the transaction signing process, and upgraded Bybit’s Safe{Wallet} contract to a malicious implementation that drained funds across multiple chains.

Weekly Web3 Security Incident Roundup | Jan 25 – Feb 1, 2026

Weekly Web3 Security Incident Roundup | Jan 25 – Feb 1, 2026

During the week of January 25 to February 1, 2026, six blockchain security incidents were reported with total losses of ~$18.05M. These involved improper input validation, token design flaws, key compromises, and business logic errors across DeFi protocols on multiple chains. The primary causes included unchecked user inputs enabling arbitrary calls, flawed burn mechanisms allowing price manipulation, compromised developer tools, and missing solvency checks in lending functions.