GHSA-jm5c-rv3w-w83m is a medium-severity (CVSS 6.5) vulnerability in github.com/ethereum/go-ethereum. O3 Security confirms whether GHSA-jm5c-rv3w-w83m is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Denial of service in geth
Real-World Exposure
github.com/ethereum/go-ethereum🐹github.com/holiman/uint256Real-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
Impact
Denial-of-service (crash) during block processing
Details
Affected versions suffer from a vulnerability which can be exploited through the MULMOD operation, by specifying a modulo of 0: mulmod(a,b,0), causing a panic in the underlying library.
The crash was in the uint256 library, where a buffer underflowed.
if `d == 0`, `dLen` remains `0`
and https://github.com/holiman/uint256/blob/4ce82e695c10ddad57215bdbeafb68b8c5df2c30/uint256.go#L451 will try to access index [-1].
The uint256 library was first merged in this commit, on 2020-06-08.
Exploiting this vulnerabilty would cause all vulnerable nodes to drop off the network.
The issue was brought to our attention through a bug report, showing a panic occurring on sync from genesis on the Ropsten network.
It was estimated that the least obvious way to fix this would be to merge the fix into uint256, make a new release of that library and then update the geth-dependency.
- https://github.com/holiman/uint256/releases/tag/v1.1.1 was made the same day,
- PR to address the issue: https://github.com/holiman/uint256/pull/80
- PR to update geth deps: https://github.com/ethereum/go-ethereum/pull/21368
Patches
Upgrade to v1.9.18 or higher
Workarounds
Not at this time
References
https://blog.ethereum.org/2020/11/12/geth_security_release/
For more information
If you have any questions or comments about this advisory:
- Open an issue in go-ethereum
- Email us at [email protected]
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/ethereum/go-ethereum | ≥ 1.9.16&&< 1.9.18 | 1.9.18 |
| 🐹Go | github.com/holiman/uint256 | ≥ 0.1.0&&< 1.1.1 | 1.1.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/ethereum/go-ethereum. 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 github.com/ethereum/go-ethereum to 1.9.18 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jm5c-rv3w-w83m 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-jm5c-rv3w-w83m 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-jm5c-rv3w-w83m. 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-jm5c-rv3w-w83m in your dependencies?
O3 detects GHSA-jm5c-rv3w-w83m across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.