NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

go-ethereum vulnerable to DoS via malicious p2p messageGHSA-4xc9-8hmq-j652

HIGH

GHSA-4xc9-8hmq-j652 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption 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.

Also known asCVE-2024-32972GO-2024-2819
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-4xc9-8hmq-j652.

EPSS Exploitation Probability

via FIRST.org ↗
0.8%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs58th percentile — riskier than 58% of all scored CVEsHighest risk
0.11%0.52%0.93%1.35%0.6%0.8%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐹github.com/ethereum/go-ethereum

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

Impact

A vulnerable node can be made to consume very large amounts of memory when handling specially crafted p2p messages sent from an attacker node.

In order to carry out the attack, the attacker establishes a peer connections to the victim, and sends a malicious GetBlockHeadersRequest message with a count of 0, using the ETH protocol.

In descendants := chain.GetHeadersFrom(num+count-1, count-1), the value of count-1 is passed to the function GetHeadersFrom(number, count uint64) as parameter count. Due to integer overflow, UINT64_MAX value is then passed as the count argument to function GetHeadersFrom(number, count uint64). This allows an attacker to bypass maxHeadersServe and request all headers from the latest block back to the genesis block.

Patches

The fix has been included in geth version 1.13.15 and onwards.

The vulnerability was patched in: https://github.com/ethereum/go-ethereum/pull/29534

Workarounds

No workarounds have been made public.

References

No more information is released at this time.

Credit

This issue was disclosed responsibly by DongHan Kim via the Ethereum bug bounty program. Thank you for your cooperation.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/ethereum/go-ethereumall versions1.13.15go get github.com/ethereum/go-ethereum@v1.13.15

Detection & mitigation playbook

Open-source dependency

  1. Detect

    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.

  2. Fix

    Update github.com/ethereum/go-ethereum to 1.13.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4xc9-8hmq-j652 is resolved across your whole dependency graph.

  3. Workarounds

    Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.

Frequently Asked Questions

### Impact A vulnerable node can be made to consume very large amounts of memory when handling specially crafted p2p messages sent from an attacker node. In order to carry out the attack, the attacker establishes a peer connections to the victim, and sends a malicious `GetBlockHeadersRequest` message with a `count` of `0`, using the `ETH` protocol. In `descendants := chain.GetHeadersFrom(num+count-1, count-1)`, the value of `count-1` is passed to the function `GetHeadersFrom(number, count uint64)` as parameter `count`. Due to integer overflow, `UINT64_MAX` value is then passed as the `cou
O3 Security · Impact-Aware SCA

Is GHSA-4xc9-8hmq-j652 in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works
go-ethereum vulnerable to DoS via malicious p2p message