- Source
- Bitcoin Corebitcoincore.org
- Originally published
- Original length
- 2 min read
- Language
- English
SATWEI summary
Received messages could reach 32 MiB before Bitcoin Core 0.10.1, so an attacker could force that much RAM allocation per connection and possibly crash the node. Bitcointalk user Evil-Knievel reported it; #5843 cut the limit to 2 MiB, later raised to 4 MB for Segwit. A disclosure announced for 2015 was postponed, and the details came out in 2024.
Tags
- CVE
- P2P
More from Bitcoin Core
Slow unbounded memory growth on paused pre-BIP31 peers
By pretending not to support BIP 31 pings, a malicious peer could dodge the 20-minute disconnect and read slowly, swelling a node's send queue by up to 2MB per hour for each inbound peer and 5MB for each outbound one. CVE-2026-117349, rated Medium, is fixed by #36667 in Bitcoin Core 32.1, 31.2, 30.4 and 29.5; -blocksonly nodes were much less exposed.
Bitcoin Core
Bitcoin Core 30.4 released
Bitcoin Core 30.4 stops treating BIP 9 bits 5 to 28 as soft fork signals, following BIP 323, so blocks that set them no longer trigger unknown-deployment warnings (#34779). Network changes include a timeout enforced on paused send peers (#36667), and flatfile positions now use 64-bit integers (#36669).
Bitcoin Core
Unbounded memory growth through TCP urgent data on non-Linux systems
Windows, macOS and BSD nodes could be crashed by a connected peer sending TCP urgent data, which slipped past paused reads in the select() backend and queued memory without limit (CVE-2026-117350). Linux nodes use poll() and are not affected. Bitcoin Core 32.1, 31.2, 30.4 and 29.5 fix the Medium-severity bug, which an LLM scan under Project Loupe found.
Bitcoin Core