Description

Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.18, the P2P resolver request handling logic is vulnerable to hash-array amplification. A connected peer can send a compressed RequestDataType_HashArrayType direct request that is only 442 bytes on the wire but expands into 200,000 decoded hash entries inside the resolver path. The resolver's antiflood logic counts only a single logical message and the compressed wire size, and while Batch.Decompress() caps the decompressed byte size, it never limits the number of decoded repeated-field items. As a result, both TxResolver and TrieNodeResolver preallocate and iterate over the entire unchecked set of decoded hashes, causing remote memory and CPU amplification against any node that accepts P2P peer connections. This issue is fixed in version 1.7.18.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-07T23:17:03.670Z",
  "pubdate": "2026-08-07T23:17:03.670Z",
  "executiveSummary": "Prior to version 1.7.18, Klever-Go, the Go implementation of the Klever blockchain protocol, contains a hash-array amplification vulnerability within its P2P resolver request handling logic.\nThe vulnerability allows a connected peer to send a maliciously crafted, compressed direct request containing an unchecked number of repeated-field items, leading to excessive resource consumption.\nThe impact includes remote memory and CPU amplification against any node accepting P2P peer connections, potentially resulting in denial of service conditions.\nAffected systems consist of Klever-Go instances running versions prior to 1.7.18.\nThe attacker capabilities require the ability to connect as a peer over the P2P network, sending a small compressed wire payload that expands massively upon decoding.\nExploitation is facilitated by insufficient input validation in the resolver path, where antiflood mechanisms only track compressed wire size and logical message counts rather than the number of decoded repeated-field items.",
  "technicalDetails": "The root cause of the vulnerability resides in the P2P resolver request handling logic of Klever-Go, specifically affecting the TxResolver and TrieNodeResolver components.\nWhen a connected peer sends a compressed RequestDataType_HashArrayType direct request, the wire size can be as small as 442 bytes while expanding into 200,000 decoded hash entries inside the resolver path.\nAlthough Batch.Decompress() enforces a cap on the decompressed byte size, it fails to limit the total count of decoded repeated-field items.\nAs a result, both TxResolver and TrieNodeResolver preallocate and iterate over the entire unchecked set of decoded hashes without restriction.\nThe attack flow proceeds as follows: an attacker establishes a P2P connection to a target Klever-Go node without requiring authentication or elevated privileges, exposing the network interface to incoming P2P traffic.\nThe attacker transmits a specially crafted, compressed P2P request payload designed to bypass the antiflood logic, which only counts a single logical message and the compressed wire size.\nUpon receipt, the resolver processes the compressed payload, which decompresses into an excessively large number of hash entries.\nThe vulnerable components preallocate memory and execute iterative loops over the massive unconstrained array, inducing severe CPU and memory exhaustion.\nThis payload behavior directly leads to resource starvation and potential denial of service for the targeted blockchain node."
}