Bitcoin Core

CVE-2024-52911 - Script Interpreter Remote Crash

2026-05-05T00:00:00+00:00

After Bitcoin Core 0.14.0 and before Bitcoin Core 29.0, validating a specially-crafted block may cause the node to access previously freed memory.

During validation, necessary data required for checking inputs for each transaction is pre-calculated and cached. For specially crafted invalid blocks, it was possible for this data to be destroyed while it was still being accessed by a background validation thread. An attacker capable of mining a block with sufficient proof-of-work could have exploited this to crash victim nodes. Because of the nature of use-after-free bugs, it is possible that the crash could have been used for remote code execution, though constraints on the input (block) data make this unlikely.

This issue is considered High severity.

Details

By default, script validation for new blocks is dispatched to background threads via a vector of CScriptCheck functors. Each CScriptCheck holds a pointer to a PrecomputedTransactionData object which stores some data needed by each input in the transaction. Because it stores a pointer and not the data itself, care must be taken to ensure that the PrecomputedTransactionData outlives the CScriptCheck.

The script checks lifetime is enforced by an RAII class, CCheckQueueControl. However, the control is intantiated before the precomputed transaction data. Because local objects in C++ are destructed in reverse order of construction, this means the vector of PrecomputedTransactionData is destroyed before the CCheckQueueControl.

This is not an issue when the block is valid, as CCheckQueueControl::Wait() will be called before the function returns and the PrecomputedTransactionData gets destroyed. However, in case of an early return (when a separate check fails) a background script thread may read the precomputed transaction data after it was destroyed. An attacker could exploit this to crash victim nodes at the expense of a valid PoW at tip.

Attribution

Cory Fields (MIT DCI) discovered this vulnerability and responsibly disclosed it in a detailed report containing a proof of concept for reproduction and a proposed mitigation.

Timeline

2024-11-02 Cory Fields privately reports the bug
2024-11-06 Pieter Wuille pushes a covert fix to already open PR #31112 which works around the issue by removing the early returns
2024-12-03 PR #31112 is merged
2025-04-12 Bitcoin Core version 29.0 is released with a fix
2026-04-19 The last vulnerable Bitcoin Core version (28.x) goes end of life
2026-05-05 Public disclosure.

CVE-2024-52911 - Script Interpreter Remote Crash was originally published by Bitcoin Core at Bitcoin Core on May 05, 2026.

CVE-2025-46597 - Highly unlikely remote crash on 32-bit systems

2025-10-24T00:00:00+00:00

Disclosure of the details of a bug on 32-bit systems which may, in a rare edge case, cause the node to crash when receiving a pathological block. This bug would be extremely hard to exploit. A fix was released on October 10th 2025 in Bitcoin Core v30.0.

This issue is considered Low severity.

Details

Before writing a block to disk, Bitcoin Core checks that its size is within a normal range. This check would overflow on 32-bit systems for blocks over 1GB, and make the node crash when writing it to disk. Such a block cannot be sent using the BLOCK message, but could in theory be sent as a compact block if the victim node has a non-default large mempool which already contains 1GB of transactions. This would require the victim to have set their -maxmempool option to a value greater than 3GB, while 32-bit systems may have at most 4GiB of memory.

This issue was indirectly prevented by capping the maximum value of the -maxmempool setting on 32-bit systems.

Attribution

Pieter Wuille discovered this bug and disclosed it responsibly.

Antoine Poinsot proposed and implemented a covert mitigation.

Timeline

2025-04-24 - Pieter Wuille reports the issue
2025-05-16 - Antoine Poinsot opens PR #32530 with a covert fix
2025-06-26 - PR #32530 is merged into master
2025-09-04 - Version 29.1 is released with the fix
2025-10-10 - Version 30.0 is released with the fix
2025-10-24 - Public Disclosure

CVE-2025-46597 - Highly unlikely remote crash on 32-bit systems was originally published by Bitcoin Core at Bitcoin Core on October 24, 2025.

CVE-2025-46598 - CPU DoS from unconfirmed transaction processing

2025-10-24T00:00:00+00:00

Disclosure of the details of a resource exhaustion issue when processing an unconfirmed transaction. A fix was released on October 10th 2025 in Bitcoin Core v30.0.

This issue is considered Low severity.

Details

An attacker could send specially-crafted unconfirmed transactions that would take a victim node a few seconds each to validate. The non-standard transactions would be rejected but not lead to a disconnection and the process could be repeated. This could be exploited to delay block propagation.

The issue was mitigated in multiple steps by reducing the validation time in different Script contexts.

Attribution

Antoine Poinsot reported this issue to the Bitcoin Core security mailing list.

