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: 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.