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.

Bitcoin Core 28.3 版本發布

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

Bitcoin Core 28.3 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 28.3 版本發布 was originally published by Bitcoin Core at Bitcoin Core on October 17, 2025.

Bitcoin Core 29.2 版本發布

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

Bitcoin Core 29.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 29.2 版本發布 was originally published by Bitcoin Core at Bitcoin Core on October 14, 2025.

Bitcoin Core 30.0 版本發布

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

Bitcoin Core 30.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 30.0 版本發布 was originally published by Bitcoin Core at Bitcoin Core on October 10, 2025.

Bitcoin Core 29.1 版本發布

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

Bitcoin Core 29.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 29.1 版本發布 was originally published by Bitcoin Core at Bitcoin Core on September 04, 2025.

Bitcoin Core 28.2 版本發布

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

Bitcoin Core 28.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 28.2 版本發布 was originally published by Bitcoin Core at Bitcoin Core on June 26, 2025.

Bitcoin Core 開發和交易中繼策略

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

我們想分享我們對 Bitcoin Core 開發與網路上交易中繼策略之間關係的看法。

Bitcoin 是一個由其使用者定義的網路，他們在選擇使用什麼軟體（完全驗證或非完全驗證）和實作他們想要的任何策略方面擁有最終自由。Bitcoin Core 貢獻者無權規定這些策略是什麼。這反映在我們長期以來避免在軟體中自動更新的做法中。這意味著沒有任何實體可以單方面向 Bitcoin Core 使用者推送變更：變更必須由使用者自己選擇採用新的軟體版本，或者如果他們願意，採用不同的軟體。自由執行任何軟體是網路對抗強制的主要保障。

作為 Bitcoin Core 開發者，我們也認為我們有責任使我們的軟體盡可能有效和可靠地為其目的服務，即在 Bitcoin 點對點網路中驗證和中繼區塊和交易，以便 Bitcoin 作為去中心化數位貨幣取得成功。關於交易中繼，這可能包括新增阻斷服務（DoS）保護和手續費評估的策略，但不會阻止中繼有持續經濟需求且可靠地進入區塊的交易。交易中繼的目標包括：

預測將被挖掘的交易（例如用於手續費估算或手續費提升，但它也是節點軟體內許多 DoS 保護策略的基礎）；
加快我們預期被挖掘的交易的區塊傳播。減少延遲有助於防止大型礦工獲得不公平的優勢；
幫助礦工了解付費交易（這樣他們就不需要依賴破壞挖礦去中心化的頻外交易提交方案）。

明知拒絕中繼礦工無論如何都會包含在區塊中的交易會迫使使用者進入替代通訊管道，破壞上述目標。

交易接受規則過去曾被有效地用於阻止使用區塊空間效率低下的用例的開發，而這樣做非常便宜。然而，這只有在使用者和礦工都對存在的任何替代方案感到滿意時才能有效。當情況不再如此，並且開發出與策略規則衝突的經濟上可行的用例時，使用者和礦工可以直接合作以避免對其活動施加限制的任何外部嘗試。事實上，能夠做到這一點是 Bitcoin 抗審查性的一個重要方面，具有優先對等的其他節點軟體也表明，規避絕大多數節點的過濾器相對容易。鑑於此，我們認為 Bitcoin 節點軟體最好旨在對下一個區塊中最終會包含什麼有一個現實的想法，而不是試圖在同意的交易建立者和礦工之間進行干預，以阻止在技術層面上基本無害的活動。

這不是認可或容忍非金融資料使用，而是接受作為抗審查系統，Bitcoin 可以而且將被用於不是每個人都同意的用例。

雖然我們認識到這一觀點並非所有使用者和開發者普遍持有，但我們真誠地相信這符合 Bitcoin 及其使用者的最佳利益，我們希望我們的使用者同意。我們將繼續作為開發者應用我們的最佳判斷，使交易接受規則與 Bitcoin 的長期健康和礦工的理性自利保持一致，包括特定的技術原因，例如升級安全性、高效的區塊建構和節點 DoS 攻擊。

簽署，

（支援此信的貢獻者列表）

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 開發和交易中繼策略 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 版本發布

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

Bitcoin Core 29.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 29.0 版本發布 was originally published by Bitcoin Core at Bitcoin Core on April 14, 2025.

Bitcoin Core 28.1 版本發布

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

Bitcoin Core 28.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 28.1 版本發布 was originally published by Bitcoin Core at Bitcoin Core on January 09, 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.

Bitcoin Core 27.2 版本發布

2024-11-04T00:00:00+00:00

Bitcoin Core 27.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 27.2 版本發布 was originally published by Bitcoin Core at Bitcoin Core on November 04, 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.

Bitcoin Core 28.0 版本發布

2024-10-02T00:00:00+00:00

Bitcoin Core 28.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 28.0 版本發布 was originally published by Bitcoin Core at Bitcoin Core on October 02, 2024.