Full Report
CometBFT is a BFT implementation used by Cosmos blockchains. In this, block timestamps are derived from a weighted median of validator votes. In theory, this should ensure that the median timestamp falls within the range of honest validators, even when 1/3 are malicious. Commit is used for the finalized proof within a block being accepted and bundling the block ID with a set of signatures. Each commit signature is a validator's vote attesting to that block. The Commit structure stores the entirety of the block information. The signatures are a list of CommitSig objects, each containing an address, timestamp, and signature. When performing commit signature verification, the index of the signature is used to find the amount of voting power. When computing the median time, the validator address is used instead. If the address is not present in the current validator set, then it's simply skipped. This small difference allows different values to be used for different things. For signature verification, the ValidatorAddress doesn't matter; it's only the index of the signature. So, the submitter of a block can use an invalid ValidatorAddress to force the lookup of an invalid value for the median time difference! The example exploit makes the attacker's validator address the ONLY valid address and index, allowing them to set the block timestamp arbitrarily. On most chains, it's possible to cause a chain halt by forcing an overflow on the time of the block. In the case of chains with time-based rewards, increasing the time horizon enables the creation of large amounts of assets. Notably, Babylon and Celestia would result in a significant token inflation. The "$600M" portion feels slightly exaggerated. These funds become unusable almost immediately after exploitation. The vulnerability is pretty rad! Bad input validation on all fields leads to a weird edge case that breaks everything. Awesome find! To fix this, they suggest performing address validation on the index and returning an error if the address cannot be found. Anytime errors are silently being ignored, it's probably going to be a problem!
Analysis Summary
# Vulnerability: Tachyon Time-Warp Attack in CometBFT
## CVE Details
- **CVE ID**: Not explicitly listed in the source (Referred to as the "Tachyon" vulnerability).
- **CVSS Score**: Estimated 9.0 - 10.0 (Critical)
- **CWE**: CWE-20 (Improper Input Validation) / CWE-697 (Incorrect Comparison)
## Affected Systems
- **Products**: CometBFT (formerly Tendermint) and blockchains built on the Cosmos SDK.
- **Versions**: All versions since January 2020. Confirmed on v0.38.x (specifically v0.38.20); likely affects v0.37.x and v1.x branches.
- **Configurations**: Blockchains utilizing BFT time for consensus and reward distribution (e.g., Celestia, Babylon, and 40+ other Cosmos-based chains).
## Vulnerability Description
The flaw stems from a consistency mismatch between how validator signatures are verified versus how they are used to calculate the block's median timestamp.
1. **Commit Verification**: Uses an **index-based lookup** (`GetByIndex`). It verifies that a signature at a specific index belongs to the validator at that index in the set. It does *not* strictly validate the `ValidatorAddress` field within the `CommitSig` object during this phase.
2. **Median Time Calculation**: Uses an **address-based lookup** (`GetByAddress`). If an address provided in the `CommitSig` is not found in the current validator set, the system silently skips it instead of returning an error.
By providing an invalid `ValidatorAddress` for honest validators while maintaining a valid index, an attacker can force the system to skip honest timestamps. This allows a single malicious validator to make their own timestamp the "median," effectively gaining total control over the block's time.
## Exploitation
- **Status**: PoC available (Developed and tested by QED Audit).
- **Complexity**: Medium (Requires the attacker to be a validator in the set).
- **Attack Vector**: Network (Consensus layer).
## Impact
- **Confidentiality**: None.
- **Integrity**: **High**. Attackers can manipulate time-based rewards, leading to unbounded token minting and massive inflation (notably on Celestia and Babylon).
- **Availability**: **High**. On most chains, forcing a timestamp overflow or violating time-monotonicity invariants will cause a permanent network halt.
## Remediation
### Patches
- CometBFT released patches on **January 21, 2026**. Users should update to the latest security releases for the 0.38.x, 0.37.x, and 1.x branches.
- The fix involves performing address validation against the index and returning an error if the address does not match or cannot be found, rather than silently skipping it.
### Workarounds
- No viable software workarounds are identified; immediate patching of the binary is required for all validators.
## Detection
- **Indicators of Compromise**: Block timestamps that deviate significantly from real-world time or jump to extreme future values (e.g., year 2038+ or max uint64).
- **Detection Methods**: Monitoring `CommitSig` structures for `ValidatorAddress` fields that do not match the validator assigned to that signature index.
## References
- QED Audit Report: [https://qedaudit.io/blog/tachyon-time-warp/](https://qedaudit.io/blog/tachyon-time-warp/)
- CometBFT Validation Logic: [https://github.com/cometbft/cometbft/blob/main/types/validation.go#L247-L265](https://github.com/cometbft/cometbft/blob/main/types/validation.go#L247-L265)
- BFT Time Specification: [https://github.com/cometbft/cometbft/blob/main/spec/consensus/bft-time.md](https://github.com/cometbft/cometbft/blob/main/spec/consensus/bft-time.md)