CometBFT's Blocksync 0-Day: Neither High Nor Informational

Three failures to separate: the bug, the severity claim, the triage process

A Korean security researcher disclosed a CometBFT blocksync vulnerability yesterday (issue #5801). Claimed severity: CVSS 7.1 High.

The vendor, Cosmos Labs, has declined to treat it as a security vulnerability and reclassified a related prior bug (CVE-2025-24371) as Informational. I think both assessments miss.

The technical analysis in the disclosure is correct. The decision to go public, given the timeline, is defensible. But 7.1 is over-priced, and Informational is under-priced. As someone who has developed on the Cosmos-SDK and operated Cosmos chains in production, here is how I would split the problem.

The bug

Two functions in the blockpool matter: pickIncrAvailablePeer and SetPeerRange.

pickIncrAvailablePeer filters peers with height < peer.base || height > peer.height. That check is fine in isolation.

SetPeerRange is where the invariant breaks. When a peer reports (base, height), the function only rejects values that are lower than previously seen:

if base < peer.base || height < peer.height {
    pool.removePeer(peerID)
    pool.banPeer(peerID)
    return
}

It never checks whether base is sane relative to pool.height. A malicious peer can advertise (base=1_000_000, height=1_000_100) while the chain sits at 151. maxPeerHeight inflates to 1,000,100. The sync target shifts to a block no one can serve. The peer is not banned because nothing went down. Every iteration of the requester picks this peer as “available,” fails, and retries forever. The node is wedged in blocksync permanently.

This is the same class of bug as CVE-2025-24371. The prior patch banned peers for reporting lower values. The new path bypasses it through higher values. Patch bypass is what makes #5801 non-trivial.

Why 7.1 is over-priced

The “chain halt at $8B+ ecosystem” framing in the disclosure requires several conditions stacking at once. Many validators must restart simultaneously. They must come up via blocksync rather than statesync. They must peer with the malicious node rather than through curated sentries. Their p2p topology must fail to filter the peer at any tier.

Each of these is unlikely in a production Cosmos chain. Validators restart rarely. Most operators prefer statesync for fresh joins. Anyone running sentries uses persistent_peers and private_peer_ids to control who their validator talks to.

Then there is the attacker-incentive dimension CVSS does not capture. No theft is possible. Shorting a chain with a blocksync-only DoS requires coordinated visibility the attack cannot deliver. The malicious peer is trivially identifiable. If you cannot make money and you will be caught, you do not run this.

One more point. The researcher’s own CVSS vector is SA:N (Subsequent System Availability: None). The score itself says “this deadlocks a single node,” but the prose says “ecosystem halt.” Those are not compatible. If the real impact were ecosystem-level, the vector would be SA:H, and the score would rise correspondingly.

My read: CVSS 4.5 to 5.5. Medium to low-medium.

Why Informational is under-priced

Cosmos Labs does not get a pass either. A bug that causes permanent, unrecoverable blocksync deadlock, bypasses an existing patch, reproduces trivially, and affects both validators and full nodes is not Informational.

The reclassification of CVE-2025-24371 to Informational (Negligible Impact, Possible Likelihood), done the day after a new researcher report landed, reads as a post-hoc severity adjustment rather than a principled reassessment.

The HackerOne response summary says the attack is not feasible but the bug has impact. That is internally inconsistent. If the bug has impact, it is a security bug. The question is degree, not whether.

The disclosure fight

Two things are being conflated in the public narrative, and they should be pulled apart.

First, operational failures. The researcher’s second report was marked as spam on HackerOne. The day after, a core maintainer opened issue #5670: “Create whitelist of known-good HackerOne submitters,” citing the false-positive as the trigger. That is the team acknowledging their own process broke, and proposing a public fix. That is the right response.

The problem is #5670 has sat open for six weeks with no PR, no label, no assignee action. Acknowledgment and resolution are different things.

I don’t say this from a distance. People I work with have had bug reports to the Cosmos team sit for over a month without review. The operational failure the researcher describes is not unique to this case, and calling out the pattern has some merit.

Second, the severity judgment. A CVSS reclassification the day after a new researcher report landed looks like something other than triage capacity. Ignoring a network-level PoC for over a month without technical rebuttal also does not fit the “we’re overwhelmed” story. I don’t have visibility into Cosmos Labs’ internal review process, so I won’t call it a methodology failure outright. But the timing sits outside what the spam-filter explanation covers.

The “AI-generated bug bounty spam is overwhelming maintainers” framing explains operational slowness. It explains less about severity reclassifications done on the same timeline. Readers who want to defend Cosmos Labs on the first point should be careful not to extend the defense to the second.

What operators should actually do

If you run a Cosmos-SDK chain, the practical risk depends on your peer policy, not on the CVSS number.

Blocksync is an edge path. Most production operators already use statesync for new nodes and rarely restart validators. If that describes you, real-world exposure is low.

If you use public seeds directly, or your sentry layer is not curated, you are in scope. Tighten persistent_peers and private_peer_ids on the validator. Make sure first-tier full nodes filter untrusted peers at the p2p layer.

The researcher’s “do not restart until patched” guidance is right for that narrow case but oversold as a general recommendation.

Patch will likely land within days now that the issue is public. Track CometBFT’s v0.38.x and v1.x release branches.

Closing

This is not a “researcher versus vendor” story, though it is being written that way on Twitter. It is a story about two separate failures.

A bug that got classified too softly by the maintainer, and a severity claim that reaches beyond what the CVSS vector itself supports. Both can sit outside what the evidence supports at the same time. Both do.

The right response is not to pick a side. It is to hold both positions at once: this is a medium-severity invariant bug that needs a real patch, and the disclosure process for it exposed gaps in how Cosmos Labs handles security reports. Those gaps are partly explained by the “too much AI spam” defense. Partly is not fully.

The patch will ship. The triage process is still the open question.