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
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 8.0.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 7.0.0 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 6.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
--- Remote Denial of Service via Crafted V5 Transactions Summary A vulnerability in Zebra's transaction processing logic allows a remote, unauthenticated attacker to cause a Zebra node to panic (crash). This is triggered by sending a specially crafted V5 transaction that passes initial deserialization but fails during transaction ID calculation. Severity Critical - This is a Remote Denial of Service (DoS) that requires no authentication and can be triggered by a single network message. Affected Versions All Zebra versions supporting V5 transactions (Network Upgrade 5 and later) prior to version 4.3.0. Description The vulnerability stems from Zebra lazily validating transaction fields that are eagerly validated in the librustzcash parsing logic used when Zebra computes transaction ids and auth digests for V5 transactions where Zebra panics if those computations fail. PushTransaction messages with malformed V5 transactions are successfully deserialized as the zebra-chain Transaction…
Recommended action: Upgrade to 6.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.