Pieter Wuille, Anthony Towns and Antoine Poinsot implemented mitigations to reduce the worst case validation time of unconfirmed transactions.

Timeline

2025-04-25 - Antoine Poinsot reports the issue
2025-05-12 - Pieter Wuille opens PR #32473 to mitigate the worst case quadratic signature hashing in legacy Script context
2025-07-24 - Anthony Towns opens PR #33050 to mitigate the worst case hashing in Tapscript context
2025-07-30 - Antoine Poinsot opens PR #33105 to further mitigate the worst case in legacy Script context
2025-08-08 - PR #33105 is merged into master
2025-08-11 - PR #32473 is merged into master
2025-08-12 - PR #33050 is merged into master
2025-10-10 - Version 30.0 is released with the mitigations
2025-10-24 - Public Disclosure

CVE-2025-46598 - CPU DoS from unconfirmed transaction processing was originally published by Bitcoin Core at Bitcoin Core on October 24, 2025.

CVE-2025-54604 - Disk filling from spoofed self connections

2025-10-24T00:00:00+00:00

Disclosure of the details of a log-filling bug which allowed an attacker to fill up the disk space of a victim node by faking self-connections. Exploitability of this bug is limited, and it would take a long time before it would cause the victim to run out of disk space. A fix was released on October 10th 2025 in Bitcoin Core v30.0.

This issue is considered Low severity.

Details

Bitcoin Core would unconditionally log in case of self-connection. This could be exploited by an attacker by waiting for a victim to connect to it and reusing the version message nonce to establish many connections to the victim, causing it to detect those attempts as self-connections. However, exploitability is limited because the initial connection from the victim will timeout after 60 seconds by default.

This issue was fixed by implementing log rate-limiting across the board, also preventing future issues of the same type from happening.

Attribution

Niklas Goegge discovered this bug and disclosed it responsibly.

Eugene Siegel and Niklas Goegge worked on a fix mitigating all types of log-filling attacks.

Credits also to contributor “practicalswift” who previously raised concerns about disk-filling vectors in Bitcoin Core and worked to address them.

Timeline

2022-03-16 - Niklas Goegge reports this issue to the Bitcoin Core security mailing list
2025-05-23 - Eugene Siegel opens PR #32604 to introduce log rate-limiting, based on earlier work from Niklas Goegge
2025-07-09 - PR #32604 is merged into master
2025-09-04 - Version 29.1 is released with the fix
2025-10-10 - Version 30.0 is released with the fix
2025-10-24 - Public Disclosure

CVE-2025-54604 - Disk filling from spoofed self connections was originally published by Bitcoin Core at Bitcoin Core on October 24, 2025.

CVE-2025-54605 - Disk filling from invalid blocks

2025-10-24T00:00:00+00:00

Disclosure of the details of a log-filling bug which allowed an attacker to cause a victim node to fill up its disk space by repeatedly sending invalid blocks. Exploitability of this bug is limited, as it would take a long time before it would cause the victim to run out of disk space. A fix was released on October 10th 2025 in Bitcoin Core v30.0.

This issue is considered Low severity.

Details

A node would unconditionally log when receiving a block that fails basic sanity checks, or when receiving a block that branches off prior to the last checkpoint. By repeatedly sending such an invalid block to a victim node, an attacker could cause the victim to run out of disk space.

This issue was fixed by implementing log rate-limiting across the board, also preventing future issues of the same type from happening.

Attribution

Niklas Goegge discovered this bug and disclosed it responsibly. Eugene Siegel independently re-discovered this bug and disclosed it responsibly.

Eugene Siegel and Niklas Goegge worked on a fix mitigating all types of log-filling attacks.

Credits also to contributor “practicalswift” who previously raised concerns about disk-filling vectors in Bitcoin Core and worked to address them.

Timeline

2022-05-16 - Niklas Goegge reports this issue to the Bitcoin Core security mailing list
2025-03-13 - Eugene Siegel reports this issue to the Bitcoin Core security mailing list
2025-04-24 - Eugene Siegel reports to the security mailing list about his research on the worst case disk filling rate.
2025-05-23 - Eugene Siegel opens PR #32604 to introduce log rate-limiting, based on earlier work from Niklas Goegge
2025-07-09 - PR #32604 is merged into master
2025-09-04 - Version 29.1 is released with the fix
2025-10-10 - Version 30.0 is released with the fix
2025-10-24 - Public Disclosure

CVE-2025-54605 - Disk filling from invalid blocks was originally published by Bitcoin Core at Bitcoin Core on October 24, 2025.

CVE-2024-52919 - Remote crash due to addr message spam (part 2)

