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.

Bitcoin Core 31.0 released

2026-04-19T00:00:00+00:00

Bitcoin Core version 31.0 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 31.0 released was originally published by Bitcoin Core at Bitcoin Core on April 19, 2026.

Bitcoin Core 28.4 released

2026-03-18T00:00:00+00:00

Bitcoin Core version 28.4 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 28.4 released was originally published by Bitcoin Core at Bitcoin Core on March 18, 2026.

Bitcoin Core 29.3 released

2026-02-10T00:00:00+00:00

Bitcoin Core version 29.3 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 29.3 released was originally published by Bitcoin Core at Bitcoin Core on February 10, 2026.

Bitcoin Core 30.2 released

2026-01-10T00:00:00+00:00

Bitcoin Core version 30.2 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 30.2 released was originally published by Bitcoin Core at Bitcoin Core on January 10, 2026.

Wallet Migration Failure May Delete Unrelated Wallet Files In Bitcoin Core 30.0 and 30.1

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

We have become aware of a wallet migration bug introduced in Bitcoin Core 30.0 and 30.1. Under rare circumstances, when the migration of a wallet.dat file fails, all files in the wallet directory may be deleted in the process, potentially resulting in a loss of funds. A fix is forthcoming and will be released as 30.2, but out of an abundance of caution we have removed the binaries for affected releases from bitcoincore.org.

At this time, we ask users to not attempt wallet migrations using the GUI or RPC until v30.2 is released. All other users, including existing wallet users, are unaffected and can keep using existing installations.

Specifically, it requires the presence of a default (unnamed) wallet.dat file, which has not been created by default since 0.21 (released 5 years ago), that fails to be migrated or loaded. One condition that may trigger this is when pruning is enabled, and the wallet was unloaded while pruning happened.

Wallet Migration Failure May Delete Unrelated Wallet Files In Bitcoin Core 30.0 and 30.1 was originally published by Bitcoin Core at Bitcoin Core on January 05, 2026.

Bitcoin Core 30.1 released

2026-01-02T00:00:00+00:00

Bitcoin Core version 30.1 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 30.1 released was originally published by Bitcoin Core at Bitcoin Core on January 02, 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.

Bitcoin Core 28.3 released

2025-10-17T00:00:00+00:00

Bitcoin Core version 28.3 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 28.3 released was originally published by Bitcoin Core at Bitcoin Core on October 17, 2025.

Bitcoin Core 29.2 released

2025-10-14T00:00:00+00:00

Bitcoin Core version 29.2 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 29.2 released was originally published by Bitcoin Core at Bitcoin Core on October 14, 2025.

Bitcoin Core 30.0 released

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

Bitcoin Core version 30.0 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 30.0 released was originally published by Bitcoin Core at Bitcoin Core on October 10, 2025.

Bitcoin Core 29.1 released

2025-09-04T00:00:00+00:00

Bitcoin Core version 29.1 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 29.1 released was originally published by Bitcoin Core at Bitcoin Core on September 04, 2025.

Bitcoin Core 28.2 released

2025-06-26T00:00:00+00:00

Bitcoin Core version 28.2 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 28.2 released was originally published by Bitcoin Core at Bitcoin Core on June 26, 2025.

Bitcoin Core development and transaction relay policy

2025-06-06T00:00:00+00:00

We’d like to share our view on the relationship between Bitcoin Core development and transaction relay policy on the network.

Bitcoin is a network that is defined by its users, who have ultimate freedom in choosing what software they use (fully-validating or not) and implementing whatever policies they desire. Bitcoin Core contributors are not in a position to mandate what those are. One way this is reflected is by our long-running practice of avoiding auto-updating in the software. This means that no entity can unilaterally push out changes to Bitcoin Core users: changes must be made by users choosing to adopt new software releases themselves, or if they so desire, different software. Being free to run any software is the network’s primary safeguard against coercion.

