Description

Klever-Go is the Go implementation of the Klever blockchain protocol. Versions from 1.7.14 through 1.7.17 are vulnerable to a remotely triggerable denial of service. Both REST APIs are started with the Gin Engine.Run convenience method, which serves requests through Go's default HTTP server with no ReadHeaderTimeout, ReadTimeout, or MaxHeaderBytes configured. As a result, incoming connections that never complete their request headers are held open indefinitely. When a REST listener is reachable beyond localhost through the documented all-interface bind or a Docker port-publish deployment, a single unauthenticated client can open many slow-header connections and hold them open until server file descriptors are exhausted, preventing the API from accepting new connections. This renders the REST API unavailable to legitimate clients. 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:04.890Z",
  "pubdate": "2026-08-07T23:17:04.890Z",
  "executiveSummary": "A denial of service vulnerability exists in the Klever-Go blockchain protocol implementations from version 1.7.14 through 1.7.17. The vulnerability stems from improper configuration of the underlying HTTP server when initializing REST APIs via the Gin Engine.Run convenience method, specifically lacking safeguards such as ReadHeaderTimeout, ReadTimeout, and MaxHeaderBytes.\nThis architectural flaw enables unauthenticated remote attackers to execute a Slowloris-style attack vector by establishing multiple concurrent connections that intentionally send incomplete HTTP request headers. Because the server holds these connections open indefinitely without timeout enforcement, an attacker can rapidly exhaust available server file descriptors.\nWhen deployed with network exposure beyond localhost—such as via documented all-interface bindings or Docker port-publish configurations—the REST API becomes entirely inaccessible to legitimate clients, halting operational availability.\nExploitation requires no prior authentication or elevated privileges, relying solely on network reachability to the exposed REST listener endpoints to induce complete service degradation.",
  "technicalDetails": "The vulnerability resides within the REST API initialization logic of Klever-Go versions 1.7.14 through 1.7.17, where the Gin framework's Engine.Run method is utilized. Engine.Run internally instantiates Go's default HTTP server implementation without configuring critical connection timeouts and resource boundaries, specifically omitting ReadHeaderTimeout, ReadTimeout, and MaxHeaderBytes settings.\nIn Go's standard library, http.Server defaults to unbounded timeouts if explicit configuration values are not provided. Consequently, when an incoming TCP connection is established and the client begins transmitting HTTP headers at an arbitrarily slow rate or halts transmission entirely after initiating the connection, the server maintains the state of the socket indefinitely while awaiting the completion of the request headers.\nThe attack flow proceeds as follows: First, an unauthenticated remote adversary establishes a network socket connection targeting the exposed Klever-Go REST API listener. Second, the client sends partial HTTP headers or transmits data at extremely low intervals, circumventing standard keep-alive mechanisms by keeping the initial read operation perpetually active. Third, the adversary repeats this process concurrently across multiple connections until the operating system or application exhausts its maximum allocation of file descriptors.\nBecause file descriptors and associated goroutines are bound to these stalled connections, the Klever-Go REST listener loses the capacity to accept new incoming socket connections from legitimate network peers. This state persists as long as the malicious connections remain open or until the hosting process crashes due to resource exhaustion, rendering the blockchain protocol's REST interface unavailable.\nNetwork exposure is a primary precondition for successful remote exploitation. Systems configured to bind the REST listener to all network interfaces or deployed via Docker port-publish configurations that expose the internal ports to external networks are directly vulnerable. Localhost-only bindings mitigate remote exploitation vectors. The issue is fully resolved in version 1.7.18."
}