Binance Bridge Hack

Exploit overview

On 6 October 2022 an attacker tricked Binance Bridge to issue 2M BNB (worth ~$550M at that moment). The attacker then used the “printed” BNB as a collateral to borrow multiple other assets and transferred them to other EVM-compatible chains. Approximately $130M worth of assets were moved out. The rest were frozen.

How crosschain bridges work?

Assume that we have two chains (Chain_A and Chain_B). Both chains implement smart-contracts. There is a “crosschain bridge” between chains A and B that allows users to swap asset_A from chain_A to chain_B.
In fact, the “crosschain bridge” consists of three main components:
  • Smart-contract on chain_A — this contract accepts deposits of asset_A on chain_A and emits an event that indicates that some quantity of asset_A was deposited by the user and it needs to be swapped to chain_B.
  • Smart-contract on chain_B —this contract can create wrapped tokens. Whenever a user wants to swap X quantity of asset_A from chain_A, a contract on chain_B creates X quantity of wrapped_asset_A and sends it to the user’s address.
  • Relay —it is important to note that a smart contract cannot access any information outside of the chain on which it is deployed. It is impossible for the contract on chain_B to read any information about the state of contract on chain_A. Relay is a service that forwards data from one chain to another. When it sees a deposit to the contract on chain_A the relay pushes contract on chain_B so that it would create wrapped tokens.
In most cases there are sophisticated rules of how relays communicate with contracts and how it is verified that what is being relayed has actually happened.
If the relay will tell contract on chain_B to create tokens by mistake is that it would create tokens that are not backed by the actual deposited amount of original asset on the original chain.

What happened?

On 5th October 2022 the attacker purchased 100 BNB at ChangeNow. Then the attacker registered as a Relayer for BSC Token Hub. Token Hub acts as a bridge between BNB Beacon Chain (BEP2) and Binance Smart Chain (BEP20).
After that the attacker exploited a vulnerability in BSC Token Hub proofs verification model to create an arbitrary message on block 110217401 (you can read the full analysis of how it was done here). This allowed the attacker to cause the Bridge to “print” 2,000,000 BNB out of thin air as if it was swapped while in fact these were not.
On 6:26 PM UTC the attacker tricked the Bridge to print 1,000,000 BNB. After that the attacker made 15 sequential attempts to print another 1M BNB but none of these were successful. 16th transaction at 8:43 PM UTC was successful and the attacker received another 1,000,000 BNB.
The attacker used a lending protocol Venus to put 900,000 BNB as a collateral to borrow USDT, USDC and BUSD. The stablecoins were then swapped to other EVM-compatible chains. These funds are still under attackers control.
Binance team issued the announcement and halted BSC. Later the attackers funds that remained on BSC were burned.
Here you can find the official response from for the hack from Binance team.

The root of the problem

There was a bug in the proof verification model that was exploited and allowed the attacker to deceive the Bridge and cause it to “print” funds that should not have existed.
The contracts system and relays model was not audited or at least there is no publicly available audit report.
The response from Binance team and community was quick and effective, even though a huge quantity of assets was swapped to other chains where Binance had no control over the funds. A total $100,000,000 worth of stablecoins were swapped away.


This attack was executed with a high level of expertise from hackers side. The attacker was very familiar with internal structure of the Bridge, BSC ecosystem and possible responses. As the result, the attacker managed to swap away a significant amount of funds despite the reaction from the BSC team and the community.
There were no attempts to communicate with the hacker.
There was no public bug bounty, which in turn meant that the hacker had no way to monetize the vulnerability other than exploiting it.
Security audit by a third party should have been conducted but this was not done.