Every CVESearch/Get API key

GHSA-p7mv-53f2-4cwj

CometBFT Vote Extensions: Panic when receiving a Pre-commit with an invalid data

8.3 HighFix available

Name: ASA-2024-011: Vote Extensions: Panic when receiving a Pre-commit with an invalid data Component: CometBFT Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: >= 0.38.x, unreleased v1.x and main development branches Affected users: Chain Builders + Maintainers, Validators

Impact

A CometBFT node running in a network with vote extensions enabled could produce an invalid Vote message and send it to its peers. The invalid field of the Vote message is the ValidatorIndex, which identifies the sender in the ValidatorSet running that height of consensus. This field is ordinarily verified in the processing of Vote messages, but it turns out that in the case of a Vote message of type Precommit and for a non-nil BlockID, a logic was introduced before this ordinary verification to handle the attached vote extension. This introduced logic (not present in releases prior to 0.38.x) does not double-check the validity of the ValidatorIndex field. The result is a panic in the execution of the node receiving and processing such message.

Impact Qualification

This condition requires the introduction of malicious code in the full node sending this Vote message to its peers. Namely, nodes running upstream code cannot produce invalid Vote messages, with non-existing ValidatorIndex. Moreover, networks utilizing default behavior, where vote extensions are not enabled, are not affected by this issue.

Patches

The new CometBFT release v0.38.15 fixes this issue.

Unreleased code in the main and v1.x branches, and experimental code in the v0.38-experimental and v1.x-experimental branches are patched as well.

Workarounds

When the consensus code panics after receiving an invalid Vote message, the operator can identify the peer from which that message was received. This may require increasing the logging level of the consensus module. This peer can then be subsequently banned at the p2p layer as a temporary mitigation.

References

Timeline

  • October 21, 2024, 3:26pm PST: Issue reported to the Cosmos Bug Bounty program
  • October 21, 2024, 3:41pm PST: Issue triaged by Amulet on-call, and distributed to Core team
  • October 29, 2024, 11:35pm PST: Core team completes validation of issue
  • October 30, 2024, 3:33am PST: Core team completes patch for issue
  • October 30, 2024, 5:09am PST: Amulet creates coordination plan; schedule for distribution
  • November 4, 2024, 8:00pm GMT: Pre-notification delivered
  • November 6, 2024, 8:00am GMT: Patch made available

This issue was reported by corverroos to the Cosmos Bug Bounty Program on HackerOne on October 21, 2024. 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 security@interchain.io. 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/.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
High
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
High
Availability
High

What each source reports

GitHub Advisories Score used8.3

CometBFT Vote Extensions: Panic when receiving a Pre-commit with an invalid data

Name: ASA-2024-011: Vote Extensions: Panic when receiving a Pre-commit with an invalid data Component: CometBFT Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: >= 0.38.x, unreleased v1.x and main development branches Affected users: Chain Builders + Maintainers, Validators

Impact

A CometBFT node running in a network with vote extensions enabled could produce an invalid Vote message and send it to its peers. The invalid field of the Vote message is the ValidatorIndex, which identifies the sender in the ValidatorSet running that height of consensus. This field is ordinarily verified in the processing of Vote messages, but it turns out that in the case of a Vote message of type Precommit and for a non-nil BlockID, a logic was introduced before this ordinary verification to handle the attached vote extension. This introduced logic (not present in releases prior to 0.38.x) does not double-check the validity of the ValidatorIndex field. The result is a panic in the execution of the node receiving and processing such message.

Impact Qualification

This condition requires the introduction of malicious code in the full node sending this Vote message to its peers. Namely, nodes running upstream code cannot produce invalid Vote messages, with non-existing ValidatorIndex. Moreover, networks utilizing default behavior, where vote extensions are not enabled, are not affected by this issue.

Patches

The new CometBFT release v0.38.15 fixes this issue.

Unreleased code in the main and v1.x branches, and experimental code in the v0.38-experimental and v1.x-experimental branches are patched as well.

Workarounds

When the consensus code panics after receiving an invalid Vote message, the operator can identify the peer from which that message was received. This may require increasing the logging level of the consensus module. This peer can then be subsequently banned at the p2p layer as a temporary mitigation.

References

