| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Bitcoin Core through 29.0 allows Uncontrolled Resource Consumption (issue 2 of 2). |
| Bitcoin Core through 29.0 allows Uncontrolled Resource Consumption (issue 1 of 2). |
| Bitcoin Core before 24.0.1 allows remote attackers to cause a denial of service (daemon crash) via a flood of low-difficulty header chains (aka a "Chain Width Expansion" attack) because a node does not first verify that a presented chain has enough work before committing to store it. |
| Bitcoin Core through 27.2 allows transaction-relay jamming via an off-chain protocol attack, a related issue to CVE-2024-52913. For example, the outcome of an HTLC (Hashed Timelock Contract) can be changed because a flood of transaction traffic prevents propagation of certain Lightning channel transactions. |
| Bitcoin Core before 25.0 allows remote attackers to cause a denial of service (blocktxn message-handling assertion and node exit) by including transactions in a blocktxn message that are not committed to in a block's merkle root. FillBlock can be called twice for one PartiallyDownloadedBlock instance. |
| In Bitcoin Core before 25.1, an attacker can cause a node to not download the latest block, because there can be minutes of delay when an announcing peer stalls instead of complying with the peer-to-peer protocol specification. |
| Bitcoin Core before 0.20.0 allows remote attackers to cause a denial of service (infinite loop) via a malformed GETDATA message. |
| In Bitcoin Core before 25.0, a peer can affect the download state of other peers by sending a mutated block. |
| Bitcoin Core before 22.0 has a CAddrMan nIdCount integer overflow and resultant assertion failure (and daemon exit) via a flood of addr messages. |
| Bitcoin Core before 22.0 has a miniupnp infinite loop in which it allocates memory on the basis of random data received over the network, e.g., large M-SEARCH replies from a fake UPnP device. |
| Bitcoin Core before 0.15.0 allows a denial of service (OOM kill of a daemon process) via a flood of minimum difficulty headers. |
| Bitcoin Core before 0.20.0 allows remote attackers to cause a denial of service (memory consumption) via a crafted INV message. |
| In Bitcoin Core before 0.18.0, a node could be stalled for hours when processing the orphans of a crafted unconfirmed transaction. |
| In Bitcoin Core before 0.21.0, an attacker could prevent a node from seeing a specific unconfirmed transaction, because transaction re-requests are mishandled. |
| Bitcoin Core before 0.21.0 allows a network split that is resultant from an integer overflow (calculating the time offset for newly connecting peers) and an abs64 logic bug. |
| The Bitcoin Proof-of-Work algorithm does not consider a certain attack methodology related to 80-byte block headers with a variety of initial 64-byte chunks followed by the same 16-byte chunk, multiple candidate root values ending with the same 4 bytes, and calculations involving sqrt numbers. This violates the security assumptions of (1) the choice of input, outside of the dedicated nonce area, fed into the Proof-of-Work function should not change its difficulty to evaluate and (2) every Proof-of-Work function execution should be independent. NOTE: a number of persons feel that this methodology is a benign mining optimization, not a vulnerability |
| The CTransaction::FetchInputs method in bitcoind and Bitcoin-Qt before 0.8.0rc1 copies transactions from disk to memory without incrementally checking for spent prevouts, which allows remote attackers to cause a denial of service (disk I/O consumption) via a Bitcoin transaction with many inputs corresponding to many different parts of the stored block chain. |
| bitcoind and Bitcoin-Qt 0.8.x before 0.8.1 do not enforce a certain block protocol rule, which allows remote attackers to bypass intended access restrictions and conduct double-spending attacks via a large block that triggers incorrect Berkeley DB locking in older product versions. |
| bitcoind and Bitcoin-Qt before 0.4.9rc2, 0.5.x before 0.5.8rc2, 0.6.x before 0.6.5rc2, and 0.7.x before 0.7.3rc2, and wxBitcoin, do not properly consider whether a block's size could require an excessive number of database locks, which allows remote attackers to cause a denial of service (split) and enable certain double-spending capabilities via a large block that triggers incorrect Berkeley DB locking. |
| wxBitcoin and bitcoind before 0.3.5 allow remote attackers to cause a denial of service (daemon crash) via a Bitcoin transaction containing an OP_LSHIFT script opcode. |
