Answer in brief
CVE-2026-52879 records a High severity (CVSS 7.5) vulnerability in Klever-Go: Unbounded goroutine spawn on direct-message ingress enables peer-driven DoS. The current sources do not mark it as known exploited. The current feed maps klever-io/klever-go (generic), github.com/klever-io/klever-go (go). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps klever-io/klever-go (generic), github.com/klever-io/klever-go (go). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| klever-io/klever-gogeneric | >= 1.7.14, < 1.7.18 | Not reported |
| github.com/klever-io/klever-gogo | >=1.7.14,<=1.7.17 | 1.7.18 |
Published upstream
Aug 7, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 9, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 11, 2026
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.
Quoted source text, attributed separately from HOL analysis.