Skip to content
Fencer Intel
high —

GHSA-m6wq-66p2-c8pc json

Babylon Nil BlockHash in BLS vote extensions triggers panics in consensus handlers

published 11mo ago modified 8mo ago also GO-2025-4211

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

### Summary

A vulnerability exists in Babylon’s BLS vote extension processing where a malicious active validator can submit a VoteExtension with the `block_hash` field omitted from the protobuf serialization. Because protobuf fields are optional, unmarshalling succeeds but leaves `BlockHash` as nil. Babylon then dereferences this nil pointer in consensus-critical code paths (notably `VerifyVoteExtension`, and also proposal-time vote verification), causing a runtime panic.

### Impact

Intermittent validator crashes at epoch boundaries, which would slow down the creation of the epoch boundary block.

### Finder

Vulnerability discovered by:

- @GrumpyLaurie55348

Patch / fix

  • go github.com/babylonlabs-io/babylon/v4 4.2.0

Is GHSA-m6wq-66p2-c8pc in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
go github.com/babylonlabs-io/babylon/v4
<4.2.0
4.2.0
go github.com/babylonlabs-io/babylon/v3
<=3.0.0-snapshot.250805a
all versions
 no fix listed
go github.com/babylonlabs-io/babylon/v2
<=2.3.2
all versions
 no fix listed
go github.com/babylonlabs-io/babylon
<=1.1.0
all versions
 no fix listed

Classification

Weakness

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.