Skip to main content

Klever-Go CVE-2026-52879

HIGH
Uncontrolled Resource Consumption (CWE-400)
2026-08-07 GitHub_M
7.5
CVSS 3.1 · Vendor: GitHub_M
Share

Severity by source

Vendor (GitHub_M) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
7.5 HIGH

Any reachable libp2p peer qualifies with no credentials; well-formed messages suffice; impact is availability-only with no scope change.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

3
Source Code Evidence Fetched
Aug 07, 2026 - 23:21 vuln.today
Analysis Generated
Aug 07, 2026 - 23:21 vuln.today
CVE Published
Aug 07, 2026 - 22:36 cve.org
HIGH 7.5

DescriptionCVE.org

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.

AnalysisAI

Unbounded goroutine exhaustion in Klever-Go versions 1.7.14-1.7.17 allows any connected libp2p peer to remotely degrade or deny service to a Klever blockchain node by flooding it with well-formed direct messages. The root defect is architectural: directMessageHandler in network/p2p/libp2p/netMessenger.go spawns an unrestricted goroutine per incoming message before the processor-level antiflood layer can reject it, meaning admission control is structurally bypassed at ingress. No public exploit code has been identified at time of analysis, though the GHSA advisory provides a precise code walkthrough that substantially lowers exploitation complexity. The fix is available in v1.7.18.

Technical ContextAI

Klever-Go is the Go-language node implementation of the Klever blockchain protocol, identified by CPE cpe:2.3:a:klever-io:klever-go:*:*:*:*:*:*:*:*. The network layer is built on libp2p and routes peer-to-peer messages through networkMessenger.directMessageHandler in network/p2p/libp2p/netMessenger.go. The flaw is classified as CWE-400 (Uncontrolled Resource Consumption): each incoming direct message unconditionally triggers go func(msg p2p.MessageP2P) before processor.ProcessReceivedMessage - which houses the antiflood admission check - ever executes. Every spawned goroutine allocates its own stack frame and retains a reference to the cloned message until ProcessReceivedMessage returns, meaning goroutines accumulate faster than the Go runtime scheduler and garbage collector can drain them. This is architecturally distinct from previously patched issues GHSA-74m6-4hjp-7226 and GHSA-87m7-qffr-542v, which targeted MultiDataInterceptor and Batch.Decompress; those patches do not bound the direct-message goroutine spawn path.

RemediationAI

The vendor-released patch is v1.7.18, available at https://github.com/klever-io/klever-go/releases/tag/v1.7.18. Node operators should upgrade to v1.7.18 promptly; the release notes confirm no consensus-breaking changes, no configuration migration, and behavioral compatibility with v1.7.17. If immediate upgrade is not possible, network-layer mitigations should focus on restricting which peers can initiate direct-send streams to the node - for example, configuring firewall rules or libp2p peer allowlists to limit the P2P port (typically TCP 37373 or operator-configured) to trusted IP ranges or known validator peers. This reduces the attack surface by preventing untrusted peers from reaching directMessageHandler, though it also restricts normal peer-to-peer connectivity. No other application-layer workaround short of patching addresses the root architectural issue of unbounded pre-antiflood goroutine spawning.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

Share

CVE-2026-52879 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy