{"id":"CVE-2025-24371","state":"PUBLISHED","title":"Malicious peer can make node stuck in blocksync in github.com/cometbft/cometbft","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.","publishedAt":"2025-02-03T21:20:56.024Z","updatedAt":"2025-02-04T19:16:21.174Z","severity":{"score":7.1,"label":"High","version":"4.0","vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","source":"GitHub_M"},"assigner":"GitHub_M","products":["cometbft cometbft"],"affected":[{"vendor":"cometbft","product":"cometbft","versions":[{"version":"< 0.38.17","status":"affected"},{"version":"= 1.0.0","status":"affected"}]}],"references":["https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4","https://github.com/cometbft/cometbft/releases/tag/v0.38.17","https://github.com/cometbft/cometbft/releases/tag/v1.0.1"],"weaknesses":["CWE-703"],"ingestedAt":"2026-10-29T20:08:47.682Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2025/24xxx/CVE-2025-24371.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.1","cveMetadata":{"cveId":"CVE-2025-24371","state":"PUBLISHED","datePublished":"2025-02-03T21:20:56.024Z","dateUpdated":"2025-02-04T19:16:21.174Z","assignerShortName":"GitHub_M","assignerOrgId":"a0819718-46f1-4df5-94e2-005712e83aaa","dateReserved":"2025-01-20T15:18:26.991Z"},"containers":{"cna":{"title":"Malicious peer can make node stuck in blocksync in github.com/cometbft/cometbft","descriptions":[{"lang":"en","value":"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."}],"affected":[{"vendor":"cometbft","product":"cometbft","versions":[{"version":"< 0.38.17","status":"affected"},{"version":"= 1.0.0","status":"affected"}]}],"references":[{"url":"https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4","name":"https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4","tags":["x_refsource_CONFIRM"]},{"url":"https://github.com/cometbft/cometbft/releases/tag/v0.38.17","name":"https://github.com/cometbft/cometbft/releases/tag/v0.38.17","tags":["x_refsource_MISC"]},{"url":"https://github.com/cometbft/cometbft/releases/tag/v1.0.1","name":"https://github.com/cometbft/cometbft/releases/tag/v1.0.1","tags":["x_refsource_MISC"]}],"metrics":[{"cvssV4_0":{"attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"LOW","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","baseScore":7.1,"baseSeverity":"HIGH","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","version":"4.0"}}],"problemTypes":[{"descriptions":[{"cweId":"CWE-703","lang":"en","description":"CWE-703: Improper Check or Handling of Exceptional Conditions","type":"CWE"}]}],"providerMetadata":{"shortName":"GitHub_M","orgId":"a0819718-46f1-4df5-94e2-005712e83aaa","dateUpdated":"2025-02-03T21:20:56.024Z"},"source":{"advisory":"GHSA-22qq-3xwm-r5x4","discovery":"UNKNOWN"}},"adp":[{"title":"CISA ADP Vulnrichment","metrics":[{"other":{"type":"ssvc","content":{"timestamp":"2025-02-04T19:15:05.677855Z","id":"CVE-2025-24371","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}}],"providerMetadata":{"shortName":"CISA-ADP","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","dateUpdated":"2025-02-04T19:16:21.174Z"}}]}}}