<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Consensus-Failure — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/consensus-failure/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Thu, 07 May 2026 20:56:21 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/consensus-failure/feed.xml" rel="self" type="application/rss+xml"/><item><title>Zebra Consensus Divergence in Transparent Sighash Hash-Type Handling (CVE-2026-44497)</title><link>https://feed.craftedsignal.io/briefs/2024-01-09-zebra-consensus-divergence/</link><pubDate>Thu, 07 May 2026 20:56:21 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-09-zebra-consensus-divergence/</guid><description>Zebra versions prior to 4.4.0 exhibit a consensus divergence vulnerability (CVE-2026-44497) due to insufficient error handling of invalid sighash types during sighash computation, potentially leading to network partitioning and double-spend attacks.</description><content:encoded><![CDATA[<p>Zebra, a Zcash node implementation, versions prior to 4.4.0 are vulnerable to a critical consensus divergence issue. This flaw, identified as CVE-2026-44497, stems from inadequate error handling when processing invalid sighash types during signature hash computation. Specifically, when an undefined hash type is encountered, Zebra&rsquo;s foreign function interface (FFI) does not properly propagate the error from the Rust-based sighash computation callback to the C++ verification code. Consequently, the C++ checker may use a stale digest from a previous valid signature validation, leading to the acceptance of invalid transactions. This discrepancy can create a consensus split between Zebra and zcashd nodes, potentially disrupting the Zcash network. The vulnerability was introduced as a side effect of a previous fix (GHSA-8m29-fpq5-89jj).</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Attacker crafts a malicious transaction.</li>
<li>Transaction contains a transparent output.</li>
<li>The output is spent by a script that includes <code>OP_CHECKSIGVERIFY</code> and <code>OP_CHECKSIG</code>.</li>
<li><code>OP_CHECKSIGVERIFY</code> is executed with a valid hash type, priming the C++ sighash buffer with a valid digest.</li>
<li><code>OP_CHECKSIG</code> is executed with an undefined hash type.</li>
<li>Zebra&rsquo;s Rust callback returns <code>None</code> due to the undefined hash type, but the C++ checker does not receive this signal.</li>
<li>The C++ checker verifies the invalid signature against the stale digest in the buffer.</li>
<li>Zebra incorrectly accepts the spend, while zcashd rejects it, leading to a consensus split.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>The vulnerability can lead to a consensus failure within the Zcash network. An attacker can exploit this to cause network partitioning, where different nodes have conflicting views of the blockchain&rsquo;s state. This can lead to service disruption for users relying on affected Zebra nodes. Furthermore, the vulnerability could potentially be exploited for double-spend attacks if a malicious miner relies on Zebra&rsquo;s faulty validation results. While the impact is mitigated by the prevalence of <code>zcashd</code> among miners, any miner or template pipeline relying on Zebra&rsquo;s validation is at risk.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade all Zebra nodes to version 4.4.0 or later immediately to address CVE-2026-44497.</li>
<li>Monitor Zebra node logs for unexpected consensus errors or forks following the upgrade.</li>
<li>Evaluate the feasibility of implementing custom monitoring to detect divergence between Zebra and zcashd validation results within your environment.</li>
</ul>
]]></content:encoded><category domain="severity">critical</category><category domain="type">advisory</category><category>consensus-failure</category><category>vulnerability</category><category>network-partition</category></item><item><title>Zebra Block Validator Sigops Undercount Vulnerability</title><link>https://feed.craftedsignal.io/briefs/2026-05-zebra-sigops-undercount/</link><pubDate>Thu, 07 May 2026 20:54:33 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-zebra-sigops-undercount/</guid><description>Zebra's block validator undercounts signature operations, allowing it to accept invalid blocks, leading to a network split between Zebra and zcashd nodes.</description><content:encoded><![CDATA[<p>Zebra, a Zcash node implementation, contains a critical vulnerability where its block validator incorrectly calculates the number of signature operations (sigops) within a block. This flaw, present in versions prior to 4.4.0, stems from two distinct undercounting issues: incorrect handling of coinbase transactions and P2SH scripts. An attacker, typically a malicious miner, can exploit this to create blocks that Zebra accepts but <code>zcashd</code> rejects. This discrepancy leads to a consensus failure, causing a network split where Zebra nodes follow a different, invalid chain. This vulnerability poses a significant risk to network integrity for operators relying on Zebra for consensus.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>A malicious miner crafts a block with a high number of signature operations.</li>
<li>The miner hides sigops in the coinbase <code>scriptSig</code> (up to ~98 sigops).</li>
<li>The miner includes transactions with a high number of P2SH spends whose redeem scripts collectively exceed 20000 sigops.</li>
<li>Zebra&rsquo;s block validator undercounts sigops due to the coinbase scriptSig and P2SH redeem script handling issues.</li>
<li>Zebra accepts the invalid block because the sigop count is below <code>MAX_BLOCK_SIGOPS</code>.</li>
<li><code>zcashd</code> rejects the block due to accurately counting the excessive sigops.</li>
<li>Zebra nodes build on the invalid block, diverging from the main Zcash chain followed by <code>zcashd</code> nodes.</li>
<li>A network split occurs, where Zebra and <code>zcashd</code> nodes operate on separate chains.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>The vulnerability results in a network split between Zebra and <code>zcashd</code> nodes. Zebra nodes may accept and propagate blocks that are considered invalid by the rest of the network, leading to transaction rollbacks and unpredictable behavior for users relying on Zebra for consensus. This could lead to a denial of service and financial losses for users of Zebra nodes. There is no information available regarding the number of victims or specific sectors targeted.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade Zebra nodes to version 4.4.0 or later to patch the vulnerability as advised by the vendor.</li>
<li>Monitor network consensus and validate Zebra&rsquo;s chain against other Zcash implementations (<code>zcashd</code>) to detect potential forks caused by this vulnerability.</li>
<li>Consider deploying network-level rules to identify blocks with unusually large coinbase <code>scriptSig</code> fields.</li>
<li>Enable detailed logging for block validation processes in Zebra to investigate potential consensus failures.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>blockchain</category><category>consensus-failure</category><category>zcash</category></item></channel></rss>