CVE-2026-104422

Executive Summary

CVE-2026-104422 is a block-synchronization validation flaw in the Zebra (zebrad) Zcash full-node client affecting versions before 6.3.0. The node trusts the block height declared in an unvalidated coinbase scriptSig during the sync download path, discarding blocks that appear "too far behind" the current tip before consensus validation, and does not penalize the peer that supplied them. A remote, unauthenticated peer can repeatedly serve a canonical block whose coinbase claims height 1 while still supplying the requested block hash, causing the victim node to stall in block discovery and remain on stale chain state — a network-reachable denial-of-service/chain-lag condition rated CVSS 7.5 (A:H).

Technical Analysis

Zebra's block sync pipeline has two logically distinct phases: (1) fetching candidate blocks by hash from connected peers, and (2) validating those blocks through full consensus. This CVE arises because a height heuristic used in phase (1) consumes data that is only trustworthy after phase (2). Specifically, per the NVD description, the sync download path "reads a block's height from its unvalidated coinbase scriptSig and drops blocks that appear too far behind the tip before consensus validation."

In Bitcoin-derived consensus (which Zcash and thus Zebra implement), the coinbase transaction's scriptSig carries an arbitrary byte string that, by BIP34-era convention, is expected to commit to the block height. That value is not consensus-enforced to match the block's actual position in the chain in the way other header fields are. The canonical, authoritative height is determined by the block header's prevBlockHash linkage back to the genesis block, not by the coinbase bytes. An implementation that reads height from the coinbase scriptSig for an early, pre-consensus "is this block useful?" decision is therefore trusting attacker-controllable input for a synchronization-policy decision.

The second ingredient is the V5 transaction ID format. As noted in the description, "V5 transaction IDs exclude the scriptSig." Zebra's ZIP-244/ZIP-225-style transaction ID computation omits the signature scripts from the txid commitment. This produces a critical property: a malicious peer can mutate the coinbase scriptSig (changing the claimed height to 1) without changing the block's hash or the txid of the coinbase. The peer can therefore keep serving the same requested hash while presenting a block that the victim classifies as "too far behind the tip," causing the victim to drop it.

The third ingredient is the absence of peer penalization. The description states the node drops these blocks "without penalizing the supplying peer." Because no ban score or disconnect is applied, the malicious peer retains its connection and can repeat the behavior indefinitely.

Net effect: the node's newest-block discovery loop is delayed. The attacker does not need to forge signatures or break consensus; it merely exploits a trust-ordering bug in the pre-validations sync filter. Because the block hash the victim asked for is returned faithfully, hash-based integrity checks pass — the corruption is at the height-heuristic layer only. The flaw class is CWE-345 (Insufficient Verification of Data Authenticity): the node relies on unauthenticated, malleable metadata (coinbase scriptSig height) to make a control decision.

Attack surface: the Zcash peer-to-peer network (typically TCP port 8233 on mainnet), reachable by any connected peer. No authentication, no prior trust, no user interaction. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects this: network-reachable, low complexity, no privileges required, no confidentiality or integrity loss but a high availability impact on the sync function.

The root-cause corrective action in 6.3.0 is implicit from the description boundary ("before 6.3.0"): the sync path should not gate on the coinbase-derived height prior to consensus validation, or should penalize peers that repeatedly supply blocks failing the height heuristic. No vendor commit, advisory, or diff is present in the tracked sources, so the exact remediation implementation cannot be confirmed from available data.

Exploitation Scenarios

No public PoC or exploit code is available for CVE-2026-104422. The chain below is inferred strictly from the vulnerability class (unvalidated-input policy decision + txid malleability that preserves the served hash) and the NVD description. No specific function names, file paths, or API parameters beyond those in the description are asserted.

