CVE-2026-86064 in Klever-Go
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 /log WebSocket route configured in config/node/api.yaml and registered by network/api/api.go does not require authentication. The first client message is parsed as a logger Profile in network/api/logs/logSender.go and applied process-wide through Profile.Apply, allowing a remote client to change global log levels and formatting options until the connection closes. The same connection is registered as a log observer and can receive live process logs. An attacker can suppress normal logs, increase verbosity, distort operator visibility, and access operational information without credentials. This issue is fixed in version 1.7.20.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The Klever-Go blockchain protocol implementation contains a critical authentication bypass vulnerability within its WebSocket API interface prior to version 1.7.20. The specific flaw resides in the GET /log endpoint, which was configured by default as an open route without requiring any form of client authentication or authorization checks. This configuration is defined in the node's api.yaml file and registered via the network/api/api.go module. Because this WebSocket route lacks security controls, it allows unauthenticated remote actors to establish a persistent connection with the blockchain node’s logging subsystem. The vulnerability stems from the application logic that immediately parses the first message received over this connection as a logger Profile object in the logSender.go file. Once parsed, the Apply method is invoked process-wide, effectively applying the attacker-supplied configuration changes across the entire running instance of the Klever-Go software without any validation of the sender's identity or permissions.
The operational impact of this vulnerability is severe due to its dual nature as both a denial-of-service vector and an information disclosure mechanism. By manipulating the logger Profile, an unauthenticated attacker can alter global log levels and formatting options for the entire node process until the WebSocket connection remains open. This capability allows malicious actors to suppress critical system logs, thereby obscuring normal operational activities and hindering incident response efforts by security operators who rely on these logs for monitoring and forensics. Conversely, attackers can also increase verbosity to generate excessive log output, potentially leading to resource exhaustion or disk space depletion through a denial-of-service attack. Furthermore, the same WebSocket connection is registered as an observer of live process logs, granting the attacker real-time access to sensitive operational information that should be restricted to authorized administrators only. This exposure compromises the confidentiality and integrity of system operations by allowing external parties to view internal state changes, network events, and other proprietary data without credentials.
From a security architecture perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the application fails to verify the identity of users attempting to access sensitive functionality. Additionally, it relates to CWE-16 Configuration, specifically involving default configurations that lack necessary security controls for exposed interfaces. In terms of adversary tactics, this flaw facilitates ATT&CK technique T1078 Valid Accounts if an attacker were to eventually gain credentials, but more immediately supports T1534 Internal Spearphishing or lateral movement preparation by allowing the attacker to blend in with normal traffic and gather intelligence on internal network structures and operational patterns. The ability to suppress logs also aids ATT&CK technique T1070 Indicator Removal on Host, as it allows an intruder to hide their presence from detection systems that rely on log analysis.
To mitigate this vulnerability, organizations running Klever-Go versions prior to 1.7.20 must upgrade immediately to version 1.7.20 or later, where the authentication requirement for the /log WebSocket route has been implemented. Until an upgrade is feasible, administrators should consider network-level mitigations such as restricting access to the API port using firewall rules or reverse proxy configurations that enforce IP whitelisting or token-based validation before requests reach the application layer. It is also advisable to audit other WebSocket endpoints within the Klever-Go architecture to ensure they do not share similar authentication deficiencies, ensuring a defense-in-depth approach to securing blockchain node interfaces against unauthorized access and manipulation.