<?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>Thu, 08 Oct 2026 14:08:47 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-309178</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-309178</link>
      <description>EUVD-2026-309178</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-309178</guid>
    </item>
    <item>
      <title>fkie_cve-2026-44497</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-44497</link>
      <description>&lt;p&gt;ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0 and prior to zebra-script version 6.0.0, the fix for CVE-2026-41583 introduced a separate issue due to insufficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes. This issue has been patched in zebrad version 4.4.0 and zebra-script version 6.0.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0 and prior to zebra-script version 6.0.0, the fix for CVE-2026-41583 introduced a separate issue due to insufficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes. This issue has been patched in zebrad version 4.4.0 and zebra-script version 6.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-44497</guid>
    </item>
    <item>
      <title>GHSA-gq4h-3grw-2rhv — Zebra has Consensus Divergence in Transparent Sighash Hash-Type Handling due to Stale Buffer</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gq4h-3grw-2rhv</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: zebra-script, crates.io: zebrad&lt;/p&gt;
&lt;p&gt;# CVE-2026-44497: Consensus Divergence in Transparent Sighash Hash-Type Handling due to Stale Buffer&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The fix for https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj introduced a separate issue due to insuficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes.&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;Zebra 4.3.1.&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++, called from Zebra through a foreign function interface (FFI) with a Rust callback that computes the sighash. The fix for  https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj added the missing V5 hash-type consensus check on the Rust side, returning `None` for undefined hash types. However, the FFI bridge only writes to the C++ sighash buf…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: zebra-script, crates.io: zebrad&lt;/p&gt;
&lt;p&gt;# CVE-2026-44497: Consensus Divergence in Transparent Sighash Hash-Type Handling due to Stale Buffer&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The fix for https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj introduced a separate issue due to insuficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes.&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;Zebra 4.3.1.&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++, called from Zebra through a foreign function interface (FFI) with a Rust callback that computes the sighash. The fix for  https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj added the missing V5 hash-type consensus check on the Rust side, returning `None` for undefined hash types. However, the FFI bridge only writes to the C++ sighash buf…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gq4h-3grw-2rhv</guid>
    </item>
  </channel>
</rss>
