bitcoinj-core CVE-2026-44714

Exploitation requires that the target application uses bitcoinj-core versions 0.15.0 through 0.17.0 and operates OUTSIDE the standard SPV (Simple Payment Verification) trust model. Specifically vulnerable are applications that call ScriptExecution.correctlySpends() - either directly or through affected methods in TransactionInput.java:546, Wallet.java:4520, LocalTransactionSigner.java:84, or CustomTransactionSigner.java:77 - and make security-critical decisions based on the return value for P2PKH or P2WPKH transaction validation. The application must process attacker-supplied Bitcoin transactions (via API, RPC interface, or network peer connections) and rely on local signature verification rather than pure SPV proof-of-work following. Standard SPV wallet implementations are NOT vulnerable because they do not verify input signatures locally. Most at risk are custom payment processors, layer-2 protocol implementations (Lightning Network components), Bitcoin exchanges with non-standard validation logic, and any service using correctlySpends() for authorization checks outside Bitcoin's consensus validation. Network access (AV:N) means attacker can deliver malicious transactions remotely without requiring local system access. No authentication (PR:N) or user interaction (UI:N) required once the vulnerable application accepts transaction data for validation. Default configurations are exploitable if they include the vulnerable code path in their transaction processing pipeline.

CVSS rates this 7.5 HIGH (AV:N/AC:L/PR:N/UI:N) indicating network-exploitable without authentication or user interaction, but impact is limited to integrity (I:H) with no confidentiality or availability compromise. However, real-world risk depends heavily on deployment context. For SPV nodes (majority of bitcoinj usage in lightweight wallets), there is NO direct risk because SPV follows longest proof-of-work chain without local signature verification. Risk is HIGH ONLY for non-SPV applications that: (1) call correctlySpends() for input validation, (2) make security decisions (transaction acceptance, pre-signing authorization) based on its return value, and (3) operate outside Bitcoin's consensus layer (e.g., payment processors with custom validation, layer-2 protocols). The CVSS vector's PR:N may be misleading - exploitation requires the target application to process attacker-crafted transactions through the vulnerable code path, which in practice requires some application-specific delivery mechanism. No EPSS score available limits quantitative exploitation probability assessment. Not listed in CISA KEV indicates no confirmed active exploitation despite public disclosure and patch availability since version 0.17.1 release. GitHub advisory provides detailed technical breakdown and proof-of-concept code snippets, lowering exploitation barrier for sophisticated attackers targeting vulnerable integrations. Primary risk is to custom Bitcoin applications and layer-2 implementations that depend on bitcoinj for transaction validation outside standard SPV workflows.

An attacker targeting a Bitcoin payment processor that uses bitcoinj for transaction pre-validation crafts a fraudulent transaction attempting to spend a P2PKH output they don't control. Instead of providing the legitimate public key that hashes to the output's committed hash, they insert their own keypair and generate a valid ECDSA signature with their private key. When the payment processor's validation logic calls ScriptExecution.correctlySpends(), the vulnerable fast-path verifies the attacker's signature against the attacker's public key and incorrectly returns success, bypassing the missing hash comparison check. The processor's application logic interprets this as a valid spend authorization and processes the fraudulent transaction, potentially crediting the attacker's account or triggering downstream business logic. If the transaction reaches the Bitcoin network, consensus nodes with correct verification (Bitcoin Core) would reject it, but damage occurs in the application's internal state or off-chain systems that trusted the flawed local validation.