CVE-2026-44697

Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.17, a remote, unauthenticated denial-of-service vulnerability in Batch.Decompress (data/batch/batch.go) allows any peer that participates in a topic served by MultiDataInterceptor to allocate multi-gigabyte heaps on the receiving node from a sub-50 KiB gossip payload. A single packet is sufficient to OOM-kill a validator with conventional memory provisioning. Fleet-wide application affects chain liveness. This vulnerability is fixed in 1.7.17.

Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.17, a remote, unauthenticated denial-of-service vulnerability in Batch.Decompress (data/batch/batch.go) allows any peer that participates in a topic served by MultiDataInterceptor to allocate multi-gigabyte heaps on the receiving node from a sub-50 KiB gossip payload. A single packet is sufficient to OOM-kill a validator with conventional memory provisioning. Fleet-wide application affects chain liveness. This vulnerability is fixed in 1.7.17.

Summary

A remote, unauthenticated denial-of-service vulnerability in Batch.Decompress (data/batch/batch.go) allows any peer that participates in a topic served by MultiDataInterceptor to allocate multi-gigabyte heaps on the receiving node from a sub-50 KiB gossip payload. A single packet is sufficient to OOM-kill a validator with conventional memory provisioning. Fleet-wide application affects chain liveness.

The vulnerability was identified during an internal security review of core/process/interceptors/multiDataInterceptor.go at commit 405d01b0abbf0d3e73b4a990bd7394a01f200dc2. It is distinct from, and substantially more severe than, the throttler-slot-leak vulnerability disclosed in GHSA-74m6-4hjp-7226. Both reports cover adjacent code in the same call path; the patches must land together in one release (rc2 superseding rc1).

Two additional, lower-severity hardening issues affecting the same code path are documented in this report and remediated by the same patch. They are not independently exploitable under the default deployed anti-flood configuration and are not requested as separate CVEs.

Description

MultiDataInterceptor.ProcessReceivedMessage (core/process/interceptors/multiDataInterceptor.go:79) handles every gossip message received on the topics the interceptor is registered for. At lines 95–102 it conditionally decompresses the payload via Batch.Decompress:

if b.IsCompressed {
    err = b.Decompress(mdi.marshalizer)
    if err != nil { ... return err }
}

Batch.Decompress (data/batch/batch.go:109) delegates the gzip step to decompressGzip (data/batch/batch.go:35-53), which performs an unbounded io.ReadAll on the gzip reader:

func decompressGzip(data []byte) ([]byte, error) {
    rdata := bytes.NewReader(data)
    reader, err := gzip.NewReader(rdata)
    if err != nil { return nil, err }
    result, err := io.ReadAll(reader)   // no LimitReader, no DataSize check
    ...
}

After the gzip step succeeds, Decompress re-Unmarshals the inflated bytes back into the Batch value, again with no size cap. The attacker-set ba.DataSize field is never validated on decompression, so the lie is free.

The order of operations in ProcessReceivedMessage:

preProcessMessage              -> anti-flood by COMPRESSED size only
marshalizer.Unmarshal(&b, ..)  -> outer Batch (small, cheap)
b.Decompress(...)              -> UNBOUNDED here  (bomb explodes)
... b.Data populated with N entries ...
antiflood.CanProcessMessagesOnTopic(..., uint32(len(b.Data)), ...)

The count-budget anti-flood check at line 111 runs after Decompress completes, so no anti-flood configuration can prevent the explosion. The only gate above Decompress is preProcessMessage's byte budget, which sees only the compressed payload size and is trivially satisfied by a sub-MB bomb.

Proof of Concept

The PoC is a self-contained Go test that exercises the real data/batch.Batch.Decompress function and the production factory.ProtoMarshalizer. No mocks. Both the attacker-side construction (marshal a Batch of millions of empty entries, gzip, wrap in an outer compressed Batch) and the receiver-side path (mrs.Unmarshal → received.Decompress(mrs)) are exactly what runs in production at the reviewed commit.

The headline test (TestC2_DecompressionBomb_ValidInner) constructs a ~48 KiB outer wire payload that decompresses to 25 million []byte entries, and samples runtime.HeapAlloc every 5 ms during Decompress to capture the peak (since the inflated buffer is freed once Decompress returns).

Test source

Place the file under playground/p2pflood/c2_decompression_bomb_test.go in a checkout of the reviewed commit, then run:

go test -v -count=1 -timeout=120s -run TestC2 ./playground/p2pflood/...

package p2pflood_test

