What is the CVSS score of CVE-2026-47249?

CVE-2026-47249 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.1%.

Which versions of klever-go are affected by CVE-2026-47249?

klever-go v1.7.17 is vulnerable to remote denial of service attacks from P2P network peers that can exhaust validator node resources through malicious compressed message expansion; publicly available…. A patch is available.

How to fix or mitigate CVE-2026-47249?

Within 24 hours: (1) Inventory all systems running klever-go v1.7.17; (2) Implement network segmentation restricting P2P peer connections to known trusted sources only; (3) Deploy rate limiting on incoming P2P messages. Within 7 days: (1) Implement per-peer connection limits and concurrent connection caps; (2) Configure alerting for abnormal memory and CPU consumption patterns; (3) Contact klever-go vendor for patch status and recommended interim configurations. Within 30 days: (1) Establish upgrade plan upon vendor patch release; (2) Evaluate alternative P2P implementations if patch timeline remains undefined.

klever-go CVE-2026-47249

HIGH

Uncontrolled Resource Consumption (CWE-400)

2026-06-05 https://github.com/klever-io/klever-go

GHSA-w342-mj6g-v9c4

Denial Of Service

7.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 05, 2026 - 15:52 vuln.today

Analysis Generated

Jun 05, 2026 - 15:52 vuln.today

DescriptionGitHub Advisory

Summary

A connected peer can send a compressed RequestDataType_HashArrayType direct request that is only 442 bytes on the wire but expands into 200000 decoded hash entries inside the resolver path. On klever-go v1.7.17, this allows remote memory and CPU amplification against nodes that accept P2P peer connections.

Details

Resolver antiflood logic accounts only one logical message and the compressed wire size in data/retriever/resolvers/messageProcessor.go#L30.

Batch.Decompress() in data/batch/batch.go#L122 enforces an inflated byte cap but does not enforce a decoded repeated-field item cap. After decompression, TxResolver preallocates and iterates all decoded hashes in data/retriever/resolvers/transactionResolver.go#L194, and TrieNodeResolver iterates the same unchecked decoded set in data/retriever/resolvers/trieNodeResolver.go#L108.

Pinned references:

https://github.com/klever-io/klever-go/blob/333f6ec910906e227705fc5767dc897d8fbfc862/data/retriever/resolvers/messageProcessor.go#L30
https://github.com/klever-io/klever-go/blob/333f6ec910906e227705fc5767dc897d8fbfc862/data/batch/batch.go#L122
https://github.com/klever-io/klever-go/blob/333f6ec910906e227705fc5767dc897d8fbfc862/data/retriever/resolvers/transactionResolver.go#L194
https://github.com/klever-io/klever-go/blob/333f6ec910906e227705fc5767dc897d8fbfc862/data/retriever/resolvers/trieNodeResolver.go#L108

This appears distinct from the public CVE-2026-44697 / GHSA-87m7-qffr-542v, which covered MultiDataInterceptor compressed batch fan-in. This report concerns resolver request paths that remain reachable through real libp2p direct-send plumbing on v1.7.17.

PoC

Reproduced with:

bash

go run auditpoc/request_batch_hash_amplification_poc.go
go test github.com/klever-io/klever-go/auditpoc -run TestRequestBatchHashAmplification_DirectSendReachability -count=1

Observed output:

text

request wire bytes: 442
fits direct-send limit (983040 bytes): true
tx resolver lookups: 200000
trie resolver lookups: 200000
heap delta before first tx lookup: 17.47 MiB
ok   github.com/klever-io/klever-go/auditpoc

The E2E harness registers the victim resolver on the request topic and sends the malicious payload through SendToConnectedPeer() to prove the work amplification survives the real direct-send path.

Impact

A connected peer can convert a sub-kilobyte request into large decode-time memory pressure and synchronous CPU work on the target node. Repeated requests or several concurrent peers can degrade or exhaust validator resources, affecting node availability.

AnalysisAI

Remote denial of service in klever-go v1.7.17 allows any connected P2P peer to send a 442-byte compressed RequestDataType_HashArrayType message that expands into 200,000 decoded hash entries, driving roughly 156 MiB of heap pressure and synchronous CPU work per request inside TxResolver and TrieNodeResolver. The flaw stems from antiflood logic that only counts compressed wire size, leaving validator nodes exposed to resource exhaustion from repeated or concurrent malicious requests. Publicly available exploit code exists (vendor-published PoC) but the issue is not in CISA KEV; EPSS data was not provided.

Technical ContextAI

klever-go is the Go implementation of the Klever blockchain node, built on libp2p for peer-to-peer messaging and using protobuf-based compressed Batch messages for request/response data between nodes. The root cause is CWE-400 (Uncontrolled Resource Consumption) in the resolver request path: messageProcessor.go counts only one logical message and the compressed byte size, while Batch.Decompress() in data/batch/batch.go enforces an inflated byte cap but no cap on the number of decoded repeated-field items. TxResolver.requestTopicHandler and TrieNodeResolver then preallocate and iterate the entire unchecked decoded hash slice, producing a classic decompression/zip-bomb-style amplification (~442 bytes in → ~200k entries and ~17 MiB initial heap delta out per request). The CPE pkg:go/github.com_klever-io_klever-go identifies the affected Go module.

RemediationAI

Vendor-released patch: upgrade klever-go to v1.7.18 (https://github.com/klever-io/klever-go/releases/tag/v1.7.18), which caps the decoded item count in Batch.Decompress via MaxItemsPerBatch = 8192, closing the amplification in TxResolver and TrieNodeResolver as well as four other coordinated-disclosure DoS issues - the release notes confirm no configuration changes, data migration, or breaking behavior, so node operators should upgrade promptly. Until v1.7.18 is rolled out, compensating controls include tightening libp2p peer admission (restrict accepted inbound peers to a known validator/operator allowlist so unknown peers cannot reach the resolver request topic), lowering the resolver direct-send size budget below the current 983,040-byte limit to shrink the achievable amplification ratio, and adding host-level memory/CPU watchdogs with automatic restart - each control trades off topology flexibility and may disconnect legitimate peers, so they are stopgaps rather than substitutes for the patch. Full details are in the GHSA advisory at https://github.com/klever-io/klever-go/security/advisories/GHSA-w342-mj6g-v9c4 and the GitHub mirror at https://github.com/advisories/GHSA-w342-mj6g-v9c4.