2025-04-28T00:00:00+00:00

Disclosure of the details of an integer overflow bug which causes a crash if a node is getting spammed addr messages continuously for a very long time (years). A fix was released on April 14th 2025 in Bitcoin Core v29.0.

This issue is considered Low severity.

Details

The address manager in Bitcoin Core uses a 32-bit identifier for each entry, incremented on every insertion. An earlier security advisory explained how it enabled an attacker to remotely trigger an assertion failure by spamming a node with addr messages until the 32-bit identifier overflow.

This was partially addressed in Bitcoin Core v22.0 by rate-limiting insertions in the address manager to 1 address per peer every 10 seconds. This made the attack a lot more expensive if not impractical: even with 1000 peers continuously attacking it would still take more than a year to get the 32-bit identifier to overflow.

The remaining, more expensive attack vector was addressed in Bitcoin Core version 29.0 by making the identifier a 64-bit identifier.

Attribution

Credit goes to Eugene Siegel for discovering and disclosing the vulnerability, and to Martin Zumsande for changing the identifier to 64-bit.

Timeline

2021-06-21 - Initial report sent to security@bitcoincore.org by Eugene Siegel
2021-07-19 - Rate limiting is merged in PR #22387
2021-09-13 - v22.0 is released with rate-limiting
2024-07-31 - Publication of the first security advisory
2024-09-20 - Change to 64-bit identifier is merged in PR #30568
2025-04-14 - Bitcoin Core v29.0 is released with the 64-bit identifier
2025-04-28 - Public Disclosure

CVE-2024-52919 - Remote crash due to addr message spam (part 2) was originally published by Bitcoin Core at Bitcoin Core on April 28, 2025.

CVE-2024-52922 - Hindered block propagation due to stalling peers

2024-11-05T00:00:00+00:00

Before Bitcoin Core v25.1, an attacker can cause a node to not download the latest block.

This issue is considered Medium severity.

Details

When receiving a new block announcement via a headers or compact blocks message, the delivering peer is requested either the full block or missing transaction details by the receiving node. If the announcing peer then doesn’t respond as the peer to peer protocol requires, the affected Bitcoin Core node will wait up to 10 minutes before disconnecting the peer and making another block download attempt. If the attacker is able to make multiple incoming or outgoing connections, this process can be repeated.

Delaying block delivery can cause network degradation by slowing down network convergence, making mining payouts less fair, and causing liveliness issues.

This issue was further exacerbated by other issues disclosed recently (for instance the inventory build-up), when mempools were relatively heterogeneous, disallowing opportunistic reconstruction of compact blocks by honest peers.

A mitigation was introduced in #27626, introduced in Bitcoin Core v26.0 and backported to v25.1. It ensures that blocks can be requested concurrently from up to 3 high-bandwidth compact block peers, one of which is required to be an outbound connection.

Attribution

Reported and fixed by Greg Sanders.

Timeline

2023-05-08 - Users reporting block timeouts in the #bitcoin-core-dev IRC channel
2023-05-09 - First github issues describing the issue https://github.com/bitcoin/bitcoin/issues/25258#issuecomment-1540028533
2023-05-11 - Mitigation PR opened https://github.com/bitcoin/bitcoin/pull/27626
2023-05-24 - PR merged prior to Bitcoin Core v26.0
2023-05-25 - Backport to Bitcoin Core v25.1 merged https://github.com/bitcoin/bitcoin/pull/27752
2023-10-19 - Bitcoin Core v25.1 Released
2024-11-05 - Public disclosure

CVE-2024-52922 - Hindered block propagation due to stalling peers was originally published by Bitcoin Core at Bitcoin Core on November 05, 2024.

Disclosure of CVE-2024-35202

2024-10-08T00:00:00+00:00

Before Bitcoin Core v25.0, an attacker could remotely crash Bitcoin Core nodes by triggering an assertion in the blocktxn message handling logic.

This issue is considered High severity.

Details

When receiving a block announcement via a cmpctblock message, Bitcoin Core attempts to reconstruct the announced block using the transactions in its own mempool as well as other available transactions. If reconstruction fails due to missing transactions it will request them from the announcing peer via a getblocktxn message. In response a blocktxn message is expected, which should contain the requested transactions.

The compact block protocol employs shortened transaction identifiers to reduce bandwidth. These short-ids are 6 byte in size, resulting in a small chance for collisions (i.e. transaction A has the same short-id as transaction B) upon block reconstruction. Collisions will be detected as the merkle root computed from the reconstructed set of transactions will not match the merkle root from the block announcement. Peers should not be punished for collisions as they may happen spuriously, therefore they are handled by falling back to requesting the full block.