As Bitcoin Core developers we also consider it our responsibility to make our software work as efficiently and reliably as possible for its purpose, namely validating and relaying blocks and transactions in the Bitcoin peer-to-peer network, so that Bitcoin succeeds as a decentralized digital currency. With regards to transaction relay, this may include adding policies for denial of service (DoS) protection and fee assessment, but not blocking relay of transactions that have sustained economic demand and reliably make it into blocks. The goals of transaction relay include:

predicting what transactions will be mined (for example for fee estimation or fee bumping, but it is also the basis for many DoS protection strategies inside of node software);
speeding up block propagation for the transactions we expect to be mined. Reduced latency helps prevent large miners from gaining unfair advantages;
helping miners learn about fee-paying transactions (so they do not need to rely on out-of-band transaction submission schemes that undermine mining decentralization).

Knowingly refusing to relay transactions that miners would include in blocks anyway forces users into alternate communication channels, undermining the above goals.

It is the case that transaction acceptance rules have been used effectively in the past to discourage the development of use cases that used block space inefficiently while doing so was very cheap. However this can only be effective while both users and miners are satisfied with whatever alternatives exist. When that is no longer the case, and an economically viable use case develops that would conflict with policy rules, users and miners can directly collaborate to avoid any external attempt to impose restrictions on their activities. In fact, the ability to do precisely that is an important aspect of Bitcoin’s censorship resistance, and other node software with preferential peering has also shown that circumventing filters of the vast majority of the nodes is relatively easy. Given that, we believe it is better for Bitcoin node software to aim to have a realistic idea of what will end up in the next block, rather than attempting to intervene between consenting transaction creators and miners in order to discourage activity that is largely harmless at a technical level.

This is not endorsing or condoning non-financial data usage, but accepting that as a censorship-resistant system, Bitcoin can and will be used for use cases not everyone agrees on.

While we recognize that this view isn’t held universally by all users and developers, it is our sincere belief that it is in the best interest of Bitcoin and its users, and we hope our users agree. We will continue to apply our best judgment as developers in aligning transaction acceptance rules with Bitcoin’s long-term health and miners’ rational self-interest, including specific technical reasons such as upgrade safety, efficient block building, and node DoS attacks.

Signed,

(List of contributors who support this letter)

Andrew Toth
Antoine Poinsot
Anthony Towns
Ava Chow
b10c
Bruno Garcia
David Gumberg
fjahr
Gloria Zhao
Gregory Sanders
hodlinator
ismaelsadeeq
Josie Baker
kevkevinpal
l0rinc
Marco De Leon
Martin Zumsande
Matthew Zipkin
Michael Ford
Murch
Niklas Gögge
pablomartin4btc
Pieter Wuille
Pol Espinasa
Sebastian Falbesoner
Sergi Delgado
Stephan Vuylsteke
TheCharlatan
Vasil Dimov
Will Clark
w0xlt

Bitcoin Core development and transaction relay policy was originally published by Bitcoin Core at Bitcoin Core on June 06, 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.

Bitcoin Core 29.0 released

2025-04-14T00:00:00+00:00

Bitcoin Core version 29.0 is now available for download. See the release notes for more information about the bug fixes in this release.

With the release of this new major version, versions 26.x and older are at “Maintenance End” and will no longer receive updates. In accordance with the security policy, two weeks after this release, medium and high severity vulnerabilities affecting versions 26.x (if any) will be disclosed. Additionally, low severity vulnerabilities affecting versions 28.x (if any) will be disclosed.

Bitcoin Core 29.0 released was originally published by Bitcoin Core at Bitcoin Core on April 14, 2025.

Bitcoin Core 28.1 released

2025-01-09T00:00:00+00:00

Bitcoin Core version 28.1 is now available for download. See the release notes for more information about the bug fixes in this release.

If you have any questions, please stop by the #bitcoin IRC chatroom (IRC, web) and we’ll do our best to help you.

Bitcoin Core 28.1 released was originally published by Bitcoin Core at Bitcoin Core on January 09, 2025.