GHSA-c32p-wcqj-j677
CometBFT has inconsistencies between how commit signatures are verified and how block time is derived
Blast Radius
github.com/cometbft/cometbft🐹github.com/cometbft/cometbftReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
CSA-2026-001: Tachyon
Description
Name: CSA-2026-001: Tachyon
Criticality: Critical (Catastrophic Impact; Possible Likelihood per ACMv1.2)
Affected versions: All versions of CometBFT
Affected users: Validators and protocols relying on block timestamps
Description
A consensus-level vulnerability was discovered in CometBFT's "BFT Time" implementation due to an inconsistency between how commit signatures are verified and how block time is derived.
This breaks a core BFT Time guarantee: "A faulty process cannot arbitrarily increase the Time value."
Impact
Downstream impact on chains affects any module, smart contract, or system that relies on the block timestamp.
Patches
The new CometBFT releases v0.38.21 and v0.37.18 fix this issue. The main unreleased branch is also patched.
Workarounds
There are no effective workarounds for this vulnerability. Upgrading to patched versions is required.
Timeline
- January 8, 2026, 5:27PM UTC: Issue reported to Cosmos Bug Bounty Program
- January 9, 2026, 4:55AM UTC: Issue triaged and validated by core team
- January 12, 2026, 10:25PM UTC: Core team completes patch for the issue
- January 13, 2026 4:41PM UTC: Pre-notification delivered to ecosystem partners
- January 23, 2026, 3:00PM UTC: Patch made available
Credits
This issue was reported to the Cosmos Bug Bounty Program on HackerOne. Credit to SEAL 911 and QED Audit for the discovery and help with the patch.
If you believe you have found a bug in the Cosmos Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.
If you have questions about Cosmos security efforts, please reach out to our official communication channel at [email protected].
A Github Security Advisory for this issue is available in the CometBFT repository. For more information about CometBFT, see https://docs.cometbft.com/.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/cometbft/cometbft | ≥ 0.38.0-alpha.1&&< 0.38.21 | 0.38.21 |
| 🐹Go | github.com/cometbft/cometbft | all versions | 0.37.18 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/cometbft/cometbft. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/cometbft/cometbft to 0.38.21 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c32p-wcqj-j677 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-c32p-wcqj-j677 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-c32p-wcqj-j677. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-c32p-wcqj-j677 in your dependencies?
O3 detects GHSA-c32p-wcqj-j677 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.