Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
27 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A soundness vulnerability in the variable-base scalar multiplication gadget of halo2gadgets allowed a malicious prover to produce a valid proof for an Orchard Action with an under-constrained base point. Because this gadget enforces the diversified-address-integrity condition of the Orchard Action statement, the flaw let a prover satisfy that condition for an arbitrary (pk<subd</sub, g<subd</sub, ivk) triple, effectively bypassing the check that binds an Action to the correct incoming viewing key — and therefore to the correct nullifier (nf) and spend validating key (ak) — of the note being spent. The main practical consequence is that an adversary could have performed a double-spend within the Orchard pool, resulting in a balance violation: the same note could be spent multiple times, each time revealing a distinct, valid-looking nullifier. The total ZEC supply was protected by Zcash's turnstile mechanism, which bounds value flowing out of any pool, so unbounded inflation of…
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node listens on the default [::] address on a Linux host (the standard deployment configuration — net.ipv6.bindv6only=0 is the default on all common Linux distributions). 3. Your node is synced near the chain tip (the expected production state for any node participating in the network). Summary An address normalization mismatch between the handshake path and the mempool misbehavior path causes a deterministic assertion panic when a peer connects via IPv4 to a dual-stack IPv6 listener and then triggers a mempool misbehavior penalty. The handshake path canonicalizes IPv4-mapped IPv6 addresses to plain IPv4 when storing the peer in the address book via MetaAddr::newconnected. The mempool misbehavior path forwards the raw transient socket address (IPv4-mapped IPv6 form) when sending MetaAddrChange::UpdateMisbehavior to the address book. The address book looks up the canonical IPv4 entry but then…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node accepts inbound P2P connections (network.listenaddr is set, which is the default). 3. Your node's mempool is active (node is synced near the chain tip). All default configurations are affected. Summary The mempool download pipeline's cancelhandles map retains entries for transactions whose verification times out at the outer RATELIMITDELAY (73-second) boundary. The tokio::time::error::Elapsed error carries no payload, so the transaction ID is unrecoverable and the corresponding cancelhandles entry (including the full Gossip::Tx(UnminedTx), up to ~2 MB) is never removed. Entries accumulate monotonically with no upper bound or garbage collection, leading to eventual out-of-memory process termination. Details Downloads::pollnext() at zebrad/src/components/mempool/downloads.rs:215-228 handles three terminal states for a verification task: - Ok(Ok(...)): success. Calls…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node participates in a network where chain forks occur (mainnet, testnet, or any network with multiple miners). All default configurations are affected. The corruption persists across restarts because it is written to RocksDB. Summary When poptip removes the tip block during a chain fork, stale Sapling and Orchard note commitment subtree root data is retained in the in-memory non-finalized state. When the chain subsequently finalizes, this stale data is written to the persistent RocksDB state. The corrupted subtree root history affects zgetsubtreesbyindex (used by lightwalletd for wallet synchronization) and could affect future chain verification that depends on correct subtree roots. Details The non-finalized state provides two methods for removing blocks: poproot (removes the oldest block during finalization) and poptip (removes the newest block during a fork revert). poproot correctly cleans…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node processes blocks past the checkpoint height (non-finalized state is active). 3. The network has NU5 or later activated. All default configurations are affected. Summary Chain::push in the non-finalized state updates the transaction-location index (txlocbyhash) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the asserteq!(priorpair, None, "transactions must be unique within a single chain") fires before the contextual validation that would cleanly reject the duplicate. Under Zebra's panic = "abort" release profile, this terminates the entire node process. The block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within Chain::push causes the process to abort. Details In zebra-state/src/service/nonfinalizedstate/chain.rs:1608-1628,…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node processes blocks on any Zcash network. Summary The finalized transparent address balance writer processes all newly-created outputs (credits) before processing spent outputs (debits) within the same block. A consensus-valid block containing a long chain of same-address transparent self-spends can cause the intermediate per-address balance during the credit pass to exceed MAXMONEY, triggering a panic in the finalized state writer. Because the triggering block is consensus-valid (zcashd accepts it), the panic recurs on restart when the node re-encounters the same block. This creates a persistent chain halt that can only be resolved by a software patch. Details The finalized state writer at zebra-state/src/service/finalizedstate/zebradb/transparent.rs iterates all transaction outputs in a block and credits them to per-address balances before iterating inputs and debiting spent outputs. When a…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node accepts inbound P2P connections and is syncing or catching up to the chain tip. Summary A malicious peer can answer Zebra's outbound getblocks/FindBlocks request with a small two-hash inventory, then serve a syntactically valid block whose coinbase height is far above the victim's local tip. The AboveLookaheadHeightLimit error in the sync download pipeline triggers a global sync restart rather than being scoped to the offending peer. The peer is never scored or disconnected because the error type does not carry the advertiser address. On mainnet, each successful cycle imposes a 67-second sync restart delay. All in-flight downloads from honest peers are cancelled on each restart. Details The bug is the interaction of three layers: 1. The syncer promotes unvalidated FindBlocks peer responses into concrete download schedules without checking that the advertised hashes are plausible chain…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 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. All default configurations are affected. No feature flags, non-default settings, or special build options are required. Summary Zebra's P2SH sigop counter uses a pure-Rust code path that short-circuits on disabled opcodes (such as OPCODESEPARATOR), 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 MAXBLOCKSIGOPS = 20,000 threshold is crossed on one side but not the other. An attacker can exploit this without mining capability. Broadcasting transactions that spend P2SH outputs with malicious redeem scripts is sufficient; any Zebra miner who…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run any version of zebrad up to and including v4.4.1. 2. Your node accepts inbound P2P connections (network.listenaddr is set, which is the default). 3. Your node processes blocks past the checkpoint height (non-finalized state is active). All default configurations are affected. Summary Zebra records a block hash in nonfinalizedblockwritesenthashes when the block is sent to the write task, before contextual validation completes. If validation fails, the hash is not removed. A remote unauthenticated peer can deliver a poisoned block body that shares a header hash with a later valid canonical block. The poisoned body is rejected, but the hash remains cached. When the valid canonical block arrives, Zebra treats it as a duplicate and rejects it. The node cannot advance past that height until restart or a reorg event. Details ZIP-244 defines txidv5 without binding transparent input scriptSig, which lives in authdigest and is committed…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node accepts inbound P2P connections (network.listenaddr is set, which is the default). Summary The P2P codec's Codec::decode() method calls src.reserve(bodylen + HEADERLEN) after parsing a 24-byte protocol header, using the attacker-claimed bodylen field. This reserves up to MAXPROTOCOLMESSAGELEN (~2 MiB) of virtual buffer capacity per connection before any body bytes arrive and before the handshake completes. However, BytesMut::reserve() sets virtual capacity without committing physical memory pages. The operating system does not allocate physical RAM until bytes are actually written into the buffer. Since the attacker never sends body bytes, the reserved capacity remains uncommitted. Reproduction of the reporter's PoC (256 threads, 30 seconds of sustained connections) showed negligible RSS impact on the Zebra process. Zebra's existing mitigations further constrain the practical attack surface:…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node accepts inbound P2P connections (network.listenaddr is set, which is the default). 3. Your node's mempool is active (node is synced near the chain tip). All default configurations are affected. Summary A single unauthenticated P2P peer can monopolize all 25 inbound mempool download/verification slots (MAXINBOUNDCONCURRENCY) by advertising fake transaction IDs. While the slots are occupied, all other inbound transactions from honest peers and local RPC sendrawtransaction calls are rejected with MempoolError::FullQueue. The attacker peer is never scored for misbehavior and is not disconnected, allowing sustained denial of mempool admission. Details The mempool download/verification pipeline at zebrad/src/components/mempool/downloads.rs uses a single bounded pool of 25 concurrent tasks. Three architectural gaps combine to produce the vulnerability: 1. No per-peer accounting: the 25 slots are…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your zebrad.toml sets rpc.listenaddr to a TCP address (RPC server is enabled). 3. An attacker can authenticate to the RPC endpoint. With the default enablecookieauth = true, this requires the attacker to read the .cookie file (typically local access). With enablecookieauth = false, any network client reaching the RPC port can trigger it. Summary The zlistunifiedreceivers RPC handler panics when processing a structurally valid Unified Address whose Sapling receiver carries 43 bytes that fail cryptographic validation (saplingcrypto::PaymentAddress::frombytes returns None for non-subgroup Jubjub points). The handler calls .expect("using data already decoded as valid") on the fallible result. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process, not just the RPC task. Details zcashaddress::unified::Encoding::decode validates only the structural envelope of a…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node accepts inbound P2P connections. Summary The readgetblocks and readgetheaders codec paths accepted block locator vectors up to approximately 65,535 entries (the generic TrustedPreallocate ceiling derived from MAXPROTOCOLMESSAGELEN), rather than the protocol-specification limit of 101 entries (matching zcashd's MAXLOCATORSZ). Each entry in the locator vector triggers a per-hash chain lookup (HashMap::containskey + RocksDB::containshash) in findchainintersection on a tokio blocking-pool thread. A single maximally-sized getblocks message occupies one blocking-pool thread for approximately 10–65ms. Under sustained load from multiple peers, this can degrade state-read performance for block validation, RPC, and mempool lookups. Details The readheaders codec path already implements the correct pattern: it reads the CompactSize count, validates against MAXHEADERSPERMESSAGE = 160 before…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your zebrad.toml sets rpc.listenaddr to a TCP address (RPC server is enabled). 3. An attacker can authenticate to the RPC endpoint. With the default enablecookieauth = true, this requires the attacker to read the .cookie file. With enablecookieauth = false, any network client reaching the RPC port can trigger it. Summary The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process. Details The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A composite denial-of-service vulnerability in Zebra's block discovery pipeline allows an unauthenticated remote attacker to permanently halt all new block discovery on a targeted node. The attack exploits three independent weaknesses in the gossip, syncer, and download subsystems — all exercisable from a single TCP connection — to create a monotonically growing block deficit that never self-heals. Severity Critical — This is a Denial of Service vulnerability that requires no authentication, no special privileges, and only a single peer connection. The halt is permanent: the node will never recover without operator intervention. Affected Versions All Zebra versions prior to 4.4.0. Description Zebra discovers new blocks through two complementary paths: a gossip path (peers announce blocks via inv messages, triggering individual block downloads) and a syncer path (Zebra periodically queries peers with FindBlocks/FindHeaders to discover chains of missing blocks). Both paths must…
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Consensus Divergence in V5 Transparent SIGHASHSINGLE With No Corresponding Output Summary Zebra failed to enforce a ZIP-244 consensus rule for V5 transparent transactions: when an input is signed with SIGHASHSINGLE and there is no transparent output at the same index as that input, validation must fail. Zebra instead asked the underlying sighash library to compute a digest, and that library produced a digest over an empty output set rather than failing. An attacker could craft a V5 transaction with more transparent inputs than outputs that Zebra accepts but zcashd rejects, creating a consensus split between Zebra and zcashd nodes. A previous fix (GHSA-cwfq-rfcr-8hmp) addressed a closely related case in the same area of the code, but did not cover this specific one. Severity 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. Note that the impact…
Recommended action: Upgrade to 4.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Zebra Transparent SIGHASHSINGLE Corresponding-Output Handling Diverges From zcashd Summary For V5+ transparent spends, Zebra and zcashd disagree on the same consensus rule: SIGHASHSINGLE must fail when the input index has no corresponding output. zcashd treats this as consensus-invalid under ZIP-244, while Zebra's transparent verification path computes a digest for the missing-output case instead of failing. The result is a direct block-validity split. A malformed V5 transparent transaction can be accepted by Zebra, retained in Zebra's mempool, selected into Zebra getblocktemplate, mined into a block, and then rejected by zcashd. Details Validated code revisions used during analysis: - zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5 - Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb Scope note: - earlier triage material grouped pre-V5 and V5 behavior together; - re-execution on the pinned revisions did not reproduce the claimed pre-V5 / V4 reject-side behavior; - this advisory…
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CVE-2026-44497: Consensus Divergence in Transparent Sighash Hash-Type Handling due to Stale Buffer Summary 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. Severity 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. Note that the impact is currently alleviated by the fact that currently most miners run zcashd. Affected Versions Zebra 4.3.1.…
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CVE-2026-44500: Allocation Amplification in Inbound Network Deserializers Summary Several inbound deserialization paths in Zebra allocated buffers sized against generic transport or block-size ceilings before the tighter protocol or consensus limits were enforced. An unauthenticated or post-handshake peer could therefore force the node to preallocate and parse for orders of magnitude more data than the protocol intended, across headers messages, equihash solutions in block headers, Sapling spend vectors in V5/V4 transactions, and coinbase script bytes in blocks. Severity Moderate - This is a Denial-of-Service Vulnerability that could allow a malicious peer to amplify per-message memory and parse cost on Zebra nodes, with effects amplified by multi-peer fan-in. Each individual case is bounded by the 2 MiB transport ceiling or the block-size cap, so no single message causes unbounded allocation, but the cumulative gap between intended and actual limits is significant. Affected Versions…
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (MAXBLOCKSIGOPS), allowing it to accept blocks that zcashd rejects with bad-blk-sigops. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while zcashd nodes do not. Two distinct undercounts: A: Coinbase Hidden Legacy Sigops zcashd's GetLegacySigOpCount() includes the coinbase input's scriptSig. Zebra's Sigops impl skipped the coinbase input entirely, so up to ~98 sigops (the 100-byte coinbase script length cap, less the height prefix) could be hidden inside the coinbase scriptSig without being charged against the block limit. B: Aggregate P2SH Sigops. zcashd's GetP2SHSigOpCount() parses each P2SH input's redeem script with accurate=true and sums those sigops into the block-wide total via ConnectBlock. The check is per-block, not per-transaction, and the limit applies regardless of who mines the offending block — a miner just needs to…
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CVE-2026-41583: Consensus Divergence in Transparent Sighash Hash-Type Handling Summary After a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes. In a similar vein, for V4 transactions, Zebra mistakenly used the "canonical" hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split. Severity 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. Note that the impact is currently alleviated by the fact that currently most miners run zcashd. Affected Versions All Zebra versions prior to…
Recommended action: Upgrade to 4.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response. Severity Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default. Affected Versions - zebrad: versions from 2.2.0 up to (but not including) 4.3.1 - zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2 Description Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The…
Recommended action: Upgrade to 4.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
rk Identity Point Panic in Transaction Verification Summary Orchard transactions contain a rk field which is a randomized validating key and also an elliptic curve point. The Zcash specification allows the field to be the identity (a "zero" value), however, the orchard crate which is used to verify Orchard proofs would panic when fed a rk with the identity value. Thus an attacker could send a crafted transaction that would make a Zebra node crash. Severity Critical - This is a Denial of Service Vulnerability that could allow an attacker to crash Zebra nodes. Affected Versions All Zebra versions prior to version 4.3.1. Description The vulnerability exists in the circuits.rs file of the orchard crate; it attempts to get the coordinates of the rk value and calls unwrap() on the results, which causes a panic if rk is the identity. Zebra parses rk as a byte vector; it creates an Orchard "bundle" using the orchard crate and then calls the same crate to verify it, triggering the panic. An…
Recommended action: Upgrade to 4.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CVE-2026-40881: addr/addrv2 Deserialization Resource Exhaustion Summary When deserializing addr or addrv2 messages, which contain vectors of addresses, Zebra would fully deserialize them up to a maximum length (over 233,000) that was derived from the 2 MiB message size limit. This is much larger than the actual limit of 1,000 messages from the specification. Zebra would eventually check that limit but, at that point, the memory for the larger vector was already allocated. An attacker could cause out-of-memory aborts in Zebra by sending multiple such messages over different connections. Severity Moderate - This is a Denial of Service Vulnerability that could allow an attacker to crash a Zebra node. Affected Versions All Zebra versions prior to version 4.3.1. Description The vulnerability exists in the readaddr/addrv2 functions in codec.rs. It deserializes a vector of addresses with the zcashdeserialize() trait method, which uses as a upper bound the result of T::maxallocation(). For…
Recommended action: Upgrade to 4.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CVE-2026-40880: Cached Mempool Verification Bypasses Consensus Rules for Ahead-of-Tip Blocks Summary A logic error in Zebra's transaction verification cache could allow a malicious miner to induce a consensus split. By carefully submitting a transaction that is valid for height H+1 but invalid for H+2 and then mining that transaction in a block at height H+2, a miner could cause vulnerable Zebra nodes to accept an invalid block, leading to a consensus split from the rest of the Zcash network. Severity High - This is a Consensus Vulnerability that could allow a malicious miner to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes. Affected Versions All Zebra versions prior to version 4.3.1. (Some older versions are not affected but are no longer supported by the network) Description The vulnerability exists due to a performance optimization whose goal is to improve performance of transaction validation if the transaction was…
Recommended action: Upgrade to 4.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.