CVE-2026-82407 in Klever-Go
Summary
by MITRE • 09/23/2026
Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.20, core/kapp/validators/validators.go Register and the runtime validator update path accept a submitted BLSPublicKey without curve, prime-order subgroup, or nonzero validation. When a validator with a malformed key becomes eligible and is selected into a consensus group, MultiSigner.Reset and the corresponding signature verification creation path cannot deserialize the group key and cancel the slot. This causes repeated missed rounds and throughput degradation, and a network whose consensus group equals the eligible validator set can halt completely. Genesis validation is not affected because that path already performs CheckPublicKeyValid. This issue is fixed in version 1.7.20.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The Klever-Go blockchain protocol implementation contains a critical input validation deficiency within its core consensus mechanism, specifically affecting the validator registration and update processes prior to version 1.7.20. The vulnerability resides in the Register function located at core/kapp/validators/validators.go as well as the runtime validator update path. These components are responsible for accepting new BLS public keys from validators joining or updating their status within the network. However, these entry points fail to perform adequate cryptographic validation on the submitted BLSPublicKey data structure. Specifically, the implementation does not verify that the key belongs to a valid elliptic curve, ensure it resides in the prime-order subgroup required for secure BLS signature operations, or confirm that the point is non-zero and mathematically well-formed. This lack of rigorous input sanitization allows malformed cryptographic keys to be ingested into the system state without triggering an immediate rejection error during the registration phase.
The operational impact of this flaw manifests when a validator possessing such a malformed key becomes eligible for selection and is subsequently chosen by the consensus algorithm to join a specific consensus group. During the subsequent MultiSigner.Reset operation, which prepares the cryptographic machinery for signing blocks or attestations, the system attempts to deserialize the group public keys. Because one of these keys is structurally invalid due to the earlier validation bypass, the deserialization process fails catastrophically. This failure triggers an exception that causes the slot creation path to cancel the current consensus round. Consequently, the node responsible for this validator cannot produce a valid signature or block proposal for that specific time slot, leading directly to missed rounds in the blockchain's history.
From a network-wide perspective, if the eligible validator set is small enough such that the compromised validator constitutes a significant portion of the consensus group, the repeated cancellation of slots can severely degrade network throughput and availability. In worst-case scenarios where the consensus group consists entirely or predominantly of validators with malformed keys due to this vulnerability, the blockchain may halt completely as no valid blocks can be produced. This represents a severe denial-of-service condition that undermines the liveness property of the distributed ledger. The issue is distinct from genesis validation because the initial chain setup process already incorporates proper CheckPublicKeyValid logic, meaning only dynamically added or updated validators are susceptible to this exploitation vector during normal network operation.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-754: Improper Check for Unusual or Exceptional Conditions within the Common Weakness Enumeration framework. The failure to validate cryptographic parameters before use is a classic example of trusting untrusted input in security-critical code paths. In terms of adversary tactics, this flaw could be leveraged by malicious validators seeking to disrupt network availability without requiring complex exploitation techniques beyond submitting malformed key data during registration or update requests. It falls under the MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically targeting service availability through resource exhaustion or logic errors that prevent normal operation.
To mitigate this risk, operators must upgrade their Klever-Go nodes to version 1.7.20 or later, where the validation logic has been corrected to enforce strict checks on curve membership, prime-order subgroup compliance, and non-zero point verification before accepting any BLSPublicKey into the validator set. For networks that have not yet upgraded, monitoring for validators with anomalous key structures during registration events can help identify potential exploitation attempts. Additionally, implementing stricter input sanitization layers at the API boundary for all cryptographic material submissions is recommended to prevent similar issues in future protocol updates or other blockchain implementations relying on BLS signatures.