<?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>Fri, 02 Oct 2026 12:05:44 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-309234</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-309234</link>
      <description>EUVD-2026-309234</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-309234</guid>
    </item>
    <item>
      <title>fkie_cve-2026-41583</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-41583</link>
      <description>&lt;p&gt;ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and prior to zebra-script version 5.0.2, after a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes. In a similar vein, for V4 transactions, Zebra mistakenly used the &amp;#34;canonical&amp;#34; hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split. This issue has been patched in zebrad version 4.3.1 and zebra-script version 5.0.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and prior to zebra-script version 5.0.2, after a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes. In a similar vein, for V4 transactions, Zebra mistakenly used the &amp;#34;canonical&amp;#34; hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split. This issue has been patched in zebrad version 4.3.1 and zebra-script version 5.0.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-41583</guid>
    </item>
    <item>
      <title>GHSA-8m29-fpq5-89jj — Zebra Vulnerable to Consensus Divergence in Transparent Sighash Hash-Type Handling</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8m29-fpq5-89jj</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: zebrad, crates.io: zebra-script&lt;/p&gt;
&lt;p&gt;# CVE-2026-41583: Consensus Divergence in Transparent Sighash Hash-Type Handling&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;After a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes.&lt;/p&gt;
&lt;p&gt;In a similar vein, for V4 transactions, Zebra mistakenly used the &amp;#34;canonical&amp;#34; hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split.&lt;/p&gt;
&lt;p&gt;## Severity&lt;/p&gt;
&lt;p&gt;**Critical** - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.&lt;/p&gt;
&lt;p&gt;Note that the impact is currently alleviated by the fact that currently most miners run `zcashd`.&lt;/p&gt;
&lt;p&gt;## Affected Versions&lt;/p&gt;
&lt;p&gt;All Zebra versions prior to version 4.3.1. (Some older versions are not impacted but are no longer supported by the network.)&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;Verification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code was called from Zebra through foreign function interface (FFI). That interface was clunky because it required parsing the whole transaction in C++ code, which would then pull Rust libraries which could get in conflict with…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: zebrad, crates.io: zebra-script&lt;/p&gt;
&lt;p&gt;# CVE-2026-41583: Consensus Divergence in Transparent Sighash Hash-Type Handling&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;After a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes.&lt;/p&gt;
&lt;p&gt;In a similar vein, for V4 transactions, Zebra mistakenly used the &amp;#34;canonical&amp;#34; hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split.&lt;/p&gt;
&lt;p&gt;## Severity&lt;/p&gt;
&lt;p&gt;**Critical** - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.&lt;/p&gt;
&lt;p&gt;Note that the impact is currently alleviated by the fact that currently most miners run `zcashd`.&lt;/p&gt;
&lt;p&gt;## Affected Versions&lt;/p&gt;
&lt;p&gt;All Zebra versions prior to version 4.3.1. (Some older versions are not impacted but are no longer supported by the network.)&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;Verification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code was called from Zebra through foreign function interface (FFI). That interface was clunky because it required parsing the whole transaction in C++ code, which would then pull Rust libraries which could get in conflict with…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8m29-fpq5-89jj</guid>
    </item>
  </channel>
</rss>
