<?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-10T09:32:04.090145+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-355203</id>
    <title>EUVD-2026-355203</title>
    <updated>2026-10-10T09:32:04.139968+00:00</updated>
    <content>EUVD-2026-355203</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-355203"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-52737</id>
    <title>fkie_cve-2026-52737</title>
    <updated>2026-10-10T09:32:04.140047+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, a malicious unauthenticated P2P peer can answer Zebra's outbound getblocks or FindBlocks request with a small two-hash inventory and then serve a syntactically valid block whose coinbase height is far above the local chain tip. In zebrad/src/components/sync/downloads.rs, BlockDownloadVerifyError::AboveLookaheadHeightLimit originally carried only the block height and hash, so handle_block_response could not attribute the failure to the advertising peer. The error then reached the restart-worthy default path in zebrad/src/components/sync.rs, cancelling all in-flight downloads from honest peers and imposing a 67-second sync restart delay on mainnet. Because the peer was neither scored nor disconnected, the peer could repeat the cycle indefinitely with minimal bandwidth and significantly degrade synchronization without corrupting state. This issue is fixed in version 4.5.0.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-52737"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-gvjc-3w7c-92jx</id>
    <title>GHSA-gvjc-3w7c-92jx — Zebra has sync restart poisoning from single unauthenticated peer via above-lookahead block</title>
    <updated>2026-10-10T09:32:04.140084+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: zebra-consensus, 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 and is syncing or catching up to the chain tip.</p>
<p>### Summary</p>
<p>A malicious peer can answer Zebra's outbound `getblocks`/`FindBlocks` request with a small two-hash inventory, then serve a syntactically valid block whose coinbase height is far above the victim's local tip. The `AboveLookaheadHeightLimit` error in the sync download pipeline triggers a global sync restart rather than being scoped to the offending peer. The peer is never scored or disconnected because the error type does not carry the advertiser address.</p>
<p>On mainnet, each successful cycle imposes a 67-second sync restart delay. All in-flight downloads from honest peers are cancelled on each restart.</p>
<p>### Details</p>
<p>The bug is the interaction of three layers:</p>
<p>1. The syncer promotes unvalidated `FindBlocks` peer responses into concrete download schedules without checking that the advertised hashes are plausible chain extensions.</p>
<p>2. When a downloaded block's coinbase height exceeds `tip + VERIFICATION_PIPELINE_DROP_LIMIT`, the sync downloader returns `BlockDownloadVerifyError::AboveLookaheadHeightLimit`. This error variant carries only the block height and hash, not the advertiser peer address.</p>
<p>3. The sync error handler in `handle_block_response` only sends misbehaviour scores for `BlockDownloadVerifyError::Invalid` errors that carry an `advertiser_addr` and have a nonzero `misbehav…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-gvjc-3w7c-92jx"/>
  </entry>
</feed>
