<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 07 Oct 2026 20:06:13 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-319124</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-319124</link>
      <description>EUVD-2026-319124</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-319124</guid>
    </item>
    <item>
      <title>fkie_cve-2026-44714</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-44714</link>
      <description>&lt;p&gt;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&amp;#39;s local verification for arbitrary P2PKH and P2WPKH outputs. This vulnerability is fixed in 0.17.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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&amp;#39;s local verification for arbitrary P2PKH and P2WPKH outputs. This vulnerability is fixed in 0.17.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-44714</guid>
    </item>
    <item>
      <title>GHSA-hfcf-v2f8-x9pc — bitcoinj has a ScriptExecution P2PKH/P2WPKH Verification Bypass</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hfcf-v2f8-x9pc</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.bitcoinj:bitcoinj-core&lt;/p&gt;
&lt;p&gt;### 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`.&lt;/p&gt;
&lt;p&gt;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&amp;#39;s local verification for arbitrary `P2PKH` and `P2WPKH` outputs.&lt;/p&gt;
&lt;p&gt;This doesn&amp;#39;t affect the SPV (simple payment verification) trust model, as this model follows PoW and doesn&amp;#39;t verify input signatures at all.&lt;/p&gt;
&lt;p&gt;### Details
The issue is in the optimized branches of `ScriptExecution.correctlySpends(...)`.&lt;/p&gt;
&lt;p&gt;In the `P2PKH` fast path at `core/src/main/java/org/bitcoinj/script/ScriptExecution.java:1042`, the code:&lt;/p&gt;
&lt;p&gt;- parses the attacker-supplied signature from `scriptSig`
- parses the attacker-supplied public key from `scriptSig`
- computes the sighash against the victim output&amp;#39;s `scriptPubKey`
- checks only `pubkey.verify(sigHash, signature)`&lt;/p&gt;
&lt;p&gt;It never enforces the missing `P2PKH` binding:&lt;/p&gt;
&lt;p&gt;- `HASH160(pubkey) == ScriptPattern.extractHashFromP2PKH(scriptPubKey)`&lt;/p&gt;
&lt;p&gt;That means the `OP_DUP OP_HASH160 &amp;lt;hash&amp;gt; OP_EQUALVERIFY OP_CHECKSIG` semantics are not actually enforced in this fast path.&lt;/p&gt;
&lt;p&gt;Relevant code:&lt;/p&gt;
&lt;p&gt;```java
} else if (ScriptPattern.isP2PKH(scriptPubKey)) {
    if (chunks.size() != 2)
        throw new ScriptException(...);
    TransactionSignature signatu…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.bitcoinj:bitcoinj-core&lt;/p&gt;
&lt;p&gt;### 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`.&lt;/p&gt;
&lt;p&gt;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&amp;#39;s local verification for arbitrary `P2PKH` and `P2WPKH` outputs.&lt;/p&gt;
&lt;p&gt;This doesn&amp;#39;t affect the SPV (simple payment verification) trust model, as this model follows PoW and doesn&amp;#39;t verify input signatures at all.&lt;/p&gt;
&lt;p&gt;### Details
The issue is in the optimized branches of `ScriptExecution.correctlySpends(...)`.&lt;/p&gt;
&lt;p&gt;In the `P2PKH` fast path at `core/src/main/java/org/bitcoinj/script/ScriptExecution.java:1042`, the code:&lt;/p&gt;
&lt;p&gt;- parses the attacker-supplied signature from `scriptSig`
- parses the attacker-supplied public key from `scriptSig`
- computes the sighash against the victim output&amp;#39;s `scriptPubKey`
- checks only `pubkey.verify(sigHash, signature)`&lt;/p&gt;
&lt;p&gt;It never enforces the missing `P2PKH` binding:&lt;/p&gt;
&lt;p&gt;- `HASH160(pubkey) == ScriptPattern.extractHashFromP2PKH(scriptPubKey)`&lt;/p&gt;
&lt;p&gt;That means the `OP_DUP OP_HASH160 &amp;lt;hash&amp;gt; OP_EQUALVERIFY OP_CHECKSIG` semantics are not actually enforced in this fast path.&lt;/p&gt;
&lt;p&gt;Relevant code:&lt;/p&gt;
&lt;p&gt;```java
} else if (ScriptPattern.isP2PKH(scriptPubKey)) {
    if (chunks.size() != 2)
        throw new ScriptException(...);
    TransactionSignature signatu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hfcf-v2f8-x9pc</guid>
    </item>
  </channel>
</rss>
