CVE-2026-40881

CVE-2026-40881 is a medium-severity allocation of resources without limits or throttling vulnerability in zebrad (rust), affecting versions < 4.3.1. It is fixed in 4.3.1, 5.0.1.

Summary

CVE-2026-40881: addr/addrv2 Deserialization Resource Exhaustion

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 read_addr/addrv2 functions in codec.rs. It deserializes a vector of addresses with the zcash_deserialize() trait method, which uses as a upper bound the result of T::max_allocation(). For theses types, it was derived from dividing the max message size (2 MiB) by the minimum serialized size of one entry. For AddrV1: 2_097_152 / 30 = 69,904. For AddrV2: 2_097_152 / 9 = 233,016. Only after deserialization was the MAX_ADDRS_IN_MESSAGE = 1000 limit checked.

An attacker could exploit this by:

  1. Creating addr or addrv2 messages with a large number of entries.
  2. Submitting them to a Zebra node, possibly through multiple connections, to attempt to get Zebra into an out-of-memory state.

Fixed Versions

This issue is fixed in Zebra 4.3.1.

The fix changes the max_allocation() method for the relevant types to return 1,000, thus blocking larger values prior to deserialization.

Mitigation

Users should upgrade to Zebra 4.3.1 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains not vulnerable to the denial of service attack.

Credits

Thanks @Zk-nd3r for finding and reporting the issue, and suggesting the fix.

Impact

Denial of Service

  • Attack Vector: Network.
  • Effect: Zebra node crash.
  • Scope: Any impacted Zebra node.

The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.

Affected versions

zebrad (< 4.3.1) zebra-network (< 5.0.1)

Security releases

zebrad → 4.3.1 (rust) zebra-network → 5.0.1 (rust)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

See it in your environment

Remediation advice

Upgrade the following packages to resolve this vulnerability:

zebrad to 4.3.1 or later; zebra-network to 5.0.1 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-40881? CVE-2026-40881 is a medium-severity allocation of resources without limits or throttling vulnerability in zebrad (rust), affecting versions < 4.3.1. It is fixed in 4.3.1, 5.0.1. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
  2. Which packages are affected by CVE-2026-40881?
    • zebrad (rust) (versions < 4.3.1)
    • zebra-network (rust) (versions < 5.0.1)
  3. Is there a fix for CVE-2026-40881? Yes. CVE-2026-40881 is fixed in 4.3.1, 5.0.1. Upgrade to this version or later.
  4. Is CVE-2026-40881 exploitable, and should I be worried? Whether CVE-2026-40881 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether CVE-2026-40881 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix CVE-2026-40881?
    • Upgrade zebrad to 4.3.1 or later
    • Upgrade zebra-network to 5.0.1 or later

Other vulnerabilities in zebrad

CVE-2026-52829CVE-2026-52734CVE-2026-52733CVE-2026-52739CVE-2026-52738

Stop the waste.
Protect your environment with Kodem.