Description

Klever-Go is the Go implementation of the Klever blockchain protocol. In versions 1.7.14 through 1.7.17, the direct-message ingress handler spawns a new goroutine for every incoming direct message before the processor-level antiflood layer makes any admission decision, with no semaphore, throttler, or bound on the number of concurrent in-flight spawns. Because the antiflood check runs inside the spawned goroutine rather than before it, a single connected peer can open a direct-send stream and send a stream of well-formed messages to force unbounded goroutine creation, where each goroutine allocates its own stack and holds a message reference until processing completes, adding scheduler and garbage-collection pressure faster than the runtime can drain it. This lets one peer degrade the node's availability and its ability to process legitimate traffic, resulting in a remotely triggerable denial of service. The issue is fixed in 1.7.18.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-07T23:17:04.743Z",
  "pubdate": "2026-08-07T23:17:04.743Z",
  "executiveSummary": "A denial of service vulnerability exists in the Klever-Go blockchain protocol implementations from version 1.7.14 through 1.7.17. The flaw resides within the direct-message ingress handler, which improperly spawns a new goroutine for every incoming direct message prior to evaluating processor-level antiflood admission controls. Lacking any concurrency throttling, semaphores, or bound mechanisms, an attacker maintaining a connected peer state can flood the targeted node with a stream of well-formed messages over a direct-send stream. This forces unbounded and uncontrolled goroutine creation, where each spawned context allocates an independent execution stack and retains message references. The resulting resource exhaustion introduces severe scheduler and garbage-collection pressure that outpaces runtime drainage capabilities, ultimately degrading node availability and disrupting legitimate transaction and consensus processing. Exploitation requires network connectivity to the target node's direct-message ingress channel but can be triggered remotely by any connected peer without requiring elevated privileges. The vulnerability is officially remediated in version 1.7.18 by reordering admission control logic to precede asynchronous execution spawning.",
  "technicalDetails": "The vulnerability is caused by architectural sequencing flaws in the direct-message ingress handler of the Klever-Go blockchain protocol. Specifically, the software processes incoming network messages by immediately instantiating a new Go routine for every received message frame before executing the processor-level antiflood admission validation layer. Because this concurrency provisioning lacks semaphores, rate limiters, or strict architectural upper bounds, the ingress pipeline allows the total count of in-flight goroutines to scale linearly with the rate of incoming network traffic.\nThe attack vector involves a remote malicious peer opening a direct-send stream to target nodes running vulnerable versions 1.7.14 through 1.7.17. The attacker transmits a continuous stream of structurally valid direct messages. Upon receipt, the vulnerable direct-message ingress handler blindly spawns an unconstrained number of concurrent goroutines. Each spawned goroutine allocates dedicated memory for its execution stack and maintains a direct reference to the incoming message payload while awaiting processing execution.\nBecause the antiflood evaluation logic executes asynchronously inside the spawned goroutine rather than synchronously at the ingress boundary, the antiflood mechanism fails to drop or reject the excess traffic before resource allocation occurs. This design flaw enables an asymmetric resource consumption model: minimal network bandwidth and framing effort by the attacker translates into massive memory allocation, scheduler thrashing, and high garbage-collection overhead on the target node. The Go runtime becomes overwhelmed, unable to drain the execution queues fast enough to keep pace with the artificially induced creation rate.\nThe post-exploitation impact is a localized or systemic denial of service. The targeted node suffers from catastrophic resource starvation, leading to unresponsiveness, dropped consensus messages, and failure to process legitimate blockchain traffic. Authentication and privilege requirements are minimal, as any network-connected peer can establish the necessary stream state to trigger the ingress handler. The vulnerability is fully resolved in version 1.7.18, where the antiflood admission check is relocated to occur prior to goroutine spawning, thereby dropping unauthorized or excessive messages synchronously."
}