Bitcoin Core will create an instance of PartiallyDownloadedBlock whenever a new compact block is received. If missing transactions are requested, the instance is persisted until the corresponding blocktxn message is processed. Upon receiving the blocktxn message, PartiallyDownloadedBlock::FillBlock is called, attempting to reconstruct the full block. In the collision case described above, the full block is requested but the PartiallyDownloadedBlock instance as well as the other state related to the underlying block request is left untouched. This leaves room for a second blocktxn message for the same block to be processed and trigger FillBlock to be called again. This violates the assumption (documented as an assert statement) that FillBlock can only be called once and causes the node to crash.

An attacker does not need to get lucky by triggering a collision, as the collision handling logic can easily be triggered by simply including transactions in the blocktxn message that are not committed to in the block’s merkle root.

Attribution

Credit goes to Niklas Gögge for discovering and disclosing the vulnerability, as well as fixing the issue in https://github.com/bitcoin/bitcoin/pull/26898.

Timeline

2022-10-05 - Niklas Gögge reports the issue to the Bitcoin Core security mailing list.
2023-01-24 - PR #26898 containing the fix is merged.
2023-05-25 - Bitcoin Core 25.0 is released with the fix.
2024-10-09 - Public disclosure.

Disclosure of CVE-2024-35202 was originally published by Bitcoin Core at Bitcoin Core on October 08, 2024.

Disclosure of DoS due to inv-to-send sets growing too large

2024-10-08T00:00:00+00:00

Before Bitcoin Core v25.0, the per-peer m_tx_inventory_to_send sets could grow too large to a point where sorting these sets when constructing inventory messages would affect the node’s ability to communicate with its peers. Network conditions in early May 2023 triggered this DoS and affected block and transaction propagation.

This issue is considered Medium severity.

Details

As part of transaction relay, Bitcoin Core maintains a per-peer m_tx_inventory_to_send set with transactions that should be announced to the peer. When constructing an inventory message for a peer, the set is sorted by transaction dependencies and feerate to prioritize high-feerate transactions and to avoid leaking the order the node learned about the transactions. Before Bitcoin Core v25.0, when constructing inventory messages, relevant (still in mempool, not yet announced to us by the peer, above the fee filter) transactions were being drained at a rate of 7 transactions per second.

In early May 2023, increased network activity caused the sets to grow faster than they were being drained resulting in significant time spent sorting the sets in the P2P communication thread. Additionally, peers that only listen for transaction announcements but never announce any themselves (commonly referred to as “spy nodes”), amplified this by having huge sets (with transactions they already know about) that take a long time to sort. It was observed that sorting took up nearly the complete time spent in the P2P communication thread, which significantly affected block and transaction propagation as well as keeping connection with peers alive.

This was fixed in #27610 by 1) earlier removing transactions that aren’t in the mempool anymore and 2) by dynamically increasing the set drainage rate depending on the set size.

Attribution

Credit goes to Anthony Towns for working on a fix and to b10c for initially reporting and narrowing the problem down to the slow inv-to-send sorting.

Timeline

