Skip to content

CVE-2026-41583/CVE-2026-41584 - Zebra consensus split and rk panic

Zebra, the Rust implementation of a Zcash node, published two critical GitHub-reviewed advisories that share the same operational fix: upgrade the node runtime immediately and verify it is following the expected consensus chain.

CVE-2026-41583 covers transparent sighash hash-type handling. A refactor moved consensus-critical validation out of C++ verification code, but Zebra did not re-enforce the rule that restricts valid V5 transaction sighash hash types. For V4 transactions, Zebra also used the canonical hash type while zcashd used the raw value. A malicious transaction could therefore be accepted by Zebra and rejected by zcashd, or vice versa, risking a consensus split.

CVE-2026-41584 covers an Orchard transaction verification panic. A crafted transaction with an identity rk value could cause the orchard crate path used by Zebra verification to panic, crashing affected Zebra nodes.

Affected versions

  • CVE-2026-41583 vulnerable: zebrad <4.3.1
  • CVE-2026-41583 vulnerable library: zebra-script <5.0.1
  • CVE-2026-41583 fixed: zebrad 4.3.1+ and zebra-script 5.0.1+
  • CVE-2026-41584 vulnerable: zebrad <4.3.1
  • CVE-2026-41584 vulnerable library: zebra-chain <6.0.2
  • CVE-2026-41584 fixed: zebrad 4.3.1+ and zebra-chain 6.0.2+

Indicator-of-exposure

  • The repository builds, vendors, packages, deploys, or documents zebrad before 4.3.1.
  • The repository includes zebra-script <5.0.1 or zebra-chain <6.0.2 in a custom Zcash transaction verification, block validation, wallet, indexer, or node-adjacent service.
  • A Zebra node is connected to public, partner, testnet, or mining networks where untrusted transactions or blocks can reach verification.
  • Deployment manifests pin Zebra images or binaries without immutable digests or an explicit fixed version.
  • Operators rely on Zebra for consensus-critical block acceptance, transaction verification, mining, indexing, or chain-observation signals.

Quick checks:

rg -n "zebrad|zebra-script|zebra-chain|ZcashFoundation/zebra|zcash|orchard|sighash|Cargo\\.lock|cargo" .
cargo tree -i zebrad
cargo tree -i zebra-script
cargo tree -i zebra-chain
rg -n "zebrad|zebra|zcash|ZCASH|mainnet|testnet|regtest" Dockerfile* docker-compose*.yml charts deploy k8s helm systemd .github .

Remediation strategy

  • Upgrade every controlled Zebra node runtime to zebrad 4.3.1+.
  • Ensure library consumers resolve zebra-script 5.0.1+ and zebra-chain 6.0.2+.
  • Regenerate Cargo locks, vendored dependency metadata, SBOMs, image digests, deployment render output, and runtime version documentation.
  • Treat this as a consensus-critical rollout. Drain, restart, or replace affected nodes according to the operator’s Zcash runbook, then verify chain height, best block hash, peer health, and crash-loop status against trusted patched peers.
  • Do not attempt to mitigate a network-reachable consensus node with network filtering alone. The advisories state immediate upgrade is the available mitigation.
  • If the repository only manages downstream services that read from Zebra, document the node owner, exposed runtime, and required upgrade in TRIAGE.md instead of pretending a client-only patch remediates the CVEs.

The prompt 

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-41583 and CVE-2026-41584 in Zebra/Zcash node
deployments and Zebra Rust library consumers. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Zebra, proves affected
  runtimes and libraries resolve to fixed versions, adds rollout-safe
  verification, and documents operator actions, or
- TRIAGE.md if this repository does not own an affected Zebra runtime/library
  or cannot make a safe change.

## Rules

- Scope only CVE-2026-41583, CVE-2026-41584,
  GHSA-8m29-fpq5-89jj, and GHSA-452v-w3gx-72wg.
- Do not generate invalid Zcash transactions, crafted `rk` values, forked-chain
  payloads, consensus-split test cases, or crash payloads against production,
  staging, shared dev, public testnet, or shared mining infrastructure.
- Do not delete chain state, resync nodes, rotate wallets, alter mining
  policy, or change peer allowlists unless the repository already owns those
  runbook actions and the PR makes the operator impact explicit.
- Do not rely on network isolation as a substitute for upgrading a node that
  can process untrusted transactions or blocks.
- Do not auto-merge.

## Steps