1. Reconnaissance / target identification. The attacker identifies reachable Zebra (zebrad) nodes on the Zcash peer-to-peer network running a version earlier than 6.3.0. Target enumeration is network-level (peer discovery, listening port 8233, or node fingerprinting). No credentials are needed — any inbound or outbound peer connection to the victim suffices.

2. Triggering the specific flaw class. The malicious peer needs to be the source from which the victim requests blocks during initial-block-download / catch-up. When the victim requests a block by hash, the attacker responds with the canonical block carrying the requested hash, but with its coinbase scriptSig altered so the embedded height value reads "1" (i.e., far behind the current tip). Because V5 transaction IDs exclude the scriptSig, this mutation does not change the transaction ID or the block hash the victim asked for — so hash-level matching succeeds and the response is accepted as the requested object.

3. Payload / execution at the vulnerability-class level. The victim's sync download path, prior to consensus validation, parses the coinbase scriptSig, extracts a height it deems "too far behind the tip," and drops the block. Crucially, the drop is a policy drop, not a consensus failure, and the description states the supplying peer is not penalized — no ban score, no disconnect. The attacker repeats this for subsequent requests, effectively withholding forward progress while remaining connected.

4. Post-exploitation impact. The victim node remains stuck discovering/disclosing the newest chain tip; it lags behind the honest network and continues operating on stale chain state. There is no key compromise, no fund theft, and no consensus rule violation — the impact is availability/liveness of the node (CVSS A:H). A node kept in a stale tip state may serve or rely on outdated view-of-chain data and fails to participate correctly in the network until the malicious peer is disconnected. Recovery is possible once the attacker is dropped or the peer set changes, which is why integrity and confidentiality sub-scores are N.

Caveats: this scenario assumes the coinbase height heuristic exists exactly as the description states and that dropping is non-fatal to the connection; both are taken verbatim from the NVD text. Any finer mechanics (exact fields, thresholds, function names) are not available from the provided data and are not invented here.

Impact Assessment

CVSS 3.1 base score 7.5 (High), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

• Confidentiality: None (C:N). The flaw exposes no data; it does not leak memory, credentials, or chain secrets.
• Integrity: None (I:N). Consensus rules are not violated. The attacker cannot force acceptance of an invalid block; the trick is a denial of honest blocks, not an injection of malicious ones. The canonical block served still carries the correct requested hash.
• Availability: High (A:H). The victim node's synchronization/liveness is directly impaired — the core described effect is "delaying the node's discovery of the newest block."
• Exploitability: Easy. AV:N (network P2P), AC:L (no special conditions), PR:N (no privileges), UI:N (no user action). Any connected peer can mount it.
• Scope: Unchanged (S:U). Impact stays within the affected node/cluster's availability domain.

Blast radius. Affected systems are Zcash full nodes running Zebra (zebrad) below 6.3.0. Exposure is any node that accepts inbound peers or dials out to potentially malicious peers — effectively most public full nodes. Syncing or lagging nodes are the most exposed; a node already at tip may be less affected until it needs to catch up again after a reorg or restart. Downstream consumers (wallets, exchanges, merchants, block explorers, mining infrastructure) that depend on the node's chain-tip view inherit the staleness. No end-user data or funds are at risk from this CVE alone. No CISA KEV listing and no public exploit code exist as of this writing, so weaponization is currently theoretical but trivially within reach of any peer-level adversary.

Detection Guidance

Synchronization-stall conditions are noisy only if operators instrument peer behavior and block provenance. The following detections key on the observable signatures: repeated drops of blocks whose coinbase scriptSig claims an implausibly low height, unchanged served hashes, and a single peer dominating "rejected-lagging-block" events without disconnect/ban.

Sigma Rule

title: Zebra (zebrad) Block Sync Stall via Malleable Coinbase Height
id: 7f4c1a2e-zebra-cve-2026-104422
status: experimental
description: Detects repeated pre-consensus drops of blocks whose coinbase scriptSig claims a height far behind tip without peer penalization (CVE-2026-104422).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-104422
author: valtersit.com
logsource:
  product: zebra
  service: node
