Components
Vulnerabilities
Pricing
MCP
API
Docs
Sign up
Login
github.com/cometbft/cometbft v0.0.0-202302… | Sonatype Guide
golang
github.com/cometbft/cometbft
v0.0.0-20230203130311-387422ac220d
github.com/cometbft/cometbft v0.0.0-20230203130311-387422ac220d
Published
Feb 3, 2023
•
Policy
compliance
golang Registry
Developer Trust Score
N/A
Recommended Version:
x.y.z
Latest version with 0 known vulnerabilities that meets your policy.
Compare Versions
Overview
Overview
Versions
85
Versions
85
Vulnerabilities
8
Vulnerabilities
8
Dependencies
0
Dependencies
0
Reset filters
Severity
Critical
(0)
High
(7)
Medium
(0)
Low
(0)
CVSS Score
0.0
10.0
EPSS Score
0.0
1.0
Malware
KEV Status
Published
Filter
Sort: Published (Newest first)
7.1
sonatype-2026-000225
github.com/cometbft/cometbft - Improper Check or Handling of Exceptional Conditions
affected
Severity
High
Published
Jan 24, 2026
8.7
sonatype-2025-004228
github.com/cometbft/cometbft - Improper Handling of Syntactically Invalid Structure
affected
Severity
High
Published
Oct 21, 2025
8.7
sonatype-2025-000426
github.com/cometbft/cometbft - Improper Validation of Specified Index, Position, or Offset in Input
affected
Severity
High
Published
Feb 4, 2025
7.1
CVE-2025-24371
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
Severity
High
Published
7.1
sonatype-2024-2332
github.com/cometbft/cometbft - Externally Controlled Reference to a Resource in Another Sphere
affected
Severity
High
Published
Jul 1, 2024
7.5
sonatype-2023-4246
github.com/cometbft/cometbft - Denial of Service (DoS)
affected
Severity
High
Published
Oct 2, 2023
8.2
CVE-2023-34451
CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. The mempool maintains two data structures to keep track of outstanding transactions: a list and a map. These two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list. In `v0.37.0`, and `v0.37.1`, as well as in `v0.34.28`, and all previous releases of the CometBFT repo2, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction. Because the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list. This happens even if the duplicated transaction is later committed in a block. The only way to remove the transaction is by restarting the node. The above problem can be repeated on and on until a sizable number of transactions are stuck in the mempool, in order to try to bring down the target node. The problem is fixed in releases `v0.34.29` and `v0.37.2`. Some workarounds are available. Increasing the value of `cache_size` in `config.toml` makes it very difficult to effectively attack a full node. Not exposing the transaction submission RPC's would mitigate the probability of a successful attack, as the attacker would then have to create a modified (byzantine) full node to be able to perform the attack via p2p.
affected
Severity
High
Feb 4, 2025
Published
Jul 5, 2023
