Loading story…
Two OpenTelemetry OTLP exporter implementations were found vulnerable to denial-of-service conditions that can exhaust application memory through malicious HTTP responses from a telemetry collector. CVE-2026-39882 affects the OpenTelemetry-Go OTLP HTTP exporters, where a compromised collector endpoint or an attacker performing a man-in-the-middle attack can keep the export connection open and stream an effectively infinite response body; the client buffers the payload during an io.Copy operation and can run out of memory before protocol parsing begins.
A related flaw, CVE-2026-40182, impacts the OpenTelemetry .NET OTLP exporter in opentelemetry-dotnet versions 1.13.1 through 1.15.1. In that case, error-handling logic reads an entire failed export response into memory for diagnostic logging when a collector rejects a request, allowing a malicious backend or adjacent-network attacker to trigger uncontrolled allocation and crash the host process. Proof-of-concept data for the Go issue showed unpatched clients peaking at 118,050,512 bytes of allocation with a 33,554,432-byte test payload, while patched clients used only 512,232 bytes under the same conditions.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
A separate unbounded memory exhaustion denial-of-service flaw, tracked as CVE-2026-40182, was disclosed in the OpenTelemetry .NET OTLP exporter affecting opentelemetry-dotnet versions 1.13.1 through 1.15.1. The issue occurs when error-handling logic reads an entire failure response into memory for diagnostic logging, enabling memory exhaustion if an attacker controls or intercepts the backend endpoint.
A memory exhaustion denial-of-service vulnerability, tracked as CVE-2026-39882, was disclosed in the OpenTelemetry-Go OTLP HTTP exporters. The flaw allows a malicious or intercepted collector response to keep a connection open and stream an unbounded body, causing the client to buffer data until memory is exhausted.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
cvereports.com
Open sourcecvereports.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Red Hat released updated **OpenTelemetry Collector** packages for RHEL 9 and RHEL 10 to remediate denial-of-service and memory-exhaustion vulnerabilities in bundled Go dependencies. The updates address `CVE-2025-27144` in Go JOSE parsing, `CVE-2025-22868`, `CVE-2025-29786`, and `CVE-2025-30204`; the RHEL 9 advisory also covers `CVE-2024-45336`, which could expose sensitive HTTP headers through a cross-domain redirect. Fixed packages are `opentelemetry-collector-0.107.0-8.el9_6` for RHEL 9 and `opentelemetry-collector-0.107.0-9.el10_0` for RHEL 10, across x86_64, s390x, ppc64le, and aarch64 systems. The same vulnerable dependencies affected Red Hat OpenShift products. OpenShift Container Platform 4.17.22 fixes the Go JOSE parsing DoS issue, while Logging for OpenShift 5.9.13 addresses denial-of-service and local-file-inclusion flaws in Net::IMAP, Rack::Static, Go JOSE, and `golang-jwt/jwt`. Red Hat also shipped updated OpenShift Container Platform 4.14.51 and OpenShift Data Foundation images, including fixes for `CVE-2025-30204`; administrators should apply the relevant RHEL package, OpenShift release, logging-stack, and container-image updates through supported channels.
Aug 27, 2026
Okta's Red Team disclosed **HollowByte**, a denial-of-service flaw in OpenSSL that lets a remote, unauthenticated attacker send a malicious TLS handshake as small as **11 bytes** and trigger excessive memory allocation. The issue affects older OpenSSL versions that trust an attacker-controlled handshake length and pre-allocate buffers before validating the full payload, allowing repeated requests to block worker threads and drive up memory consumption on exposed services such as **NGINX**. Researchers said repeated exploitation with randomized claimed sizes can cause severe heap fragmentation in `glibc`, leading to persistent resident memory growth even after connections close and, in testing, leaving systems vulnerable to **OOM** conditions or large amounts of locked-up memory while staying below normal connection limits. OpenSSL fixed the bug by switching to incremental buffer growth and backported the change to supported branches, with patched releases available in **4.0.1**, **3.6.3**, **3.5.7**, **3.4.6**, and **3.0.21**; defenders are being urged to upgrade promptly despite the flaw not receiving a CVE.
Jul 24, 2026
A newly disclosed denial-of-service flaw in multiple HTTP/2 server implementations allows remote, unauthenticated attackers to exhaust memory and crash services by abusing normal flow-control behavior. By stalling outbound data transmission—such as by manipulating `SETTINGS_INITIAL_WINDOW_SIZE` or withholding `WINDOW_UPDATE` frames—an attacker can cause vulnerable servers to keep generating and buffering full responses, leading to out-of-memory conditions, swap thrashing, worker-thread exhaustion, service freezes, or kernel OOM kills. CERT/CC is tracking the issue after it was reported by the Okta Red Team, and the coordinated disclosures include `CVE-2026-44909`, `CVE-2026-59173`, and `CVE-2026-59762`. Affected vendors named in advisories include Apache Traffic Server, Citrix, F5 Networks, Meta, Red Hat, SUSE, and Yahoo. Apache Traffic Server users were advised to upgrade to versions `9.1.14` or `10.1.3`, while F5 published guidance for BIG-IP and other vendors issued product-specific fixes or mitigations. Recommended defenses include stricter memory limits, limiting concurrent HTTP/2 streams, terminating stalled connections, and improving timeout and backpressure handling. No public exploitation has been confirmed, but the low complexity of the attack has prompted calls for rapid patching and configuration hardening.
Jul 24, 2026