Skip to main content
VulnerabilityPublished

CVE-2026-52734: Zebrad Has Unbounded Memory Leak

Affects zebradSource GCVE Database

0
Compare
Authoritative record:CVE-2026-52734· Medium 5.3

Not known to be exploited · CVSS 5.3 Medium : upgrade to 4.5.0 when convenient.

Data as of 30 Oct 2026, 06:59 UTC

CVSS 3.1 base score
5.3Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.5% chance of exploitation in 30 days – higher than 43% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 4.5.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 18 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Upgrade zebrad to 4.5.0.

Affected software

ProductAffectedFixed in
crates.iozebradAffected
  • <4.5.0
Fixed in
  • 4.5.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

A patch is available that fixes the memory leak by ensuring the transaction ID is preserved on timeout errors and the corresponding cancel_handles entry is removed. Operators should upgrade to zebrad version 4.5.0 or later. There is no configuration-level workaround; restarting the node clears accumulated entries but does not prevent recurrence. Operators running in memory-constrained environments should be aware of potential OOM kills until patched.

Description

ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, an unauthenticated P2P peer can cause the mempool download pipeline to retain transactions after verification reaches the outer RATE_LIMIT_DELAY timeout. In zebrad/src/components/mempool/downloads.rs, Downloads::poll_next removed cancel_handles entries after success and ordinary verification errors, but tokio::time::error::Elapsed did not carry the UnminedTxId needed to remove the timed-out entry. Each retained cancel_handles entry could hold a full Gossip::Tx(UnminedTx), while normal mined-transaction cleanup could not match attacker transactions and no periodic garbage collection or count cap existed. Sustained traffic therefore caused monotonic memory growth until swap pressure degraded the node or the operating system terminated the zebrad process for exhausting memory. This issue is fixed in version 4.5.0.

References

Community reviews

Loading reviews…