Klever-Go CVE-2026-58262

The attacker must hold or compromise a block producer role on the Klever network, which requires staking or validator credentials (reflected as PR:L in the CVSS vector). The vulnerability is triggered only when the consensus group size is not an exact multiple of 8, producing padding bits in the final byte of PubKeysBitmap; consensus sizes that are multiples of 8 leave no exploitable padding. The crafted header must be submitted through normal block production channels. Limiting factors are: the block producer credential requirement eliminates unauthenticated and unprivileged attackers; the consensus-size divisibility condition must be met; and exploitation affects only consensus integrity (VI:H) with no confidentiality or availability impact (VC:N, VA:N).

The CVSS 4.0 score of 7.1 with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N correctly reflects the attack surface: network-accessible, low-complexity, but gated behind a block producer credential (PR:L), with high integrity impact and no confidentiality or availability consequence. The PR:L requirement meaningfully constrains the attacker pool to entities holding a validator or block-producer stake on the Klever network, or those who have compromised such an entity. No EPSS score was provided; no CISA KEV listing confirms active exploitation; and no public POC has been identified. The technical severity is real - consensus finality can be undermined without a genuine supermajority - but the practical exploitation window is limited to network insiders or sophisticated adversaries capable of compromising a block producer node. This is not a speculative high-CVSS-but-low-real-risk issue; the integrity impact on a blockchain is severe when exploited, but the barrier to entry (stake-based block producer role) substantially reduces the realistic threat population for most deployments.

A malicious or compromised block producer crafts a block header where the trailing byte of the PubKeysBitmap has padding bits (bit positions at or above consensusSize) set to 1. When peer nodes run verifyConsensusSize, these phantom bits inflate the apparent signer count past the two-thirds threshold even though fewer legitimate validator signatures were gathered. Because the BLS aggregate-signature check ignores those out-of-range bits, the header passes cryptographic verification, causing nodes to accept and finalize a block without genuine supermajority consensus - potentially enabling double-spend attempts or forcing an invalid chain branch.