Crafted non-standard transactions could tie up a Bitcoin Core node for a few seconds each without getting the sender disconnected, giving an attacker a way to delay block propagation. CVE-2025-46598, rated Low, was reported by Antoine Poinsot and mitigated in v30.0 by cutting worst-case validation time.
Blocks over 1GB could overflow a size check on 32-bit Bitcoin Core nodes and crash them on the write to disk, but only as a compact block, and only against a victim running -maxmempool above 3GB with 1GB of transactions inside. Pieter Wuille found CVE-2025-46597, rated Low; capping -maxmempool on 32-bit systems closed it in 29.1 and 30.0.
Default minimum feerates drop in Bitcoin Core 28.3: -blockmintxfee to 1 satoshi per kvB, -minrelaytxfee and -incrementalrelayfee to 100 satoshis per kvB. Wallet feerates stay put, and cheaper transactions may not propagate unless the new defaults spread across the network. Whitelist permissions also stop applying to onion inbound connections (#33395).
FillBlock picks up two P2P fixes in Bitcoin Core 29.2: a witness mutation check (#32646) and an empty-header check before the call (#33296). TRUC checks are no longer enforced on reorg (#33504), and getblock and getblockheader stop returning the tip's target (#33446).
OP_RETURN limits effectively disappear in Bitcoin Core 30.0: -datacarriersize defaults to 100,000 and one transaction may carry multiple data outputs, though -datacarriersize=83 restores the old cap. Default relay feerates fall to 0.1 satoshis per vB, legacy signature operations are capped at 2500 per standard transaction, and a new bitcoin command wraps the existing executables.
Unconditional disk logging in Bitcoin Core 29.1 is rate limited to 1MiB per hour for each source location (#32604), and standard transactions may hold at most 2500 potentially executed legacy signature operations. Default relay feerates drop to 100 satoshis per kvB, while 32-bit builds cap -maxmempool at 500MB and -dbcache at 1GiB.
Just over half of the changes in Bitcoin Core 28.2 are build work. Guix now notarizes the macOS app bundle and codesigns all macOS and Windows binaries (#31407), and depends gets compile fixes for libevent on NetBSD (#31500) and freetype under cmake (#32693).
Thirty-one Bitcoin Core contributors signed a letter saying node software should not refuse to relay transactions with sustained economic demand that reliably reach blocks, since users and miners can route around such filters. They stress this does not endorse non-financial data use and that users alone choose which software and policies to run.
Years of nonstop addr spam could overflow the 32-bit identifier in Bitcoin Core's address manager and crash the node, the remainder of an attack first blunted by rate limiting in v22.0. Version 29.0 moves to a 64-bit identifier, closing CVE-2024-52919, rated Low. Eugene Siegel found it; Martin Zumsande made the change.
UPnP support is gone from Bitcoin Core 29.0; -natpmp now runs on a built-in PCP and NAT-PMP implementation instead of libnatpmp. Ephemeral dust arrives as a new policy, a fix for double-reserved block weight adds -blockreservedweight, and nodes ask every peer that announced an orphan for its missing parents. Versions 26.x and older reach Maintenance End.
With -port set, Bitcoin Core 28.1 derives the default onion listening port as that port plus one rather than fixing it at 8334 on mainnet, so several local nodes can again run side by side without a startup collision. Manual HiddenServicePort lines in torrc may need changing. Secret data is also cleared in DecodeExtKey (#31166).
A peer that announces a block and then stalls could leave a Bitcoin Core node waiting up to 10 minutes before trying elsewhere, and attackers could repeat the trick. CVE-2024-52922, rated Medium and reported and fixed by Greg Sanders, is mitigated in v25.1 and v26.0, which can request a block at once from as many as 3 high-bandwidth compact block peers.
Version 27.2 of Bitcoin Core closes a race condition in self-connect detection (#30394) and corrects FillPSBT calls that wrongly returned complete=true (#30357). The load block thread and scheduler now shut down in a different order (#30435), and the code builds with miniupnpc 2.2.8 and GCC 15.
Mutated blocks from one peer could wipe the download state of other peers announcing the same block in Bitcoin Core before v25.0, making a node forget a compact block it was still reconstructing. Suhas Daftuar noticed the problem, and #27608 limits each peer to its own state. CVE-2024-52921 is rated Medium.
Nodes running Bitcoin Core before v25.0 could be crashed remotely with a repeat blocktxn message for one block, which tripped an assertion that FillBlock runs only once. No short-id collision was needed: including transactions absent from the block's merkle root reached the same path. Niklas Gögge found and fixed the High-severity bug, CVE-2024-35202.
A burst of network activity in early May 2023, made worse by spy nodes, slowed block and transaction propagation as sorting oversized inv-to-send sets ate nearly all of the P2P thread's time. Rated Medium, the problem was fixed in Bitcoin Core v25.0 by #27610, which drops transactions gone from the mempool sooner and drains the sets faster as they grow.
Testnet4 (BIP94) arrives in Bitcoin Core 28.0, along with limited package relay for 1-parent-1-child pairs, standard TRUC transactions under BIP 431 and a new Pay To Anchor output type. -mempoolfullrbf now defaults to 1, and libbitcoinconsensus is gone after its deprecation in 27.0.
Chains of low-difficulty headers could remotely crash Bitcoin Core nodes before v24.0.1, and one crafted chain could be reused against any node on the network. The fix in #25717 makes a node check that a chain carries enough work before storing it, which also ended reliance on checkpoints against known attacks. Severity: High.
Spamming addr messages could crash a Bitcoin Core node: 2^32 addrman insertions overflowed a 32-bit ID counter and tripped an assertion. Eugene Siegel reported the High-severity bug in 2021, and v22.0 carries Pieter Wuille's fix.
Posing as a UPnP device on the local network, an attacker could feed a Bitcoin Core node bloated M-SEARCH replies until it ran out of memory. Only nodes started with -miniupnp were exposed, since the library is otherwise off by default. The Low-severity bug was fixed in v22.0.