{"schema_version":"1.9.0","id":"CVE-2025-24371","published":"2025-02-03T21:20:56.024Z","modified":"2026-08-12T03:51:31.043587297Z","aliases":["GHSA-22qq-3xwm-r5x4","GO-2025-3442"],"related":["SUSE-SU-2025:0429-1","openSUSE-SU-2025:14732-1"],"summary":"Malicious peer can make node stuck in blocksync in github.com/cometbft/cometbft","details":"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":[{"ranges":[{"type":"GIT","repo":"https://github.com/cometbft/cometbft","events":[{"introduced":"0"},{"introduced":"ce344cc66cb2a9c5e8bb934cf1fa297a442c8b07"},{"fixed":"d03254d3599b973f979314e6383b89fa1802e679"},{"fixed":"d22299509a50140b74d81b113c4d78e4cf501994"}],"database_specific":{"extracted_events":[{"introduced":"0"},{"fixed":"0.38.17"},{"introduced":"= 1.0.0"},{"last_affected":"= 1.0.0"}],"source":["AFFECTED_FIELD","REFERENCES"]}}],"versions":["= 1.0.0","v0.38.16","v1.0.0","v0.38.15","v0.38.14","v0.38.13","v0.38.12","v0.38.11","v0.38.10","v0.38.9","v0.38.8","v0.38.7","v0.38.6","v0.38.5","v0.38.4","v0.38.3","v0.38.2","v0.38.1","v0.38.0","v0.38.0-rc3","v0.38.0-rc2","v0.38.0-rc1","v0.38.0-alpha.2","v0.38.0-alpha.1"],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-24371.json"}}],"references":[{"type":"WEB","url":"https://github.com/cometbft/cometbft/releases/tag/v0.38.17"},{"type":"WEB","url":"https://github.com/cometbft/cometbft/releases/tag/v1.0.1"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/24xxx/CVE-2025-24371.json"},{"type":"ADVISORY","url":"https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-24371"}],"database_specific":{"cna_assigner":"GitHub_M","cwe_ids":["CWE-703"],"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/24xxx/CVE-2025-24371.json"},"severity":[{"type":"CVSS_V4","score":"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"}]}