<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 09 Oct 2026 22:00:42 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-24371 — Malicious peer can make node stuck in blocksync in github.com/cometbft/cometbft</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-24371</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; cometbft&lt;/p&gt;
&lt;p&gt;CometBFT is a distributed, Byzantine fault-tolerant, deterministic state machine replication engine. In the `blocksync` protocol peers send their `base` and `latest` heights when they connect to a new node (`A`), which is syncing to the tip of a network. `base` acts as a lower ground and informs `A` that the peer only has blocks starting from height `base`. `latest` height informs `A` about the latest block in a network. Normally, nodes would only report increasing heights. If `B` fails to provide the latest block, `B` is removed and the `latest` height (target height) is recalculated based on other nodes `latest` heights. The existing code however doesn&amp;#39;t check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X &amp;gt; Y`. `A` will be trying to catch up to 2000 indefinitely. This condition requires the introduction of malicious code in the full node first reporting some non-existing `latest` height, then reporting lower `latest` height and nodes which are syncing using `blocksync` protocol. This issue has been patched in versions 1.0.1 and 0.38.17 and all users are advised to upgrade. Operators may attempt to ban malicious peers from the network as a workaround.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; cometbft&lt;/p&gt;
&lt;p&gt;CometBFT is a distributed, Byzantine fault-tolerant, deterministic state machine replication engine. In the `blocksync` protocol peers send their `base` and `latest` heights when they connect to a new node (`A`), which is syncing to the tip of a network. `base` acts as a lower ground and informs `A` that the peer only has blocks starting from height `base`. `latest` height informs `A` about the latest block in a network. Normally, nodes would only report increasing heights. If `B` fails to provide the latest block, `B` is removed and the `latest` height (target height) is recalculated based on other nodes `latest` heights. The existing code however doesn&amp;#39;t check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X &amp;gt; Y`. `A` will be trying to catch up to 2000 indefinitely. This condition requires the introduction of malicious code in the full node first reporting some non-existing `latest` height, then reporting lower `latest` height and nodes which are syncing using `blocksync` protocol. This issue has been patched in versions 1.0.1 and 0.38.17 and all users are advised to upgrade. Operators may attempt to ban malicious peers from the network as a workaround.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-24371</guid>
    </item>
  </channel>
</rss>
