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:
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:
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:
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
leduckhuong Reporter
Summary
A connected peer can send a compressed
RequestDataType_HashArrayTypedirect request that is only442bytes on the wire but expands into200000decoded hash entries inside the resolver path. Onklever-gov1.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()indata/batch/batch.go#L122enforces an inflated byte cap but does not enforce a decoded repeated-field item cap. After decompression,TxResolverpreallocates and iterates all decoded hashes indata/retriever/resolvers/transactionResolver.go#L194, andTrieNodeResolveriterates the same unchecked decoded set indata/retriever/resolvers/trieNodeResolver.go#L108.Pinned references:
This appears distinct from the public
CVE-2026-44697/GHSA-87m7-qffr-542v, which coveredMultiDataInterceptorcompressed batch fan-in. This report concerns resolver request paths that remain reachable through real libp2p direct-send plumbing onv1.7.17.PoC
Reproduced with:
go run auditpoc/request_batch_hash_amplification_poc.go go test github.com/klever-io/klever-go/auditpoc -run TestRequestBatchHashAmplification_DirectSendReachability -count=1Observed output:
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