CVE-2026-86065: Denial of Service via Resource Exhaustion in klever-go WebSocket Subscription Endpoint

The klever-go package provides the Go implementation of the Klever blockchain protocol. Within this node architecture, the WebSocket endpoint located at /subscribe is designed to allow clients to receive real-time updates regarding blockchain events, block proposals, and transaction confirmations. This service represents a significant portion of the external attack surface exposed by public validator nodes.

In versions prior to 1.7.20, this endpoint was exposed without robust traffic or memory management controls. Because HTTP REST and WebSocket APIs run inside the primary node process, any unhandled resource exhaustion on this interface directly impacts the core validator engine. A failure in the WebSocket sub-system will cause the entire process to crash or hang, rendering the node incapable of participating in the consensus mechanism or synchronizing blocks.

This vulnerability is categorized under CWE-770 (Allocation of Resources Without Limits or Throttling). It consists of five interrelated sub-flaws: unbounded frame parsing, uncapped concurrent connections, unrestricted slice allocation, oversized map-key retention, and a permanent memory leak during client teardown. Combined, these vectors permit unauthenticated remote attackers to trigger out-of-memory panics or thread exhaustion.

The technical root cause of the vulnerability lies in how the subscription lifecycle and the underlying network connection upgrades are handled. During a WebSocket protocol upgrade, the HTTP connection is hijacked and transitioned into a stateful WebSocket connection. In affected versions of klever-go, the server did not call the SetReadLimit function on the upgraded network connection. Consequently, the gorilla/websocket library was permitted to read frame payloads of arbitrary size, leading to immediate heap allocation of the incoming payload size.

Simultaneously, the connection tracking logic relied on nested Go maps (h.addressSubscription) to map target addresses to connected client structs. When a client registered interest in an address, a new key was inserted into the outer map. Upon client disconnection, the server executed handleClientDelete to locate the client in the inner map and delete the entry. However, the outer map's key itself was never pruned. This omission left empty map structures in memory, establishing a classic memory leak where each unique subscription address string remained in memory permanently.

Furthermore, the system failed to enforce bounds on the length of input address strings or the total count of addresses submitted in a single request. Attackers could supply arbitrarily long, non-compliant address strings, which were directly converted into map keys. Go's runtime implements map buckets that do not shrink dynamically; storing excessively long garbage keys caused significant memory amplification and heap fragmentation that could not be recovered by the garbage collector.

To understand the precise code-level flaw, we examine the teardown function handleClientDelete as it existed before the patch:

// Vulnerable implementation
func (h *SocketHub) handleClientDelete(c *client) {
	delete(h.blockSubscription, c)
	delete(h.transactionSubscription, c)
	c.close()
	for _, clients := range h.addressSubscription {
		for cl := range clients {
			if cl == c {
				delete(clients, c)
			}
		}
	}
}

In this implementation, the nested inner map clients is iterated, and the target client c is deleted. However, the outer key in h.addressSubscription is never evaluated. If clients becomes empty (i.e., no other active clients are subscribed to that address), the address key remains in the parent map, referencing an empty map allocation.

This architecture is fixed in version 1.7.20 by introducing explicit cleanups on the outer map when the inner map's length reaches zero, alongside input string length constraints. The revised teardown logic performs the following operations:

// Patched implementation
func (h *SocketHub) handleClientDelete(c *client) {
	delete(h.blockSubscription, c)
	delete(h.transactionSubscription, c)
	c.close()
	for addr, clients := range h.addressSubscription {
		delete(clients, c)
		if len(clients) == 0 {
			delete(h.addressSubscription, addr)
		}
	}
	delete(h.clientAddresses, c)
}

By deleting addr from h.addressSubscription when len(clients) == 0, the parent map is successfully pruned, allowing the Go runtime's garbage collector to reclaim both the key string and the map bucket resources.

Exploitation of these vulnerabilities does not require authentication or complex cryptographic negotiation. A remote attacker can target the /subscribe endpoint directly over standard HTTP/HTTPS ports. The most straightforward vector involves an Out-of-Memory (OOM) attack via a single oversized WebSocket frame. By initiating a WebSocket handshake and subsequently transmitting a text frame containing a JSON subscription payload with highly inflated elements, the attacker forces the node to allocate a matching buffer size, exhausting physical memory.

Alternatively, an attacker can exploit the connection management failure. Because WebSocket upgrades bypass standard Gin connection-limiting middleware, an attacker can launch a slow-exhaustion attack by establishing thousands of concurrent TCP connections, upgrading them to WebSockets, and holding them open. This rapidly consumes file descriptors and initiates thousands of concurrent goroutines, halting the network thread of the validator node.

Finally, the memory leak vector (CWE-401) can be exploited dynamically over an extended period. An attacker can programmatically connect, subscribe to thousands of randomized, non-existent address strings, disconnect, and repeat. Since each disconnected session leaves empty keys behind, the node's resident set size (RSS) memory increases monotonically until the operating system's OOM killer terminates the validator daemon.

The impact of CVE-2026-86065 is classified as High (CVSS Base Score: 7.5). The primary impact is on availability, as successful exploitation results in a complete process crash or complete unresponsiveness of the target node. In the context of the Klever blockchain, if validator nodes are targeted, this can result in missed blocks, loss of staking rewards, and potential disruption to the consensus layer of the network.

Because the WebSocket endpoint is typically exposed publicly to allow block explorers, wallets, and dApps to receive real-time updates, the vulnerability can be reached by any entity with network access to the API port. No privileges are required, and the attack complexity is extremely low, requiring no prior knowledge of state or session variables.

There is no impact on confidentiality or integrity, as the vulnerability does not permit remote code execution or unauthorized access to sensitive cryptographic keys. However, the operational impact on node infrastructure makes remediation a critical priority for all network operators running affected versions.

The primary remediation path is upgrading the klever-go daemon to version 1.7.20 or later. This release introduces comprehensive structural safeguards, including a max message size limit on WebSocket frames, global and per-IP connection limits, and correct map key garbage collection on client disconnects.

If an immediate upgrade is not feasible, operators should apply temporary network-level mitigations. This includes implementing a reverse proxy (such as Nginx, HAProxy, or Cloudflare) in front of the API port. The reverse proxy should be configured to limit the maximum allowed body size for WebSocket upgrades, enforce rate limiting on connections, and restrict the absolute number of concurrent open connections per client IP address.

> [!NOTE] > Restricting access to the /subscribe endpoint via firewall rules or firewall-level IP whitelisting is highly recommended for internal nodes or private validators that do not require public WebSocket exposure.