GHSA-jm5c-rv3w-w83m is a medium-severity (CVSS 6.5) vulnerability in github.com/ethereum/go-ethereum. A fix is available for github.com/ethereum/go-ethereum — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-jm5c-rv3w-w83m by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
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.18go get github.com/ethereum/go-ethereum@v1.9.18 |
| 🐹Go | github.com/holiman/uint256 | ≥ 0.1.0&&< 1.1.1 | 1.1.1go get github.com/holiman/uint256@v1.1.1 |
Affected Products
go ethereumethereumDetection & 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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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.
Frequently Asked Questions
Is GHSA-jm5c-rv3w-w83m in your dependencies?
Find it across Go, including transitive dependencies.