<?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>Tue, 06 Oct 2026 11:24:38 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-355252</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-355252</link>
      <description>EUVD-2026-355252</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-355252</guid>
    </item>
    <item>
      <title>fkie_cve-2026-52735</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-52735</link>
      <description>&lt;p&gt;ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, Zebra can accept a block that zcashd rejects because the P2SH signature-operation counter undercounts redeem scripts containing a disabled opcode followed by signature opcodes. In zebra-script/src/lib.rs, p2sh_input_sigop_count used the pure-Rust script::Code::sig_op_count path, whose try_fold parser stops at disabled opcodes such as OP_CODESEPARATOR and returns only the partial count accumulated before the error. The zcashd reference implementation continues static signature-operation counting through disabled opcodes, so an attacker can broadcast P2SH spends that Zebra counts below MAX_BLOCK_SIGOPS while zcashd counts above the 20,000-operation limit. If a Zebra miner includes those transactions, Zebra validators accept the block while zcashd validators reject it, creating a consensus chain split that affects network integrity and availability without requiring the attacker to produce a block. This issue is fixed in version 4.5.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, Zebra can accept a block that zcashd rejects because the P2SH signature-operation counter undercounts redeem scripts containing a disabled opcode followed by signature opcodes. In zebra-script/src/lib.rs, p2sh_input_sigop_count used the pure-Rust script::Code::sig_op_count path, whose try_fold parser stops at disabled opcodes such as OP_CODESEPARATOR and returns only the partial count accumulated before the error. The zcashd reference implementation continues static signature-operation counting through disabled opcodes, so an attacker can broadcast P2SH spends that Zebra counts below MAX_BLOCK_SIGOPS while zcashd counts above the 20,000-operation limit. If a Zebra miner includes those transactions, Zebra validators accept the block while zcashd validators reject it, creating a consensus chain split that affects network integrity and availability without requiring the attacker to produce a block. This issue is fixed in version 4.5.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-52735</guid>
    </item>
    <item>
      <title>GHSA-gf9r-m956-97qx — zebrad has consensus divergence via P2SH sigop undercount in pure-Rust disabled-opcode parser</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gf9r-m956-97qx</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;### Am I affected&lt;/p&gt;
&lt;p&gt;You are affected if:&lt;/p&gt;
&lt;p&gt;1. You run any version of `zebrad` up to and including `v4.4.1`.
2. Your node validates blocks on mainnet, testnet, or any network where both Zebra and zcashd nodes participate.&lt;/p&gt;
&lt;p&gt;All default configurations are affected. No feature flags, non-default settings, or special build options are required.&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Zebra&amp;#39;s P2SH sigop counter uses a pure-Rust code path that short-circuits on disabled opcodes (such as `OP_CODESEPARATOR`), returning a partial count of zero for any sigops following the disabled opcode. The reference implementation (zcashd) correctly counts through disabled opcodes in its static sigop analysis. This produces a consensus divergence: Zebra accepts blocks that zcashd rejects when the block-wide `MAX_BLOCK_SIGOPS = 20,000` threshold is crossed on one side but not the other.&lt;/p&gt;
&lt;p&gt;An attacker can exploit this without mining capability. Broadcasting transactions that spend P2SH outputs with malicious redeem scripts is sufficient; any Zebra miner who includes those transactions in a block triggers a chain split between Zebra and zcashd validators.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The P2SH sigop counter at `zebra-script/src/lib.rs:399` calls `script::Code(redeemed_bytes).sig_op_count(true)`, which is a pure-Rust path through `zcash_script-0.4.4`. The legacy (non-P2SH) sigop counter at `lib.rs:282-289` correctly uses the C++ FFI via `interpreter.legacy_sigop_count_script()`. Only the P2SH path bypasses the FFI.&lt;/p&gt;
&lt;p&gt;The Rust parser in `zcash_scri…&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;### Am I affected&lt;/p&gt;
&lt;p&gt;You are affected if:&lt;/p&gt;
&lt;p&gt;1. You run any version of `zebrad` up to and including `v4.4.1`.
2. Your node validates blocks on mainnet, testnet, or any network where both Zebra and zcashd nodes participate.&lt;/p&gt;
&lt;p&gt;All default configurations are affected. No feature flags, non-default settings, or special build options are required.&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Zebra&amp;#39;s P2SH sigop counter uses a pure-Rust code path that short-circuits on disabled opcodes (such as `OP_CODESEPARATOR`), returning a partial count of zero for any sigops following the disabled opcode. The reference implementation (zcashd) correctly counts through disabled opcodes in its static sigop analysis. This produces a consensus divergence: Zebra accepts blocks that zcashd rejects when the block-wide `MAX_BLOCK_SIGOPS = 20,000` threshold is crossed on one side but not the other.&lt;/p&gt;
&lt;p&gt;An attacker can exploit this without mining capability. Broadcasting transactions that spend P2SH outputs with malicious redeem scripts is sufficient; any Zebra miner who includes those transactions in a block triggers a chain split between Zebra and zcashd validators.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The P2SH sigop counter at `zebra-script/src/lib.rs:399` calls `script::Code(redeemed_bytes).sig_op_count(true)`, which is a pure-Rust path through `zcash_script-0.4.4`. The legacy (non-P2SH) sigop counter at `lib.rs:282-289` correctly uses the C++ FFI via `interpreter.legacy_sigop_count_script()`. Only the P2SH path bypasses the FFI.&lt;/p&gt;
&lt;p&gt;The Rust parser in `zcash_scri…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gf9r-m956-97qx</guid>
    </item>
  </channel>
</rss>
