The vulnerability exists in the message processing pipeline of Klever-Go, specifically in how compressed P2P payloads are handled. The root cause is an unbounded decompression in the decompressGzip function located in data/batch/batch.go. This function reads the entire decompressed stream into memory without any limits, making it vulnerable to a "decompression bomb" attack where a small, highly-compressed payload can expand to consume a massive amount of memory.
The vulnerable decompressGzip function is called by Batch.Decompress, which is responsible for decompressing batch data. The attack is triggered when a remote peer sends a malicious gossip message to a topic served by MultiDataInterceptor. The MultiDataInterceptor.ProcessReceivedMessage function, located in core/process/interceptors/multiDataInterceptor.go, receives the message and calls Batch.Decompress.
A critical flaw in the logic is that the anti-flood defenses, which are meant to prevent resource exhaustion attacks, are ineffective. The size of the incoming message is checked before decompression, so a small compressed bomb passes the check. The check for the number of items in the batch occurs after the memory-exhausting decompression has already happened. This allows an unauthenticated remote attacker to cause an Out-Of-Memory (OOM) crash on the node with a single, small packet, leading to a denial of service.