GHSA-8rc9-vxjh-qjf2
MEDIUMVega's validators able to submit duplicate transactions
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
code.vegaprotocol.io/vegaReal-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:
- Cause an Ethereum event on one of the bridge contracts e.g a deposit to the collateral bridge, or the staking bridge
- This will result in the Ethereum-event-forwarder of each node to submit a ChainEvent transaction to the Vega network corresponding to that event
- Scrape the valid chain event transaction from the Tendermint block data using a node’s Tendermint API
- Change the value of the
txIdfield of the ChainEvent to any valid, but different, value - Bundle the tweaked ChainEvent into a new transaction, sign it with a validator key and resubmit to the Vega network
- 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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | code.vegaprotocol.io/vega | all versions | 0.71.6 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.vegaprotocol.io/vega. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
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.
How O3 protects you
O3 pinpoints whether GHSA-8rc9-vxjh-qjf2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-8rc9-vxjh-qjf2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-8rc9-vxjh-qjf2 in your dependencies?
O3 detects GHSA-8rc9-vxjh-qjf2 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.