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 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 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.
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 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.
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 6.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-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 5.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.