GHSA-hrhf-2vcr-ghch
CometBFT's invalid BitArray handling can lead to network halt
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-003: Invalid BitArray handling can lead to network halt
Criticality: High (Considerable Impact; Possible Likelihood per ACMv1.2)
Affected versions: <= v0.38.18, <= v0.37.15, and main development branches
Affected users: Validators, Full nodes, Users
Description
A bug was discovered in CometBFT's handling of BitArray's that have a mismatch between the BitArray's expected number of Elems for the specified number of Bits. Additional validation was added to prevent processing BitArray's in this invalid state, as well as guards to prevent panics on BitArray methods if one of these invalid states is processed.
Impact
BitArray's are present in a number of messages received from peers. When handling these messages, insufficient validation was applied to prevent processing messages the aforementioned invalid state. In the worst case, nodes will gossip messages to peers in an invalid state before processing them themselves, leading to a network halt (instead of only the node receiving the malicious message crashing).
Patches
The new CometBFT releases v0.38.19 and v0.37.16 fix this issue.
Unreleased code in the main branch is patched as well.
Workarounds
If a node is able to identify a malicious peer sending these payloads, they can ban the ip address using common tools like iptables.
Timeline
- October 3, 2025, 11:26am EST: Issue reported to Cosmos Labs via an external team (via their Bug Bounty Program).
- October 3, 2025, 11:59am EST: Issue triaged by core team and core team completes validation of issue.
- October 6, 2025, 11:14pm EST: Issue reported to the Cosmos Bug Bounty Program (by original white hat reporter).
- October 9, 2025, 11:15am EST: Pre-notification delivered.
- October 10, 2025, 11:37am EST: Core team completes patch for the issue.
- October 14, 2025, 11:00am EST: Patch made available.
This issue was reported by @whoismxuse to the Cosmos Bug Bounty Program on HackerOne on October 6, 2025. If you believe you have found a bug in the Cosmos Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.
If there are questions about Cosmos security efforts, please reach out to our official communication channel at [email protected].
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 | all versions | 0.37.16 |
| 🐹Go | github.com/cometbft/cometbft | ≥ 0.38.0-alpha.1&&< 0.38.19 | 0.38.19 |
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 0.37.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hrhf-2vcr-ghch 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-hrhf-2vcr-ghch 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-hrhf-2vcr-ghch. 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-hrhf-2vcr-ghch in your dependencies?
O3 detects GHSA-hrhf-2vcr-ghch across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.