import (
	"bytes"
	"compress/gzip"
	"runtime"
	"sync/atomic"
	"testing"
	"time"

	"github.com/klever-io/klever-go/data/batch"
…

Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.17, a remote, unauthenticated denial-of-service vulnerability in Batch.Decompress (data/batch/batch.go) allows any peer that participates in a topic served by MultiDataInterceptor to allocate multi-gigabyte heaps on the receiving node from a sub-50 KiB gossip payload. A single packet is sufficient to OOM-kill a validator with conventional memory provisioning. Fleet-wide application affects chain liveness. This vulnerability is fixed in 1.7.17.

Klever-Go is the Go implementation of the Klever blockchain protocol. Prior to 1.7.17, a remote, unauthenticated denial-of-service vulnerability in Batch.Decompress (data/batch/batch.go) allows any peer that participates in a topic served by MultiDataInterceptor to allocate multi-gigabyte heaps on the receiving node from a sub-50 KiB gossip payload. A single packet is sufficient to OOM-kill a validator with conventional memory provisioning. Fleet-wide application affects chain liveness. This vulnerability is fixed in 1.7.17.

Summary

A remote, unauthenticated denial-of-service vulnerability in Batch.Decompress (data/batch/batch.go) allows any peer that participates in a topic served by MultiDataInterceptor to allocate multi-gigabyte heaps on the receiving node from a sub-50 KiB gossip payload. A single packet is sufficient to OOM-kill a validator with conventional memory provisioning. Fleet-wide application affects chain liveness.

The vulnerability was identified during an internal security review of core/process/interceptors/multiDataInterceptor.go at commit 405d01b0abbf0d3e73b4a990bd7394a01f200dc2. It is distinct from, and substantially more severe than, the throttler-slot-leak vulnerability disclosed in GHSA-74m6-4hjp-7226. Both reports cover adjacent code in the same call path; the patches must land together in one release (rc2 superseding rc1).

Two additional, lower-severity hardening issues affecting the same code path are documented in this report and remediated by the same patch. They are not independently exploitable under the default deployed anti-flood configuration and are not requested as separate CVEs.

Description

MultiDataInterceptor.ProcessReceivedMessage (core/process/interceptors/multiDataInterceptor.go:79) handles every gossip message received on the topics the interceptor is registered for. At lines 95–102 it conditionally decompresses the payload via Batch.Decompress:

if b.IsCompressed {
    err = b.Decompress(mdi.marshalizer)
    if err != nil { ... return err }
}

Batch.Decompress (data/batch/batch.go:109) delegates the gzip step to decompressGzip (data/batch/batch.go:35-53), which performs an unbounded io.ReadAll on the gzip reader:

func decompressGzip(data []byte) ([]byte, error) {
    rdata := bytes.NewReader(data)
    reader, err := gzip.NewReader(rdata)
    if err != nil { return nil, err }
    result, err := io.ReadAll(reader)   // no LimitReader, no DataSize check
    ...
}

After the gzip step succeeds, Decompress re-Unmarshals the inflated bytes back into the Batch value, again with no size cap. The attacker-set ba.DataSize field is never validated on decompression, so the lie is free.

The order of operations in ProcessReceivedMessage:

preProcessMessage              -> anti-flood by COMPRESSED size only
marshalizer.Unmarshal(&b, ..)  -> outer Batch (small, cheap)
b.Decompress(...)              -> UNBOUNDED here  (bomb explodes)
... b.Data populated with N entries ...
antiflood.CanProcessMessagesOnTopic(..., uint32(len(b.Data)), ...)

The count-budget anti-flood check at line 111 runs after Decompress completes, so no anti-flood configuration can prevent the explosion. The only gate above Decompress is preProcessMessage's byte budget, which sees only the compressed payload size and is trivially satisfied by a sub-MB bomb.

Proof of Concept

The PoC is a self-contained Go test that exercises the real data/batch.Batch.Decompress function and the production factory.ProtoMarshalizer. No mocks. Both the attacker-side construction (marshal a Batch of millions of empty entries, gzip, wrap in an outer compressed Batch) and the receiver-side path (mrs.Unmarshal → received.Decompress(mrs)) are exactly what runs in production at the reviewed commit.

The headline test (TestC2_DecompressionBomb_ValidInner) constructs a ~48 KiB outer wire payload that decompresses to 25 million []byte entries, and samples runtime.HeapAlloc every 5 ms during Decompress to capture the peak (since the inflated buffer is freed once Decompress returns).

Test source

Place the file under playground/p2pflood/c2_decompression_bomb_test.go in a checkout of the reviewed commit, then run:

go test -v -count=1 -timeout=120s -run TestC2 ./playground/p2pflood/...

package p2pflood_test

import (
	"bytes"
	"compress/gzip"
	"runtime"
	"sync/atomic"
	"testing"
	"time"

	"github.com/klever-io/klever-go/data/batch"
…

Klever-Go MultiDataInterceptor has remote OOM via crafted compressed P2P payload in github.com/klever-io/klever-go

This update for govulncheck-vulndb fixes the following issues:

• Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).

Go CVE Numbering Authority IDs added or updated with aliases:

• GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
• GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
• GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
• GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
• GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
• GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
• GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
• GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
• GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
• GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
• GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
• GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
• GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
• GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
• GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
• GO-2026-5933 GHSA-3g4q-2f67-2gvh
• GO-2026-5934 GHSA-59qp-cfj3-rp64
• GO-2026-5935 GHSA-7856-g3gv-9wq8
• GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
• GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
• GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
• GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
• GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
• GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
• GO-2026-5942 CVE-2026-46600
• GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
• GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
• GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
• GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
• GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
• GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
• GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
• GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
• GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
• GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
• GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
• GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
• GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
• GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
• GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
• GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
• GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
• GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
• GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
• GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
• GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
• GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
• GO-2026-5969 GHSA-g936-7jqj-mwv8
• GO-2026-5970 CVE-2026-56852
• GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
• GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
• GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
• GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
• GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
• GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
• GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
• GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
• GO-2026-5981 GHSA-mqxv-9rm6-w8qc
• GO-2026-5982 GHSA-pqg7-v6wh-3pfp
• GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
• GO-2026-5985 GHSA-7rx3-5wx3-5v76
• GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
• GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
• GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
• GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
• GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
• GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
• GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
• GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
• GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
• GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
• GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
• GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
• GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
• GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
• GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
• GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…