GHSA-w3hj-wr2q-x83g
Discovery uses the same AES/GCM Nonce throughout the session
Blast Radius
tech.pegasys.discovery:discoveryReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Discovery uses the same AES/GCM Nonce throughout the session though it should be generated on per message basis which can lead to the leaking of the session key. As the actual ENR record is signed with a different key it is not possible for an attacker to alter the ENR record. Note that the node private key is not compromised, only the session key generated to communicate with an individual peer.
From discovery spec:
The number of messages which can be encrypted with a certain session key is limited because encryption of each message requires a unique nonce for AES-GCM. In addition to the keys, the session cache must also keep track of the count of outgoing messages to ensure the uniqueness of nonce values. Since the wire protocol uses 96 bit AES-GCM nonces, it is strongly recommended to generate them by encoding the current outgoing message count into the first 32 bits of the nonce and filling the remaining 64 bits with random data generated by a cryptographically secure random number generator.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | tech.pegasys.discovery:discovery | all versions | 0.4.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for tech.pegasys.discovery:discovery. 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 tech.pegasys.discovery:discovery to 0.4.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w3hj-wr2q-x83g 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-w3hj-wr2q-x83g 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-w3hj-wr2q-x83g. 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-w3hj-wr2q-x83g in your dependencies?
O3 detects GHSA-w3hj-wr2q-x83g across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.