GHSA-w342-mj6g-v9c4
Klever-Go KVM: Hash-array amplification in P2P resolver request handling
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| Go | github.com/klever-io/klever-go | < 1.7.18 | 1.7.18 |
Details
As written in the advisory (Markdown source, shown as plain text).
### 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.
References
External links from the advisory. They lead to third-party sites.