GHSA-r3r4-g7hq-pq4f
CometBFT allows a malicious peer to stall the network by disseminating seemingly valid block parts
Blast Radius
github.com/cometbft/cometbft🐹github.com/cometbft/cometbftReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Name: ASA-2025-002: Malicious peer can stall network by disseminating seemingly valid block parts Component: CometBFT Criticality: High (Catastrophic Impact; Possible Likelihood per ACMv1.2) Affected versions: <= v0.38.16, v1.0.0 Affected users: Validators, Full nodes, Users
Description
A bug was identified in the CometBFT validation of block part indices and the corresponding proof part indices that can lead to incorrect processing and dissemination of invalid parts, which in turn could lead to a network halt. Additional validation was added to prevent this condition from happening.
Patches
The new CometBFT releases v1.0.1 and v0.38.17 fix this issue.
Unreleased code in the main branch is patched as well.
Workarounds
There are no known workarounds for this issue. If a node is producing these malicious proofs, the only mitigation is to upgrade CometBFT. After upgrading, the validators then will eventually conclude the correct value.
Technical Deep-Dive
When the next proposer creates a block, it is split into many block parts (64kB each). Each block part is then disseminated via p2p layer in a gossip fashion. The block part contains the following fields:
type Part struct {
Index uint32 `json:"index"`
Bytes cmtbytes.HexBytes `json:"bytes"`
Proof merkle.Proof `json:"proof"`
}
Index- represents the index of a block partBytes- the actual contentProof- Merkle proof, which allows the receiving node to quickly verify that aPartis indeed a piece of the proposed block.
The Proof contains the following fields:
type Proof struct {
Total int64 `json:"total"` // Total number of items.
Index int64 `json:"index"` // Index of item to prove.
LeafHash []byte `json:"leaf_hash"` // Hash of item value.
Aunts [][]byte `json:"aunts,omitempty"` // Hashes from leaf's sibling to a root's child.
}
Note that the total number of leaves in the Merkle tree equals the number of parts in the proposed block. Previously, CometBFT did not validate the Index field and specifically that Part.Index must be equal to Part.Proof.Index. This leads to a condition where, it is possible to use the proof from a different part and CometBFT accept it, even though the proof proves the different part is a piece of the proposed block and not the part that the peer actually sent to us.
This condition is problematic because:
- it would disseminate the invalid block part to its neighboring nodes (because it deemed it as correct)
- it would mark the block part as received and ask the neighboring nodes not to relay it in the future, making it impossible to receive the correct block part.
To address this, CometBFT was patched to verify that Part.Index is equal to Part.Proof.Index, preventing the above condition.
Timeline
- January 15, 2025, 12:12pm PST: Issue reported to the Cosmos Bug Bounty program
- January 15, 2025, 12:31pm PST: Issue triaged by Amulet on-call, and distributed to Core team
- January 27, 2025, 11:28pm PST: Core team completes validation of issue
- January 31, 2024, 2:15pm PST: Pre-notification delivered
- February 3rd, 2024, 9:00am UTC+4: Patch made available
This issue was reported by unknown_feature to the Cosmos Bug Bounty Program on HackerOne on January 15, 2025. If you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.
If you have questions about Interchain security efforts, please reach out to our official communication channel at [email protected]. For more information about the Interchain Foundation’s engagement with Amulet, and to sign up for security notification emails, please see https://github.com/interchainio/security.
A Github Security Advisory for this issue is available in the CometBFT repository. For more information about CometBFT, see https://docs.cometbft.com/.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/cometbft/cometbft | ≥ 1.0.0-alpha.1&&< 1.0.1 | 1.0.1 |
| 🐹Go | github.com/cometbft/cometbft | all versions | 0.38.17 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/cometbft/cometbft. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/cometbft/cometbft to 1.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r3r4-g7hq-pq4f is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-r3r4-g7hq-pq4f is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-r3r4-g7hq-pq4f. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-r3r4-g7hq-pq4f in your dependencies?
O3 detects GHSA-r3r4-g7hq-pq4f across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.