2023-05-02 - Problem first observed and reported
2023-05-11 - Fix is merged (#27610)
2023-05-25 - v25.0 is released
2024-10-09 - Public disclosure

Disclosure of DoS due to inv-to-send sets growing too large was originally published by Bitcoin Core at Bitcoin Core on October 08, 2024.

CVE-2024-52921 - Hindered block propagation due to mutated blocks

2024-10-08T00:00:00+00:00

Before Bitcoin Core v25.0, a peer sending mutated blocks could clear the download state of other peers that also announced the block to us, which would hinder block propagation.

This issue is considered Medium severity.

Details

Bitcoin Core treats a block as mutated when, for example, the Merkle root in the header or the witness commitment in the coinbase transaction doesn’t match the transactions in the block.

Before Bitcoin Core v25.0, a peer could clear the block download state of other peers by sending an unrequested mutated block. This was a problem for, for example, compact block relay. After receiving a compact block and while waiting for a response to a getblocktxn request to reconstruct the full block, receiving the mutated block would let Bitcoin Core forget about the compact block reconstruction state. A blocktxn response arriving after the mutated block couldn’t be used to reconstruct the block. This hindered block propagation.

This was fixed in #27608 by making sure that a peer can only affect its own block download state and not the download state of other peers.

Attribution

Credit goes to Suhas Daftuar for noticing the problem and working on a fix.

Timeline

2023-05-08 - A problem with mutated blocks is first reported in the #bitcoin-core-dev IRC channel.
2023-05-10 - Fix is merged (#27608)
2023-05-25 - v25.0 is released
2024-10-09 - Public disclosure

CVE-2024-52921 - Hindered block propagation due to mutated blocks was originally published by Bitcoin Core at Bitcoin Core on October 08, 2024.

CVE-2019-25220 - Memory DoS due to headers spam

2024-09-18T00:00:00+00:00

Before Bitcoin Core v24.0.1, attackers could spam nodes with low-difficulty headers chains, which could be used to remotely crash peers.

This issue is considered High severity.

Details

Bitcoin Core stores the blockchain headers in memory. This makes it susceptible to being DoSed, by having it download and store extremely long chains of headers, even if they are of low difficulty. It is important to note that once crafted, an attack chain could be reused to crash any node on the network.

The possibility of using this to attack nodes has long been known, and was the primary reason why the checkpoint system was still in place: making an attacker start an attack at the last checkpoint makes it far more costly than starting at the genesis block. However, over time, with decreasing hashrate costs, even this mitigation became less effective.

This attack was independently discovered and reported to the Bitcoin Core project in January 2019 by David Jaenson, who suggested introducing newer checkpoints as a practical mitigation. However:

This still leaves nodes performing IBD with no protection before they receive checkpoint blocks.
It relies on the ecosystem semi-regularly adopting updated software with new checkpoints, a practice which Bitcoin Core contributors have long been uncomfortable with.

It later got increased attention when Braydon Fuller posted his “Chain width expansion” writeup to the bitcoin-dev mailing list in October 2019. He had previously responsibly reported it to the Bitcoin Core security list. The suggested approach was not adopted in Bitcoin Core due to concerns about network convergence when limiting the number of parallel chains.

At the time, the computational cost of creating a huge low-difficulty headers chain was equal to about 32.28% of mining one block at the tip. That is a cost of about 4.12 BTC since the block reward then was about 12.77 BTC.

By February 2022, the cost of the attack had dropped further to around 14.73% of the cost of mining a block, and this prompted investigation of alternative solutions. If unaddressed, the cost today (September 2024) would just be 4.44% of a block. These figures translate to a cost of about 1.07 BTC and 0.14 BTC respectively, given the block reward at these dates.

A protection against this DoS was implemented in Bitcoin Core PR #25717, whereby the node will first verify a presented chain has enough work before committing to store it. With that, Bitcoin Core no longer relies on having checkpoints to protect against any known attacks.

Attribution

Credit goes to David Jaenson and Braydon Fuller for independently re-discovering the attack, estimating its cost and suggesting modifications.

Credit goes to Suhas Daftuar and Pieter Wuille for researching a satisfying fix and implementing it.

Timeline

2010-07-17 - Bitcoin 0.3.2 is released, which introduces checkpoints. They protect among other things against low-difficulty block spam.
2011-11-21 - Bitcoin 0.5.0 is released, which skips script validation for blocks before the last checkpoint. This makes the role of checkpoints even more security-critical.
2014-04-09 - Block 295000 is mined, which becomes the last Bitcoin Core checkpoint. The protection offered by checkpoints against block spam starts eroding from this point on as hashrate costs decrease.
2015-02-16 - Bitcoin Core 0.10.0 is released, with headers-first synchronization. This weakens the low-difficulty block spam attack to a block header spam attack.
2017-03-08 - Bitcoin Core 0.14.0 is released, which disentangles the skipping of script validation from checkpoints, leaving them only relevant for protecting against block header spam.
2019-01-28 - David Jaenson reports this issue to the Bitcoin Core security mailing list.
2019-09-18 - Braydon Fuller emails the Bitcoin Core security list with a paper titled “Bitcoin Chain Width Expansion Denial-of-Service Attacks”, which discusses the dangers of block and block header spam, a cost analysis, and a proposed solution.
2019-09-26 - Suhas Daftuar replies to Braydon Fuller that it’s a known issue, and invites him to post his writeup to the bitcoin-dev mailing list.
2019-10-04 - Braydon Fuller sends his paper to the bitcoin-dev mailing list.
2019-10-31 - In response to the above events, Suhas Daftuar opens PR #17332 with an earlier but impractical proof of concept he worked on to improve the situation, with the hope of causing more discussion on the topic.
2022-02 - Suhas Daftuar and Pieter Wuille discuss this issue and estimate that the cost of this attack has now actually become so low that it warrants immediate action, and the need to avoid talking about it publicly.
2022-06-22 - Suhas Daftuar opens PR #25454 as preparatory work toward implementing a fix.
2022-06-22 - Suhas Daftuar messages a group of long-term contributors detailing the attack, its cost and the fix Pieter Wuille and him have been working on.
2022-07-26 - Suhas Daftuar opens PR #25717, co-authored with Pieter Wuille, which implements the fix.
2022-08-30 - PR #25717 is merged.
2022-10-21 - Niklas Gögge’s PR #26355 is merged, which fixes a bug in the headers pre-synchronization step that was introduced in PR #25717. Without this, it would still have been possible to spam block headers. The discovery of this bug, and the possibility of potential undiscovered ones, is the reason why the old checkpoints have not been removed entirely yet.
2022-12-12 - Bitcoin Core 24.0.1 is released with the fix.
2023-12-07 - The last vulnerable version of Bitcoin Core (23.2) goes end of life.
2024-09-18 - Public disclosure.

CVE-2019-25220 - Memory DoS due to headers spam was originally published by Bitcoin Core at Bitcoin Core on September 18, 2024.

CVE-2024-52919 - Remote crash due to addr message spam

2024-07-31T00:00:00+00:00

Disclosure of the details of an integer overflow bug which causes an assertion crash, a fix for which was released on September 14th, 2021 in Bitcoin Core version v22.0.

This issue is considered High severity.

Details

CAddrMan has a 32-bit nIdCount field that is incremented on every insertion into addrman, and which then becomes the identifier for the new entry. By getting the victim to insert 2³² entries (through e.g. spamming addr messages), this identifier overflows, which leads to an assertion crash.

Attribution

Credit goes to Eugene Siegel for discovering and disclosing the vulnerability, and to Pieter Wuille for fixing the issue in https://github.com/bitcoin/bitcoin/pull/22387.

Timeline

2021-06-21 - Initial report sent to security@bitcoincore.org by Eugene Siegel
2021-07-19 - Fix is merged (https://github.com/bitcoin/bitcoin/pull/22387)
2021-09-13 - v22.0 is released
2024-07-31 - Public disclosure

CVE-2024-52919 - Remote crash due to addr message spam was originally published by Bitcoin Core at Bitcoin Core on July 31, 2024.

CVE-2024-52917 - Infinite loop bug in the miniupnp dependency

2024-07-31T00:00:00+00:00

Disclosure of the impact of an infinite loop bug in the miniupnp dependency on Bitcoin Core, a fix for which was released on September 14th, 2021 in Bitcoin Core version v22.0.

This issue is considered Low severity.

Details

Miniupnp, the UPnP library used by Bitcoin Core, would be waiting upon discovery for as long as it receives random data from a device on the network. In addition it would allocate memory for every new device information. An attacker on the local network could pretend to be a UPnP device and keep sending bloated M-SEARCH replies to the Bitcoin Core node until it runs out of memory.

Only users running with the -miniupnp option would have been affected by this bug as Miniupnp is otherwise turned off by default.

Attribution

Credit goes to Ronald Huveneers for reporting the infinite loop bug to the miniupnp project, and to Michael Ford (Fanquake) for the report to the Bitcoin Core project along with a PoC exploit to trigger an OOM and a pull request to bump the dependency (containing the fix).

Timeline

2020-09-17 - Initial report of infinite loop bug to miniupnp by Ronald Huveneers
2020-10-13 - Initial report sent to security@bitcoincore.org by Michael Ford
2021-03-23 - Fix is merged (https://github.com/bitcoin/bitcoin/pull/20421)
2021-09-13 - v22.0 is released
2024-07-31 - Public disclosure

CVE-2024-52917 - Infinite loop bug in the miniupnp dependency was originally published by Bitcoin Core at Bitcoin Core on July 31, 2024.

CVE-2024-52913 - Censorship due to transaction re-request handling

2024-07-03T00:00:00+00:00

An attacker could prevent a node from seeing a specific unconfirmed transaction.

This issue is considered Medium severity.

Details

Before this issue was fixed in PR 19988, the “g_already_asked_for” mechanism was used to schedule GETDATA requests for transactions. The SendMessages() function would send out GETDATAs for transactions recently announced by peers, remembering when that request was sent out in g_already_asked_for. However, this g_already_asked_for was a “limitedmap” data structure, with a bounded size that would forget the oldest entries if it reaches 50000 entries. This makes the following attack possible:

The attacker is the first to announce a legitimate transaction T to the victim.
The victim requests T from the attacker using GETDATA.
The attacker does not respond to GETDATA until close to the time when the victim would request T from other peers (~60 seconds).
Then, the attacker carefully spams the victim with bogus announcements, causing the victim’s g_already_asked_for to evict T.
The attacker announces T again to the victim (due to how the queueing works in m_tx_process_time, this does not need to be timed particularly accurately).
The victim, not finding T in g_already_asked_for will treat it as a new announcement, sending a new GETDATA for it to the attacker.
The attacker again does not respond to GETDATA.
etc.

This way, the attacker can prevent the victim from ever requesting the transaction from anyone but the attacker.

Attribution

Responsibly disclosed by John Newbery, claiming discovery by Amiti Uttarwar and him.

Timeline

2020-04-03 John Newbery reports the bug in an email to Suhas Daftuar and others
2020-05-08 John Newbery suggests an approach to fixing the bug
2020-09-21 Pieter Wuille opens PR #19988 as a comprehensive approach to fixing this and other bugs
2020-10-14 Pieter’s PR is merged
2021-01-14 Bitcoin Core version 0.21.0 is released with a fix
2022-04-25 The last vulnerable Bitcoin Core version (0.20.x) goes EOL
2024-07-03 Public disclosure

CVE-2024-52913 - Censorship due to transaction re-request handling was originally published by Bitcoin Core at Bitcoin Core on July 03, 2024.

CVE-2024-52918 - Crash using malicious BIP72 URI

2024-07-03T00:00:00+00:00

Bitcoin-Qt could crash upon opening a BIP72 URI.

This issue is considered Medium severity.

Details

BIP72 extends the BIP21 URI scheme with an r parameter to fetch a payment request from. An attacker could simply point the URL contained in the r parameter to a very large file, for which Bitcoin-Qt would try to allocate enough memory and crash.

The victim could get tricked into opening a rogue payment request. The large download would happen in the background with little to no output in the GUI until the application runs out of memory.

Attribution

Credits go to Michael Ford (Fanquake) for responsibly disclosing the issue and providing a PoC.

Timeline

2019-08-12 Michael Ford reports the bug to Cory Fields and Wladimir Van Der Laan
2019-10-16 Michael Ford opens PR #17165 to get rid of BIP70 support entirely
2019-10-26 Michael’s PR is merged into Bitcoin Core
2020-06-03 Bitcoin Core version 0.20.0 is released
2021-09-13 The last vulnerable Bitcoin Core version (0.19.x) goes EOL
2024-07-03 Public disclosure

CVE-2024-52918 - Crash using malicious BIP72 URI was originally published by Bitcoin Core at Bitcoin Core on July 03, 2024.

CVE-2024-52920 - DoS using huge GETDATA messages

2024-07-03T00:00:00+00:00

A malformed GETDATA message could trigger an infinite loop on the receiving node, using 100% of the CPU allocated to this thread and not making further progress on this connection.

This issue is considered Low severity.

Details

Before Bitcoin Core 0.20.0, an attacker (or buggy client, even) could send us a GETDATA message that would cause our net_processing thread to start spinning at 100%, and not make progress processing messages for the attacker peer anymore. It would still make progress processing messages from other peers, so it is just a CPU DoS with low impact beyond that (not making progress for attacker peers is a non-issue). It also increases per-peer long-term memory usage up by 1.5 MB per attacker peer.

John Newbery opened PR #18808 to fix this issue by only disclosing the lack of progress.

Attribution

Credits to John Newbery for finding this bug, responsibly disclosing it and fixing it.

Timeline

2020-04-29 John Newbery opens #18808
2020-05-08 John Newbery reports his finding by email
2020-05-12 #18808 is merged
2020-06-03 Bitcoin Core version 0.20.0 is released with a fix
2021-09-13 The last vulnerable Bitcoin Core version (0.19.x) goes EOL
2024-07-03 Public disclosure.

CVE-2024-52920 - DoS using huge GETDATA messages was originally published by Bitcoin Core at Bitcoin Core on July 03, 2024.

CVE-2024-52916 - Memory DoS using low-difficulty headers

2024-07-03T00:00:00+00:00

After Bitcoin Core 0.12.0 and before Bitcoin Core 0.15.0 a node could be spammed with minimum difficulty headers, which could possibly be leveraged to crash it by OOM.

This issue is considered Medium severity.

Details

Before the introduction of headers pre-synchronisation, nodes relied exclusively on checkpoints to avoid getting spammed by low-difficulty headers.

In Bitcoin Core 0.12.0 a check for headers forking before the last checkpoint’s height was moved to after storing the header in mapBlockIndex. This allowed an attacker to grow the map unboundedly by spamming headers whose parent is the genesis block (which only need difficulty 1 to create), as such blocks bypassed the checkpoint logic.

Attribution

Credits to Cory Fields for finding and responsibly disclosing the bug.

Timeline

2017-08-08 Cory Fields privately reports the bug
2017-08-11 Pieter Wuille opens PR #11028 to fix it
2017-08-14 PR #11028 is merged
2017-09-14 Bitcoin Core version 0.15.0 is released with a fix
2018-10-03 The last vulnerable version of Bitcoin Core (0.14.3) goes end of life
2024-07-03 Public disclosure.

CVE-2024-52916 - Memory DoS using low-difficulty headers was originally published by Bitcoin Core at Bitcoin Core on July 03, 2024.

CVE-2024-52915 - Memory DoS using huge INV messages

2024-07-03T00:00:00+00:00

A node could be forced to allocate a significant amount of memory upon receiving a specially crafted INV message. This was particularly an issue for nodes with little available memory or a large number of connections.

This issue is considered Medium severity.

Details

An INV message filled with 50,000 block items could cause 50,000 getheaders responses to be sent in a single ProcessMessages() call. Each response contains a locator and is around 1 kB. All would be put into the send buffer at once. The attacker could just refuse to receive data to prevent the 50 MB buffer from draining.

John Newbery opened PR #18962 to fix this issue pretexting a bandwidth gain from sending a single GETHEADERS per received INV.

Attribution

Credits to John Newbery for finding this bug, responsibly disclosing it and fixing it.

Timeline

2020-05-08 John Newbery reports his finding by email
2020-05-12 John Newbery opens #18962
2020-05-14 #18962 is merged
2020-06-03 Bitcoin Core version 0.20.0 is released with a fix
2021-09-13 The last vulnerable Bitcoin Core version (0.19.x) goes EOL
2024-07-03 Public disclosure.

CVE-2024-52915 - Memory DoS using huge INV messages was originally published by Bitcoin Core at Bitcoin Core on July 03, 2024.

CVE-2024-52914 - Significant DoS due to orphan handling

2024-07-03T00:00:00+00:00

A node could be stalled for hours when processing the orphans of a specially crafted unconfirmed transaction.

This issue is considered High severity.

Details

After accepting a transaction into its mempool, the node would go through its cache of orphan transactions to find if this new accepted transaction makes it possible to accept any. This search was quadratic: for each output in the newly accepted transaction it would go through all cached orphan transactions (limited to 100). By specially crafting the orphan transactions to be invalid yet expensive to validate a node could be stalled for several hours.

The stall was fixed by Pieter Wuille in PR #15644 by interrupting the orphan resolution to process new messages when a match is found (whether the orphan turns out to be valid or not).

Attribution

Credits to sec.eine for responsibly disclosing the bug and providing feedback on the fix.

Timeline

2019-03-19 sec.eine reports the issue to Greg Maxwell by email
2019-03-21 Greg Maxwell responds with information about the proposed patch
2019-03-22 sec.eine gives feedback on the patch (“seems solid and [..] doesn’t attract attention”)
2019-03-22 Pieter Wuille opens PR #15644
2019-04-01 PR #15644 is merged
2019-05-18 Bitcoin Core version 0.18.0 is released with a fix
2020-07-22 The issue is partially disclosed during a PR review club
2020-08-01 The last vulnerable Bitcoin Core version (0.17.x) goes EOL
2024-07-03 Public disclosure.

CVE-2024-52914 - Significant DoS due to orphan handling was originally published by Bitcoin Core at Bitcoin Core on July 03, 2024.

Disclosure of CVE-2015-3641

2024-07-03T00:00:00+00:00

A node could be forced to allocate large buffers when receiving a message, which could be leveraged to remotely crash it by OOM.

This issue is considered Medium severity.

Details

Without a tighter bound, received messages’ size was limited by the maximum serialized message size of 32 MiB. An attacker could force a node to allocate this much RAM per connection, which may lead to an OOM.

PR #5843 reduced the size P2P messages can have before receiving the payload. This reduces the per-peer receive buffer memory size a malicious peer can cause. The PR reduced the number from 32 MiB to 2 MiB, which was later increased back to 4 MB as part of the Segwit BIP144 changes.

Attribution

Reported to Greg Maxwell by bitcointalk user Evil-Knievel. Fixed by Pieter Wuille.

Timeline

2015-02-05 Evil-Knievel reports the vulnerability to Greg Maxwell through bitcointalk private messages.
2015-??-?? CVE-2015-3641 is registered for it.
2015-03-01 PR #5843 is opened to fix it.
2015-03-06 PR #5843 is merged.
2015-03-09 The fix is backported to version 0.10.1.
2015-04-27 Bitcoin Core version 0.10.1 is released with a fix.
2015-06-25 A disclosure is pre-announced.
2015-07-07 Disclosure is postponed.
2016-08-23 The last vulnerable Bitcoin Core Version (0.10.x) goes EOL
2024-07-03 Public disclosure.

Disclosure of CVE-2015-3641 was originally published by Bitcoin Core at Bitcoin Core on July 03, 2024.