GHSA-5854-jvxx-2cg9

What it actually does

This vulnerability is a denial-of-service flaw in the content handling logic of github.com/cometbft/cometbft. A malformed, oversized, or otherwise adversarial input can cause affected CometBFT versions to consume excessive resources, fail processing, or become unavailable. The impact is availability-focused rather than direct code execution or data theft, but in consensus or blockchain infrastructure, node instability can affect peer connectivity, block propagation, validation, and service reliability.

Why it matters to the business

Organizations running affected CometBFT versions may experience degraded or unavailable blockchain/node services if an attacker or hostile peer triggers the flaw. Operational consequences can include node crashes, missed consensus participation, delayed transaction processing, service interruptions, alert fatigue, and potential financial or reputational impact where uptime or validator participation matters. The issue is old and not listed in CISA KEV, and no exploit maturity is reported, but exposed or peer-connected nodes should still be upgraded because denial-of-service flaws in consensus infrastructure can be disruptive even without data compromise.

How an attack unfolds

An attacker first identifies a service or node running a vulnerable CometBFT version. They then interact with the exposed network interface or protocol path that processes the vulnerable content. By sending crafted content that exercises the vulnerable parsing or validation behavior, the attacker causes the target process to consume excessive CPU, memory, or otherwise enter an error state. If successful, the CometBFT node may crash, become unresponsive, drop peers, or stop participating normally until restarted or remediated. Repeated delivery can turn a single crash condition into sustained service degradation.

How to fix it

Upgrade github.com/cometbft/cometbft to version 0.37.7 or later. If CometBFT is included transitively through another Go module or blockchain application, update the parent application or dependency lock file so the resolved CometBFT version is fixed. Rebuild and redeploy affected binaries after updating Go module dependencies. As temporary mitigations, restrict access to CometBFT network/API surfaces to trusted peers and administrative networks, apply rate limits where feasible, monitor resource use, and use process supervision to restart crashed services; these mitigations reduce exposure but do not replace upgrading.

How to confirm the fix worked

Confirm the deployed binary or application resolves github.com/cometbft/cometbft at version 0.37.7 or later. Review go.mod and go.sum, run dependency inspection such as `go list -m all | grep github.com/cometbft/cometbft`, and verify container images or packaged binaries were rebuilt after dependency updates. Validate that exposed CometBFT ports and APIs are limited to intended networks. After upgrade, perform controlled negative testing with malformed or oversized content only in a safe test environment and confirm the node remains stable with no crash, excessive resource consumption, or peer disruption.

Typical attack path

1. Identify internet-exposed or peer-accessible CometBFT nodes running a vulnerable version.
2. Establish network interaction with the relevant CometBFT protocol or API surface.
3. Send crafted content that triggers the vulnerable denial-of-service condition.
4. Observe node instability, excessive resource consumption, peer disconnects, process crashes, or service unavailability.
5. Repeat the request or content delivery to sustain outage conditions until the software is upgraded or traffic is filtered.

How to detect it

To determine whether exploitation already occurred, review CometBFT application logs, system journals, container logs, supervisor logs, and infrastructure metrics for unexplained crashes, restarts, out-of-memory events, CPU or memory spikes, peer disconnect storms, or malformed-content errors. Correlate these events with inbound network connections to CometBFT peer/RPC/API ports, especially repeated requests or traffic from unfamiliar peers immediately before instability. In containerized environments, inspect orchestration events for CrashLoopBackOff, OOMKilled, repeated liveness probe failures, or rapid pod restarts. On hosts, review system logs for kernel OOM killer messages, segmentation faults, panic traces, or service-manager restart events involving CometBFT-based processes. Because no public exploit indicators are provided for this advisory, detection should focus on behavioral evidence of denial of service rather than a unique payload signature.

• github.com/cometbft/cometbft
• cometbft
• CometBFT
• OOMKilled
• CrashLoopBackOff
• out of memory
• Killed process
• panic:
• fatal error:
• segmentation violation
• connection reset by peer
• peer disconnected
• too many open files
• service restart
• Started CometBFT
• Stopped CometBFT

What your security team should do

• Inventory applications, nodes, containers, and services that include github.com/cometbft/cometbft.
• Prioritize upgrade of exposed validators, sentry nodes, RPC endpoints, and other peer-accessible CometBFT deployments to 0.37.7 or later.
• Rebuild and redeploy binaries after dependency updates; do not rely only on source-level dependency changes.
• Restrict CometBFT peer, RPC, and administrative interfaces to trusted networks and peers wherever possible.
• Add monitoring for process restarts, node crashes, peer churn, missed blocks, memory spikes, CPU saturation, and abnormal inbound traffic volumes.
• Review historical logs for unexplained CometBFT crashes or resource exhaustion around externally reachable interfaces.
• Document operational restart procedures and ensure supervisors are configured, while treating restart automation as a resilience measure rather than a fix.