1. Inventory every Zebra/Zcash asset controlled by this repository:
   Cargo manifests, Cargo.lock files, vendored crates, Dockerfiles, base
   images, compose files, Helm charts, Kubernetes manifests, Terraform,
   Ansible, systemd units, CI images, SBOMs, release manifests, runbooks,
   node configuration, and runtime version probes.
2. Determine every resolved version:
   - `zebrad` is vulnerable if it resolves below `4.3.1`;
   - `zebra-script` is vulnerable if it resolves below `5.0.1`;
   - `zebra-chain` is vulnerable if it resolves below `6.0.2`.
3. Determine exposure without exploit testing:
   - Is `zebrad` connected to public, partner, mining, testnet, or regtest
     peers that can supply untrusted transactions or blocks?
   - Does the service use Zebra libraries for transaction, block, mempool,
     wallet, indexer, or chain-observation decisions?
   - Are node health, block acceptance, or mining decisions consumed by other
     production systems?
4. If this repository does not own an affected runtime or library consumer,
   stop with `TRIAGE.md` listing files checked, resolved versions, suspected
   owner, and the exact upgrade requested.
5. Upgrade controlled nodes and libraries:
   - move `zebrad` to `4.3.1+`;
   - move `zebra-script` to `5.0.1+`;
   - move `zebra-chain` to `6.0.2+`;
   - update image tags to fixed immutable digests where possible;
   - regenerate Cargo locks, vendor metadata, SBOMs, image metadata, and
     rendered deployment manifests.
6. Add a dependency guard or deployment policy check that rejects the vulnerable
   Zebra versions in future builds. Keep it narrow to Zebra/Zcash artifacts.
7. Add safe verification that does not exercise the vulnerability:
   - dependency-resolution assertions for the fixed crate versions;
   - image or binary version checks such as `zebrad --version` where available;
   - deployment render tests proving fixed image tags or digests are used;
   - runbook checks for patched node startup, peer health, chain height, best
     block hash, and crash-loop status after rollout.
8. Add temporary rollout containment when deployment is not atomic:
   - remove vulnerable nodes from load-bearing consensus/mining/indexing roles;
   - prefer patched peers for validation during the rollout;
   - flag downstream services that consume Zebra consensus signals as degraded
     until patched nodes are healthy;
   - document any operator-approved resync or state-rebuild requirement.
9. Add a PR body section named `Zebra CVE operator actions` that states:
   - every Zebra binary, crate, image, and deployment target before and after
     the change;
   - whether affected nodes were public-peer, partner-peer, mining, indexer,
     wallet, testnet, or internal-only;
   - whether any downstream service consumes Zebra consensus or chain-state
     output;
   - expected restart, drain, resync, peer-health, and chain-tip verification
     steps;
   - logs to inspect for consensus mismatch, invalid transaction handling,
     Orchard verification panic, or crash loops;
   - any temporary degraded mode that remains after the PR.
10. Run relevant validation: Cargo resolution, unit tests, dependency/security
    scan, SBOM refresh, image build, deployment render, policy checks, and
    safe node startup/version checks available in this repository.
11. Use PR title:
    `fix(sec): remediate Zebra CVE-2026-41583 and CVE-2026-41584`.

## Stop conditions

- No affected Zebra node, crate, image, or deployment target is controlled by
  this repository.
- A fixed Zebra release cannot be consumed without a broader chain-node or
  protocol migration.
- The only available verification would require crafting invalid transactions,
  inducing a consensus split, or crashing a node.
- The change would delete chain state, alter mining behavior, or trigger a
  resync without operator approval.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled Cargo lock, vendored crate, image, SBOM, or deployment target resolves zebrad <4.3.1, zebra-script <5.0.1, or zebra-chain <6.0.2.
  • Deployment artifacts use fixed Zebra image tags or immutable digests and do not leave old binaries in sidecars, init containers, base images, or release bundles.
  • Verification is safe: dependency resolution, version probes, deployment rendering, patched startup, peer health, chain height, best block hash, and crash-loop checks.
  • Operator actions explain consensus-risk rollout steps and downstream services that consume Zebra output.
  • The PR does not include exploit transactions, crafted rk values, or consensus-split reproduction payloads.

Watch for

  • Updating zebrad while a container layer, vendored crate directory, or release bundle still contains old Zebra binaries or libraries.
  • Treating zebra-script or zebra-chain library consumers as safe because they do not run the full zebrad binary.
  • Checking only Cargo.toml and missing Cargo.lock, vendored sources, image digests, or Helm values.
  • Restarting a patched node without checking that it rejoins the expected chain tip and stops crash-looping.
  • Hiding operator actions such as drain, restart, resync, degraded mode, or downstream-consumer impact.

References