Omni Identifies Critical Vulnerability in CometBFT

In October 2024, our team identified and reported a critical vulnerability in CometBFT, specifically within the implementation of ABCI 2.0's Vote Extensions. This flaw has since been patched and publicly disclosed in GitHub Security Advisory GHSA-p7mv-53f2-4cwj. Our team member, Corver, was credited with discovering and reporting this exploit.

If exploited, the malicious actor could halt any Cosmos chain with Vote Extensions enabled.

Context

CometBFT is a BFT consensus engine for building blockchains. It serves as the consensus layer for various blockchains, particularly those built with the Cosmos SDK. ABCI 2.0 is the Application Blockchain Interface – the communication protocol between the consensus and application layers in CometBFT. ABCI 2.0 introduced a more customizable consensus process, and introduced many new features including Vote Extensions. Vote Extensions allow validators to attach additional application specific data to their pre-commit votes. Typically, vote extensions are used to bring non-deterministic or off-chain data on-chain, like with Skip’s Slinky oracle.

Omni’s goal is to make it easy for smart contract developers to access users and capital from the entire Ethereum ecosystem. The Omni Network consists of 2 components:

• Core: cross-chain messaging and EVM
• SolverNet: intents protocol leveraging Core for settlement

Omni Core uses Vote Extensions for cross-chain messaging. Validators watch supported chains for cross-chain messages, build XBlocks (cross-chain blocks), and attest to them via Vote Extensions.

Discovering the Vulnerability

Omni Labs operates multiple environments for development and testing, including a staging environment designed to test protocol features under real world conditions. Staging consists of a full instance of the Omni Network with multiple validators and support for Holesky, Base Sepolia, Arbitrum Sepolia, and Optimism Sepolia testnets. It is frequently redeployed from Block 0 for testing purposes.

During routine testing, Corver synced a 3rd validator to staging (in addition to the usual 2) with additional logging to test a new feature. The tests went fine, and the third validator remained synced to the network.

Later that week, staging was redeployed from scratch to batch release new features into staging – a normal practice. This creates a new instance of staging from Block 0. Staging started processing blocks, and everything went smoothly. From here on out, we’ll refer to the previous instance of staging as Staging 1, and the current instance of staging as Staging 2.

Over the weekend, Grafana began reporting staging consensus failures, node crashes, and unexpected behavior across staging. It was armageddon. Investigation revealed that Corver’s third validator, still running from Staging 1, was now connected to Staging 2 and attempting to participate.

However, this shouldn’t have been catastrophic. Preventing malicious behavior from validators is basically the #1 goal for blockchains. However, Omni isn’t just running standard CometBFT consensus, it was also using vote extensions.

The orphaned validator started sending pre-commit votes with Vote Extensions referencing ValidatorIndex 3 that did not exist in Staging 2. These “malformed” Vote Extensions caused recipient validators and full nodes to panic and crash upon receiving them.

Why didn’t the new instance of staging crash immediately though? Well, the orphaned validator only began sending messages to Staging 2 at a specific block height (roughly, say, ~10,000), corresponding to when it joined Staging 1. Anything before block ~10,000 was before its time (on Staging 1), so from Validator 3’s perspective, it didn’t know anything about blocks 0→9,999.

The vulnerability allowed any full node to send a malicious pre-commit message containing an invalid vote extension, causing recipient validators or full nodes to crash.

The Impact

For any Cosmos or CometBFT chain with vote extensions enabled, an attacker could:

• Operate a malicious full node
• Broadcast invalid pre-commit messages containing malformed Vote Extensions
• Cause validators and other full nodes to crash, likely halting the entire network

Affected systems include protocols relying on vote extensions in any capacity, such as Skip’s Slinky oracle and dYdX v4, which secures $350m in TVL.

Mitigation

Upon identifying the issue, we promptly reported it to the CometBFT development team. They acknowledged the vulnerability and released a patch, introducing additional validation checks within the VerifyVoteExtension method to ensure malformed Vote Extensions are safely rejected.

Lessons Learned

This incident reinforces a couple best practices that are well-known in protocol development. But it’s helpful to have a reminder once in a while anyway.

• Validation – never trust p2p messages, verify rigorously
• Robust error handling – malformed data should fail gracefully without compromising network stability

We are grateful to the CometBFT team for their swift response and effort in addressing the issue.

See you onchain.