Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
| Source | ID | Title |
|---|---|---|
EUVD |
EUVD-2025-0216 | 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't check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X > 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. |
Github GHSA |
GHSA-22qq-3xwm-r5x4 | CometBFT allows a malicious peer to make node stuck in blocksync |
Mon, 14 Jul 2025 13:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
epss
|
epss
|
Tue, 04 Feb 2025 20:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Mon, 03 Feb 2025 21:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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't check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X > 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. | |
| Title | Malicious peer can make node stuck in blocksync in github.com/cometbft/cometbft | |
| Weaknesses | CWE-703 | |
| References |
| |
| Metrics |
cvssV4_0
|
Status: PUBLISHED
Assigner: GitHub_M
Published:
Updated: 2025-02-04T19:16:21.174Z
Reserved: 2025-01-20T15:18:26.991Z
Link: CVE-2025-24371
Updated: 2025-02-04T19:16:10.482Z
Status : Deferred
Published: 2025-02-03T22:15:28.460
Modified: 2026-04-15T00:35:42.020
Link: CVE-2025-24371
No data.
OpenCVE Enrichment
Updated: 2025-07-13T11:07:12Z
EUVD
Github GHSA