Decoding BSC Token Hub’s Contract Vulnerability

4 min read
Bsc Token Hub

Hacker attacked the cross-chain bridge BSC Token Hub on the BNB Chain resulting the loss of $566M.


On October 6, 2022, a hacker attacked the cross-chain bridge BSC Token Hub on the BNBChain and stole about 2 million $BNB tokens, worth approximately $566 million.

Introduction to BSC Token Hub#

BEP2 (BNB Beacon), and BEP20 or BSC (BNB Chain) are two popular blockchain networks of Binance exchange.

The BSC Token Hub is the BNB Chain ecosystem's internal cross-chain bridge that allows token transfers between the BNB Beacon Chain governance blockchain and the BNB Smart Chain (BSC) consensus layer.

Vulnerability Assessment#

The potential reason for this vulnerability is that the Binance Bridge had a bug in the way it verified proofs, which could have allowed attackers to forge arbitrary messages. BNB Chain Team stated that the exploit was accomplished through the sophisticated forging of the low level proof into a single common library.


Step 1:

The attacker had found a way to trick the Binance Bridge into sending them 1 million $BNB tokens, twice.

Step 2:

The block height used by the attacker was 110217401, however the height used by legitimate withdrawals were 270822321.

Step 3:

The attacker's proof was also significantly shorter than the legitimate withdrawl's pool. It is understood that the attacker had found a way to forge a proof for the block: 110217401.

Step 4:

On Binance, a special precompiled contract exists to verify IAVL trees.

Step 5:

The IAVL trees, as the name suggests, are trees like structures in which every node is labelled with a hash of some data. The bottom-most nodes are called leaves.

Step 6:

There are as many leaves as the number of data that need to be hashed, and the nodes between the leaves and the root are determined by the hash of the concatenated hashes of the nodes below it.

Step 7:

In the case of Binance Bridge, when we verify an IAVL tree, it expects two operations, an iavl:v operation, and a multistore operation.

Step 8:

In order to forge a proof, we need both operations to succeed, and we need the multistore operation to return a fixed value, which is the hash of the specified block, 110217401.

Step 9:

As per the implemented codebase, it is seen that the root hash is difficult to be manipulated. We need the input value (value := args[0]), to be equal to one of the core's commit IDs. The root hash is generated using the ComputeRootHash method.

Step 10:

The input value of the multistore operation is the output value of the iavl:v operation. This means we need to have some control over the root variable while still passing the value verification.

Step 11:

The way these hash functions are intended to work using trees, it is obvious that any pair (path, nleaf) will produce a unique hash.

Step 12:

As observed from the proof in a legitimate transaction, it has a very long path, no inner nodes, and only one leaf node. The leaf node contains the hash of the malicious payload.

Step 13:

If we can't change this leaf node, we'll have to create a new one. Similarly, if we add a new leaf node, we must also add a new inner node to match.

Step 14:

In order for the ComputeHash method to return the needed root hash, we will require a path to contain a non-zero right hash. When we find one that does, we assert it matches the intermediate root hash.

Step 16:

The attacker thus used a legitimate proof and modified it so that a new leaf is added to get a forged payload. He added a blank inner node to satisfy the prover, and then tweaked the leaf to exit early with the correct root hash.

Step 17:

This way the attacker forged two arbitrary messages, but the consequences could have been far worse.


The team temporarily paused BSC after the incident was disclosed. Changpeng Zhao, CEO of Binance, reported that the exploit resulted in the loss of more than $100 million worth of funds.

The exploiter transferred approximately $89.5 million of the stolen funds to other chains, with 58% going to Ethereum, 33% going to FantomFDN, and 4.5% going to Arbitrum. However, due to the involvement of community, internal, and external security partners, they were able to freeze $7 million in funds.

How to Prevent Such an Attack Vector#

In 2022 alone, bridges have lost over $2 billion due to more than a dozen hacks and smart contract vulnerabilities. No system is completely secure, and in order to help prevent the occurrence or reoccurrence of all such events, extremely stringent code audits must be implemented.

DeFi companies should invest sufficient resources in implementing standard security practices and encourage bounty hunters to disclose critical code vulnerabilities by allocating hefty reward programs.

Protocol, and Platform Security#

Our security team at Neptune Mutual can validate your platform for DNS and web-based security, smart contract reviews, as well as frontend and backend security. We can offer you a solution to scan your platform and safeguard your protocol for known and unknown vulnerabilities that have the potential to have catastrophic long-term effects. Contact us on social media if you are serious about security and have the budget, desire, and feeling of responsibility to do so.