https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-07T20:06:48.936541+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/euvd-2026-319124 EUVD-2026-319124 2026-10-07T20:06:48.939052+00:00 EUVD-2026-319124 https://cve.radiocsirt.org/vuln/fkie_cve-2026-44714 fkie_cve-2026-44714 2026-10-07T20:06:48.939083+00:00

The bitcoinj library is a Java implementation of the Bitcoin protocol. Prior to 0.17.1, ScriptExecution.correctlySpends() contains two fast-path verification bugs for standard P2PKH and native P2WPKH spends in core/src/main/java/org/bitcoinj/script/ScriptExecution.java. In both branches, bitcoinj verifies an attacker-controlled signature/public-key pair but fails to verify that the public key is the one committed to by the output being spent. As a result, any attacker keypair can satisfy bitcoinj's local verification for arbitrary P2PKH and P2WPKH outputs. This vulnerability is fixed in 0.17.1.

 https://cve.radiocsirt.org/vuln/ghsa-hfcf-v2f8-x9pc GHSA-hfcf-v2f8-x9pc — bitcoinj has a ScriptExecution P2PKH/P2WPKH Verification Bypass 2026-10-07T20:06:48.939117+00:00

Affected: Maven: org.bitcoinj:bitcoinj-core

### Summary `ScriptExecution.correctlySpends()` contains two fast-path verification bugs for standard `P2PKH` and native `P2WPKH` spends in `core/src/main/java/org/bitcoinj/script/ScriptExecution.java`.

In both branches, bitcoinj verifies an attacker-controlled signature/public-key pair but fails to verify that the public key is the one committed to by the output being spent. As a result, any attacker keypair can satisfy bitcoinj's local verification for arbitrary `P2PKH` and `P2WPKH` outputs.

This doesn't affect the SPV (simple payment verification) trust model, as this model follows PoW and doesn't verify input signatures at all.

### Details The issue is in the optimized branches of `ScriptExecution.correctlySpends(...)`.

In the `P2PKH` fast path at `core/src/main/java/org/bitcoinj/script/ScriptExecution.java:1042`, the code:

- parses the attacker-supplied signature from `scriptSig` - parses the attacker-supplied public key from `scriptSig` - computes the sighash against the victim output's `scriptPubKey` - checks only `pubkey.verify(sigHash, signature)`

It never enforces the missing `P2PKH` binding:

- `HASH160(pubkey) == ScriptPattern.extractHashFromP2PKH(scriptPubKey)`

That means the `OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG` semantics are not actually enforced in this fast path.

Relevant code:

```java } else if (ScriptPattern.isP2PKH(scriptPubKey)) { if (chunks.size() != 2) throw new ScriptException(...); TransactionSignature signatu…