Vega is a decentralized trading platform that allows pseudo-anonymous trading of derivatives on a blockchain. Prior to version 0.71.6, a vulnerability exists that allows a malicious validator to trick the Vega network into re-processing past Ethereum events from Vega’s Ethereum bridge. For example, a deposit to the collateral bridge for 100USDT that credits a party’s general account on Vega, can be re-processed 50 times resulting in 5000USDT in that party’s general account. This is without depositing any more than the original 100USDT on the bridge. Despite this exploit requiring access to a validator's Vega key, a validator key can be obtained at the small cost of 3000VEGA, the amount needed to announce a new node onto the network.

A patch is available in version 0.71.6. No known workarounds are available, however there are mitigations in place should this vulnerability be exploited. There are monitoring alerts for `mainnet1` in place to identify any issues of this nature including this vulnerability being exploited. The validators have the ability to stop the bridge thus stopping any withdrawals should this vulnerability be exploited.

Affected: Go: code.vegaprotocol.io/vega

A vulnerability exists that allows a malicious validator to trick the Vega network into re-processing past Ethereum events from Vega’s Ethereum bridge. For example, a deposit to the collateral bridge for 100USDT that credits a party’s general account on Vega, can be re-processed 50 times resulting in 5000USDT in that party’s general account. This is without depositing any more than the original 100USDT on the bridge.

Despite this exploit requiring access to a validator's Vega key, a validator key can be obtained at the small cost of 3000VEGA, the amount needed to announce a new node onto the network.

The steps to carry out this exploit are as follows: 1. Cause an Ethereum event on one of the bridge contracts e.g a deposit to the collateral bridge, or the staking bridge 2. This will result in the Ethereum-event-forwarder of each node to submit a ChainEvent transaction to the Vega network corresponding to that event 3. Scrape the valid chain event transaction from the Tendermint block data using a node’s Tendermint API 4. Change the value of the `txId` field of the ChainEvent to any valid, but different, value 5. Bundle the tweaked ChainEvent into a new transaction, sign it with a validator key and resubmit to the Vega network 6. The fraudulent ChainEvent will be processed by Vega as if it were a new ChainEvent even though it did not occur on Ethereum

The key to this exploit is in step 4. The `txId` field of the ChainEvent is used when checking for ChainEvent resubmission,…