# Vega's validators able to submit duplicate transactions 🐹 🐹 Go Not in CISA KEV MEDIUM severity # Vega's validators able to submit duplicate transactionsGHSA-8rc9-vxjh-qjf2 MEDIUM [Fix: vegaprotocol/vega@56b09bf](https://github.com/vegaprotocol/vega/commit/56b09bf57af8cd9eca5996252d86f469a3e34c68) GHSA-8rc9-vxjh-qjf2 is a medium-severity (CVSS 6) Improper Input Validation vulnerability in code.vegaprotocol.io/vega. 1 public exploit or proof-of-concept reference is indexed, so weaponization risk is real. A fix is available for code.vegaprotocol.io/vega — see the affected versions and patch details below. Also known as[CVE-2023-35163](/vulnerability/CVE-2023-35163)GO-2023-1865 Published Jun 20, 2023 Updated Aug 20, 2024 Affected 1 pkg Patched 1 / 1 Exploits 1 known Exploitation data as of Nov 12, 2026 · OSV.dev, NVD, FIRST.org (EPSS) ## Exploitation Status ### Proof-of-concept exploit code exists - CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation. Exploitation and automatability from CISA’s SSVC triage for GHSA-8rc9-vxjh-qjf2. ## EPSS Exploitation Probability [via FIRST.org ↗](https://www.first.org/epss/) 0.5%probability of exploitation in next 30 days Lower Risk0.00% Lower risk than most CVEs43th percentile — riskier than 43% of all scored CVEsHighest risk 0.00%0.33%0.66%0.99%0.1%0.5%0.5%May 26Sep 26Nov 26 Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/). ## How urgent is this, really ## Where this sits among everything scored ## Real-World Exposure 1 pkg affected 🐹`code.vegaprotocol.io/vega` Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems. ## Description 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, but NOT during the subsequent on-chain verification of the event. Therefore changing the `txId` of an existing ChainEvent is enough to by-pass the duplication check and for it to still be verified as a real event. #### Impact The impact of this exploit is dependent on the ChainEvent being manipulated. The below table describes each one: Chain Event Allows Consequence Deposit Generation of unlimited funds of any asset Withdrawal of all assets Stake Deposit Delegate unlimited Vega to a single node A single node has controlling amount of voting power Stake Removed Force a Validator node to drop below self-stake requirements Prevents reward payouts Bridge Stop The Vega network to think the bridge is stopped Prevent anyone from withdrawing funds Signer Removed The Vega network to think a validator nodes is not on the multisig contract Prevent reward payouts #### Patches v0.71.6 #### Workarounds No work around known, 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 #### References N/A ## Affected Packages 1 total 1 fixed Ecosystem Package Vulnerable range Fix 🐹Go `code.vegaprotocol.io/vega` all versions 0.71.6`go get code.vegaprotocol.io/vega@v0.71.6` ## Affected Products 1 product · 1 configurations Application `vega`gobalsky < 0.71.6 range Exploits & PoCs 1 Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization. [ Vega is a decentralized trading platform that allows pseudo-anonymous tr… github.comNVDJul 2023 ](https://github.com/vegaprotocol/vega/security/advisories/GHSA-8rc9-vxjh-qjf2) ## Detection & mitigation playbook Open-source dependency 1. ### Detect Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.vegaprotocol.io/vega, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version. 2. ### Fix Update code.vegaprotocol.io/vega to 0.71.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8rc9-vxjh-qjf2 is resolved across your whole dependency graph. 3. ### Workarounds If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands. ## Frequently Asked Questions 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 O3 Security · Impact-Aware SCA ### Is GHSA-8rc9-vxjh-qjf2 in your dependencies? Find it across Go, including transitive dependencies. [Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)