detection:
  selection:
    event_action:
      - "block_sync_dropped"
      - "sync_block_rejected"
    reason|contains:
      - "behind tip"
      - "height"
  coinbase_claimed_height:
    - 0
    - 1
  same_peer_repeat: true
  condition: selection and coinbase_claimed_height and same_peer_repeat
fields:
  - peer_addr
  - block_hash
  - coinbase_claimed_height
  - tip_height
falsepositives:
  - Legitimately reorged or very old blocks on a clearly lagging node (expected once, not repeated by one peer)
level: high
tags:
  - attack.t1499
  - cve.2026.104422

YARA Rule

rule CVE_2026_104422_Zebra_Sync_Coinbase_Height
{
    meta:
        description = "Flags Zebra/zebrad nodes below 6.3.0 and sync code paths that gate on unvalidated coinbase scriptSig height"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-104422"
        cve = "CVE-2026-104422"
        author = "valtersit.com"
        date = "2026-01-01"

    strings:
        $ver = "6.3.0"
        $sync1 = "behind tip" nocase ascii wide
        $sync2 = "block_sync" ascii
        $sync3 = "scriptSig" ascii nocase
        $sync4 = "coinbase" ascii nocase
        $zebra = "zebrad" ascii nocase

    condition:
        uint32(0) == 0x464c457f and
        filesize < 200MB and
        $zebra and
        any of ($sync1, $sync2) and
        any of ($sync3, $sync4)
}

Suricata IDS Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET 8233 ( \
  msg:"CVE-2026-104422 Zebra/zebrad block sync stall via malleable coinbase height"; \
  flow:established,to_server; \
  dsize:>0; \
  content:"|04 00 00 80|"; \
  threshold:type both, track by_src, count 5, seconds 60; \
  classtype:attempted-dos; \
  reference:cve,2026-104422; \
  reference:url,nvd.nist.gov/vuln/detail/CVE-2026-104422; \
  sid:2026104422; rev:1; )

Note: the byte pattern shown is an illustrative Zcash/Bitcoin-style magic prefix; operators should tune the content to the Zcash mainnet P2P message framing and to repeated block/getdata request-response pairs from a single peer. Hash-level matching on real deployments should key on ping-pong correlation between one peer and repeated dropped-block events rather than a single fixed byte string.

Elastic Detection

sequence by process.pid with maxspan=10m
  [ network where network.transport == "tcp" and destination.port == 8233
      and event.action == "peer_connected" and source.address != null ]
  [ log where event.dataset == "zebra.block" and event.outcome == "dropped"
      and zebra.block.drop_reason like "~*behind tip*"
      and zebra.block.coinbase_claimed_height <= 1 ]
  [ log where event.dataset == "zebra.peer" and event.action == "no_penalty"
      and zebra.peer.ban_score == 0 ]

This EQL correlates a peer connection, a pre-consensus height-based drop, and the absence of any ban-score increment on the same peer — the three-step fingerprint of CVE-2026-104422. Operators must map field names to their actual log schema.

Splunk SPL Query

index=zebra sourcetype="zebrad:node"
(event="sync_block_dropped" OR event="sync_block_rejected")
| where lower(reason) LIKE "%behind tip%" OR origin="coinbase_scriptSig"
| where coinbase_claimed_height <= 1
| stats count AS drops, values(block_hash) AS hashes, dc(block_hash) AS unique_hashes, max(tip_height) AS tip BY peer_addr
| where drops >= 5 AND (unique_hashes <= 1 OR (tip - coinbase_claimed_height) > 100)
| sort - drops
| table peer_addr, drops, unique_hashes, tip

Looks for a single peer producing repeated pre-consensus drops of a small set of hashes with an implausibly low claimed height — consistent with one peer withholding forward progress.

Wazuh OSSEC Rule

