Miggo Logo
Miggo Vulnerability Database
→
GHSA-hrhf-2vcr-ghch

GHSA-hrhf-2vcr-ghch: CometBFT's invalid BitArray handling can lead to network halt

N/A

CVSS Score

Basic Information

CVE ID
-
GHSA ID
GHSA-hrhf-2vcr-ghch
EPSS Score
-
CWE
CWE-228
Published
10/14/2025
Updated
10/14/2025
KEV Status
No
Technology
TechnologyGo

Technical Details

CVSS Vector
-
Package NameEcosystemVulnerable VersionsFirst Patched Version
github.com/cometbft/cometbftgo<= 0.37.150.37.16
github.com/cometbft/cometbftgo>= 0.38.0-alpha.1, <= 0.38.180.38.19

Vulnerability Intelligence
Miggo AIMiggo AI

Miggo AIRoot Cause Analysis

The vulnerability exists in CometBFT's handling of the BitArray data structure, which is used in various peer-to-peer messages. The root cause is a failure to validate that the BitArray's internal state is consistent, specifically that the length of its Elems slice (which holds the bit data) corresponds correctly to the number of Bits it claims to represent.

An attacker can craft a network message, such as NewValidBlockMessage, ProposalPOLMessage, or VoteSetBitsMessage, containing a BitArray with this inconsistency. The analysis of the patches shows that the ValidateBasic methods for these message types in consensus/reactor.go were missing the necessary validation for their BitArray fields.

When a vulnerable node receives such a message, it accepts the malformed BitArray. Subsequent operations on this BitArray, such as those performed by bits.BitArray.setIndex or bits.BitArray.getNumTrueIndices, would then result in an out-of-bounds memory access, causing the node process to panic and crash. Because these messages are gossiped to other peers before being fully processed, the vulnerability could be used to trigger a cascading failure across the network, leading to a halt.

The patches rectify this by first introducing a ValidateBasic method on the BitArray type itself to check for the inconsistency. Secondly, they add calls to this new validation method within the ValidateBasic methods of the message types that carry BitArrays, ensuring that invalid messages are rejected upon receipt. Finally, defensive guards were added to the internal BitArray methods (setIndex, getNumTrueIndices) as a secondary protection against panics.

Vulnerable functions

consensus.NewValidBlockMessage.ValidateBasic
consensus/reactor.go
This function processes `NewValidBlockMessage` messages from peers. Prior to the patch, it did not validate the consistency of the `BlockParts` BitArray, allowing a malformed BitArray to be processed, which could lead to a panic. The patch adds a call to `m.BlockParts.ValidateBasic()` to prevent this.
consensus.ProposalPOLMessage.ValidateBasic
consensus/reactor.go
This function processes `ProposalPOLMessage` messages from peers. Prior to the patch, it did not validate the `ProposalPOL` BitArray. An attacker could send a message with an invalid BitArray, causing the node to crash. The patch introduces a call to `m.ProposalPOL.ValidateBasic()`.
consensus.VoteSetBitsMessage.ValidateBasic
consensus/reactor.go
This function processes `VoteSetBitsMessage` messages from peers. It was vulnerable because it failed to validate the `Votes` BitArray, allowing a maliciously crafted message to cause a panic. The fix was to add a call to `m.Votes.ValidateBasic()`.
bits.BitArray.setIndex
libs/bits/bit_array.go
This internal method of `BitArray` was vulnerable to an out-of-bounds panic. If a malformed BitArray (where the `Elems` slice was too small for the number of `Bits`) was received and processed, a call to `setIndex` could attempt to access an index beyond the bounds of the `Elems` slice, causing a crash. The patch adds a check against `len(bA.Elems)`.
bits.BitArray.getNumTrueIndices
libs/bits/bit_array.go
This function calculates the number of set bits. It was vulnerable to a panic if it operated on a malformed BitArray where the `Elems` slice length didn't match the `Bits` count. This mismatch could cause an out-of-bounds read during iteration. The patch adds a guard to validate the BitArray's internal consistency before proceeding.

WAF Protection Rules

WAF Rule

N*m*: *S*-****-***: Inv*li* *it*rr*y **n*lin* **n l*** to n*twork **lt *riti**lity: *i** (*onsi**r**l* Imp**t; Possi*l* Lik*li*oo* p*r [**Mv*.*](*ttps://*it*u*.*om/int*r***inio/s**urity/*lo*/m*in/r*sour**s/*L*SSI*I**TION_M*TRIX.m*)) *****t** v*rsions

Reasoning

T** vuln*r**ility *xists in *om*t**T's **n*lin* o* t** `*it*rr*y` **t* stru*tur*, w*i** is us** in v*rious p**r-to-p**r m*ss***s. T** root **us* is * **ilur* to v*li**t* t**t t** `*it*rr*y`'s int*rn*l st*t* is *onsist*nt, sp**i*i**lly t**t t** l*n*t*