Timeline

  • October 21, 2024, 3:26pm PST: Issue reported to the Cosmos Bug Bounty program
  • October 21, 2024, 3:41pm PST: Issue triaged by Amulet on-call, and distributed to Core team
  • October 29, 2024, 11:35pm PST: Core team completes validation of issue
  • October 30, 2024, 3:33am PST: Core team completes patch for issue
  • October 30, 2024, 5:09am PST: Amulet creates coordination plan; schedule for distribution
  • November 4, 2024, 8:00pm GMT: Pre-notification delivered
  • November 6, 2024, 8:00am GMT: Patch made available

This issue was reported by corverroos to the Cosmos Bug Bounty Program on HackerOne on October 21, 2024. 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 security@interchain.io. 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/.

Record
GHSA-p7mv-53f2-4cwj
CVSS 4.0
8.3 HighCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Weakness
CWE-129
Updated
2026-11-02
OSV8.3

CometBFT Vote Extensions: Panic when receiving a Pre-commit with an invalid data

Name: ASA-2024-011: Vote Extensions: Panic when receiving a Pre-commit with an invalid data Component: CometBFT Criticality: High (Considerable Impact, and Possible Likelihood per ACMv1.2) Affected versions: >= 0.38.x, unreleased v1.x and main development branches Affected users: Chain Builders + Maintainers, Validators

Impact

A CometBFT node running in a network with vote extensions enabled could produce an invalid Vote message and send it to its peers. The invalid field of the Vote message is the ValidatorIndex, which identifies the sender in the ValidatorSet running that height of consensus. This field is ordinarily verified in the processing of Vote messages, but it turns out that in the case of a Vote message of type Precommit and for a non-nil BlockID, a logic was introduced before this ordinary verification to handle the attached vote extension. This introduced logic (not present in releases prior to 0.38.x) does not double-check the validity of the ValidatorIndex field. The result is a panic in the execution of the node receiving and processing such message.

Impact Qualification

This condition requires the introduction of malicious code in the full node sending this Vote message to its peers. Namely, nodes running upstream code cannot produce invalid Vote messages, with non-existing ValidatorIndex. Moreover, networks utilizing default behavior, where vote extensions are not enabled, are not affected by this issue.

Patches

The new CometBFT release v0.38.15 fixes this issue.

Unreleased code in the main and v1.x branches, and experimental code in the v0.38-experimental and v1.x-experimental branches are patched as well.

Workarounds

When the consensus code panics after receiving an invalid Vote message, the operator can identify the peer from which that message was received. This may require increasing the logging level of the consensus module. This peer can then be subsequently banned at the p2p layer as a temporary mitigation.

References

Timeline

  • October 21, 2024, 3:26pm PST: Issue reported to the Cosmos Bug Bounty program
  • October 21, 2024, 3:41pm PST: Issue triaged by Amulet on-call, and distributed to Core team
  • October 29, 2024, 11:35pm PST: Core team completes validation of issue
  • October 30, 2024, 3:33am PST: Core team completes patch for issue
  • October 30, 2024, 5:09am PST: Amulet creates coordination plan; schedule for distribution
  • November 4, 2024, 8:00pm GMT: Pre-notification delivered
  • November 6, 2024, 8:00am GMT: Patch made available

This issue was reported by corverroos to the Cosmos Bug Bounty Program on HackerOne on October 21, 2024. 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 security@interchain.io. 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/.

Record
GHSA-p7mv-53f2-4cwj
CVSS 4.0
8.3 HighCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Weakness
CWE-129
Updated
2026-11-02
OSVGO-2024-3259No score

CometBFT Vote Extensions: Panic when receiving a Pre-commit with an invalid data in github.com/cometbft/cometbft

CometBFT Vote Extensions: Panic when receiving a Pre-commit with an invalid data in github.com/cometbft/cometbft

Record
GO-2024-3259
Updated
2026-11-02

Affected packages

Affected packages
PackageAffectedFixed
github.com/cometbft/cometbft
Go
0.38.0 up to 0.38.15
0.38.15

History

History
RecordedChangedSources
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

GHSA-p7mv-53f2-4cwj is a high vulnerability (CVSS 8.3) in github.com/cometbft/cometbft, published November 6, 2024. No source lists public exploit code. Fixed in github.com/cometbft/cometbft 0.38.15.

References

MoveEnter Open