<group name="zebra,cve-2026-104422,">
  <rule id="104422" level="10">
    <decoded_as>json</decoded_as>
    <field name="event">sync_block_dropped</field>
    <field name="coinbase_claimed_height">1</field>
    <description>CVE-2026-104422: Zebra block dropped pre-consensus with height 1 from unvalidated coinbase scriptSig</description>
    <mitre>
      <id>T1499</id>
    </mitre>
    <group>dos,cve_2026_104422,</group>
  </rule>

  <rule id="1044221" level="12" frequency="5" timeframe="60">
    <if_matched_sid>104422</if_matched_sid>
    <same_field>peer_addr</same_field>
    <description>CVE-2026-104422: repeat sync drop from same peer without penalization (possible sync-stall attack)</description>
    <group>dos,cve_2026_104422,</group>
  </rule>
</group>

Requires Zebra node logs to be shipped in JSON with event, coinbase_claimed_height, and peer_addr fields; adjust decoder to your pipeline.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence from any tracked source, no vendor fix URL, no workaround documented, and no affected-version enumeration beyond the description's "before 6.3.0" boundary.

1. Immediate mitigations (no patch available).

   • Restrict peer exposure: allow only trusted peers/allowlisted peers; disable inbound P2P if the node does not need it, or front it with a connection broker you control.
   • Increase the diversity of peer connections and enable/prefer DNS-seed and configured trusted peers so a single malicious peer cannot dominate block delivery.
   • Monitor for the CVE-2026-104422 signatures above and drop the offending peer manually at the firewall or connection layer when detected.
   • Operate a second, independent node (different implementation or isolated from untrusted peers) and cross-check chain-tip state; alarm on tip divergence.
   • Where operationally acceptable, run the node behind an outbound-only connection model.

2. Patch / upgrade steps.

   • The fixed boundary per the NVD description is Zebra 6.3.0. Upgrade any affected zebrad deployment to 6.3.0 or later as soon as a verified release is available from the Zebra upstream project.
   • No vendor advisory or commit is present in tracked sources; verify the 6.3.0 release notes and changelog directly from the upstream repository before relying solely on the version number.
   • Validate the upgrade by confirming the node no longer gates block acceptance on unvalidated coinbase scriptSig height and that peers failing the check accrue ban/discard penalties.

3. Long-term hardening.

   • Treat all peer-supplied metadata as untrusted until consensus validation; never let pre-consensus heuristics make trust decisions on malleable fields.
   • Audit sync code for other pre-validation decisions that consume attacker-controllable inputs (coinbase fields, non-commitment data, message headers).
   • Implement and enforce peer penalization/ban scoring for repeated policy-violating block delivery.
   • Add regression tests covering txid-malleable coinbase mutations that preserve block hash.
   • Track the upstream Zebra security advisories and subscribe to Zcash network security announcements for a definitive fix notice, given the current 0/4 patch-confidence status.

References

• NVD — CVE-2026-104422: https://nvd.nist.gov/vuln/detail/CVE-2026-104422
• MITRE CWE-345 — Insufficient Verification of Data Authenticity: https://cwe.mitre.org/data/definitions/345.html
• MITRE ATT&CK T1499 — Endpoint Denial of Service: https://attack.mitre.org/techniques/T1499/
• Zebra (zebrad) upstream project / releases (verify 6.3.0 advisory and changelog): https://github.com/ZcashFoundation/zebra
• Zcash protocol / transaction ID (ZIP-244, ZIP-225) specification context for V5 transaction IDs excluding scriptSig: https://zips.z.cash/zip-0244

Campaign/exploit status: No CISA KEV listing. No public PoC, no Nuclei template, and no exploit code observed in tracked sources. No threat-actor campaign or in-the-wild exploitation evidence is available as of this report; exploitability is assessed as theoretical but low-effort for any peer-level adversary given the unauthenticated, low-complexity attack profile.