<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-07T16:43:44.188638+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-356490</id>
    <title>EUVD-2026-356490</title>
    <updated>2026-10-07T16:43:44.222465+00:00</updated>
    <content>EUVD-2026-356490</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-356490"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-52734</id>
    <title>fkie_cve-2026-52734</title>
    <updated>2026-10-07T16:43:44.222509+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-52734"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-65jj-fmw8-468q</id>
    <title>GHSA-65jj-fmw8-468q — zebrad has unbounded memory leak in mempool download pipeline via timeout path cancel_handles retention</title>
    <updated>2026-10-07T16:43:44.222549+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: zebrad</p>
<p>### Am I affected</p>
<p>You are affected if:</p>
<p>1. You run `zebrad` up to and including `v4.4.1`.
2. Your node accepts inbound P2P connections (`network.listen_addr` is set, which is the default).
3. Your node's mempool is active (node is synced near the chain tip).</p>
<p>All default configurations are affected.</p>
<p>### Summary</p>
<p>The mempool download pipeline's `cancel_handles` map retains entries for transactions whose verification times out at the outer `RATE_LIMIT_DELAY` (73-second) boundary. The `tokio::time::error::Elapsed` error carries no payload, so the transaction ID is unrecoverable and the corresponding `cancel_handles` 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.</p>
<p>### Details</p>
<p>`Downloads::poll_next()` at `zebrad/src/components/mempool/downloads.rs:215-228` handles three terminal states for a verification task:</p>
<p>- `Ok(Ok(...))`: success. Calls `cancel_handles.remove(&amp;tx.transaction.id)`. Correct.
- `Ok(Err(...))`: verification error. Calls `cancel_handles.remove(&amp;hash)`. Correct.
- `Err(elapsed)`: outer timeout. Returns `Err(elapsed)` without removing anything. **Bug.**</p>
<p>`tokio::time::error::Elapsed` has no payload, so the timed-out transaction's `UnminedTxId` is unrecoverable from the error. The consumer at `zebrad/src/components/mempool.rs:663-672` explicitly acknowledges this gap with a TODO comment.</p>
<p>The only c…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-65jj-fmw8-468q"/>
  </entry>
</feed>
