Lately PolyNetwork is hacked, which leads millions of dollars to be drained.

Poly team says:

The hacker exploited a vulnerability between contract calls, exploit was not cause by the single keeper as rumored.

I was wondering how is Poly Network Hack is done. What are the vulnerabilities in the Solidity code.

=> Could there be any handle mechanism by Solidity or some kind of approval mechanism before to prevent this hack?


Poly Network suffered a major hack with a total of $610 million USD in cryptocurrencies being stolen.

  • no vunerabilities in Solidity, just the same old spoofing technique
    – Nulik
    Aug 13, 2021 at 4:25
  • What is the just the same old spoofing technique? If there is no vunerabilities in Solidity, there shouldn't be no hack. By sending this cross-chain message, the user could trick the EthCrossChainManager into calling the EthCrossChainData contract, passing the onlyOwner check.
    – alper
    Aug 13, 2021 at 7:42
  • Hacks are caused by bugs in the code Solidity users write - not bugs in Solidity itself. So there was simply some faulty logic in the code written in Solidity by someone Aug 16, 2021 at 4:41

2 Answers 2


The following is taken from these two sources:

  • Twitter thread from Kelvin Fichter (link)
  • report from Peckshield (link)

Basically, Poly has a contract which is in charge of verifying that that it's being communicated with by the right accounts. This is a whitelist, a list of addresses which are approved to send messages to the system about the state of txs on different chains. This contract is called EthCrossChainData, we'll call it simply Data. If you could get your address added to this whitelist, then you'd be able to tell Poly whatever you like and it would believe you. For example, you'd be able to tell Poly that all the assets in Poly actually belong to you now because you've made the relevant transactions locking up funds against them on other chains, and the network would just believe you.

This is exactly what the hacker did. But how?

The Data contract was owned by another contract: the EthCrossChainManager contract, which we'll call the Manager contract. Part of the purpose of the Manager is to execute calls from other chains, which means that it has functions for executing somewhat arbitrary code, and in this case, was also left a bit more open than it should be - in particular, anyone from another chain could call a function called verifyHeaderAndExecuteTx, which could call other Poly Network contracts. Remember how Manager was the owner of Data? That means that if the hacker could figure out how to create a payload that the Manager contract would interpret as meaning it should add the hacker to the whitelist on the Data contract, it would do so.

As I'm sure you figured out, that's what the hacker did. The truth is a bit more complicated, though. The verifyHeaderAndExecuteTx would only execute code that conformed to the function signature of _method, "(bytes,bytes,uint64)" - a function signature is the first 4 bytes of the keccak256 hash of the name and arguments of a function (you can read more about that in this excellent article in the section called "Function Signatures"). This might have helped stop the function from calling any other function, but since _method was a user-generated, all the hacker had to do was figure out how to put some arbitrary value there that would make the first 4 bytes of the keccak256 hash conform to the target payload they wanted. (In other words, they didn't need a hash collision since the function selector only uses the first four bytes, and colliding four bytes isn't that hard.)

Once they were able to construct a payload that collided with the function signature for getting themselves added to the whitelist, they added themselves on every chain they could and drained all the funds.


Poly Network smart contract performing bridged arbitrary (user-defined) calls on behalf of users had an ownership on locked (bridged) tokens vault smart contract. Hacker bridged fake call to make this smart contract to add hacker's public key to tokens vault smart contract.

Arbitrary (user-defined) calls functionality should have been extracted to separate smart contract, which have nor balances nor ownership rights.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.