CVE-2026-86065 in Klever-Goinfo

Summary

by MITRE • 09/23/2026

Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.20, the default-open GET /subscribe endpoint in network/api/websocket/routes.go accepts unauthenticated WebSocket clients with permissive origin handling, does not call SetReadLimit to bound message size, and has no live-connection cap. SocketHub.HandleClientInsertion also accepts an unbounded address list that grows addressSubscription, and client.loopIn continues reading without a size limit, allowing one client to grow subscription maps or many clients to retain goroutines, buffered channels, and descriptors. The global HTTP request throttler does not count upgraded live WebSocket connections. Because the REST and WebSocket API runs in the node process, memory or scheduler exhaustion can crash the node and interrupt P2P and consensus participation. This issue is fixed in version 1.7.20.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 09/23/2026

The Klever-Go blockchain protocol implementation contains a critical resource management vulnerability within its WebSocket server infrastructure that enables denial of service attacks through unbounded resource consumption. Prior to version 1.7.20, the default-open GET /subscribe endpoint located in network/api/websocket/routes.go fails to enforce essential security controls for incoming connections. Specifically, this endpoint accepts unauthenticated WebSocket clients without verifying their origin headers, allowing any external actor to establish a persistent connection to the node's API layer. This lack of access control combined with permissive origin handling creates an open channel for malicious actors to interact directly with the blockchain node's internal services without authentication or restriction.

The technical flaw centers on the absence of message size limits and live-connection caps within the WebSocket handler logic. The code does not invoke SetReadLimit, which is a standard Go net/http package function used to restrict the maximum size of incoming messages. Consequently, client.loopIn continues reading data from connected clients without any upper bound on payload size. This allows a single malicious client to send excessively large messages that consume significant memory resources within the node process. Furthermore, SocketHub.HandleClientInsertion accepts an unbounded address list that grows the internal addressSubscription map indefinitely as new subscriptions are added. There is no mechanism in place to cap the number of active live connections or limit the depth of subscription maps, leading to linear and potentially exponential resource growth depending on client behavior.

The operational impact of these deficiencies extends beyond simple memory exhaustion. Because each accepted WebSocket connection spawns a goroutine that retains buffered channels and file descriptors, an attacker can trigger scheduler exhaustion by opening thousands of simultaneous connections. The global HTTP request throttler fails to account for upgraded live WebSocket connections in its rate-limiting calculations, meaning the standard protections against high-frequency API requests do not apply to these persistent sessions. As both REST and WebSocket APIs run within the same node process as the core blockchain logic, resource exhaustion at this layer directly compromises the stability of the entire node. This can lead to a complete crash of the Klever-Go binary, resulting in an interruption of peer-to-peer network participation and consensus mechanism engagement. Such disruptions effectively take the node offline, potentially impacting network availability and consistency for other participants relying on that validator or full node.

This vulnerability aligns with CWE-787 Out-of-bounds Read and CWE-400 Uncontrolled Resource Consumption within the Common Weakness Enumeration framework. From an offensive security perspective, it maps to MITRE ATT&CK technique T1496 Resource Hijacking, where attackers consume system resources to degrade service availability for legitimate users. The lack of authentication on a data-access endpoint also reflects CWE-306 Missing Authentication for Critical Function. To mitigate this risk, organizations running Klever-Go versions prior to 1.7.20 must upgrade immediately to version 1.7.20 or later where these controls have been implemented. In the interim, deploying network-level firewalls to restrict WebSocket traffic to known trusted IP addresses and implementing reverse proxy configurations that enforce connection limits and message size restrictions can provide partial protection against exploitation until a software patch is applied.

Responsible

GitHub M

Reservation

09/04/2026

Disclosure

09/23/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to know what is going to be exploited?

We predict KEV entries!