Listen to this Post
How the Mentioned CVE Works
This vulnerability exists in the deprecated `OpenTelemetry.Exporter.Jaeger` package for .NET. The core issue resides in how the exporter manages pooled-list structures during the conversion of OpenTelemetry spans into the Jaeger format. When the exporter processes a telemetry span, it appends tag and event data into internal pooled lists. If a single span contains an unusually large set of tags or events, the exporter allocates a larger list to accommodate this data. This oversized list is then returned to a global pool for reuse. The critical flaw is that this enlarged allocation size persists and is reused for all subsequent trace exports, regardless of the size of future spans. This creates a scenario where a single, attacker-influenced large payload causes the exporter to “learn” an oversized memory footprint. As the exporter processes telemetry under high-cardinality or attacker-controlled input, this permanently inflated allocation pattern leads to sustained, elevated memory pressure. Over time, this persistent oversizing results in a steady increase in the application’s private memory working set. Unlike a traditional memory leak where objects are not freed, this is a logical inefficiency where the allocator retains an excessively large but valid memory buffer. In environments where telemetry attributes can be influenced by untrusted input and default limits on span attributes are increased, this memory pressure can grow unchecked. The cumulative effect can lead to process instability, out-of-memory (OOM) conditions, and ultimately a denial of service, as the application consumes more and more host memory without releasing it. The Jaeger exporter was deprecated in 2023, and there is no plan to issue a fix for this behavior.
dailycve form:
Platform: .NET (NuGet)
Version: <=1.6.0-rc.1
Vulnerability: Memory pressure DoS
Severity: Medium
Date: 2026-04-18
Prediction: No patch expected
What Undercode Say:
To test for exposure, you can check your project dependencies:
Check for vulnerable Jaeger exporter package in a .NET project dotnet list package --vulnerable --include-transitive | findstr OpenTelemetry.Exporter.Jaeger
To simulate high-cardinality telemetry that could trigger the memory issue (conceptual):
Python-like pseudocode for generating large, randomized span attributes
import random
span.set_attribute("a"10000, "b"10000) Oversized tag set
To monitor memory pressure on a Linux host running a vulnerable application:
Watch memory usage of the process over time
while true; do ps aux | grep "YourAppName" | awk '{print $6}' ; sleep 5; done
Or use top to see RES (resident memory) growth
top -p $(pgrep -d',' YourAppName) -o %MEM
Exploit:
An attacker who can influence telemetry data ingested by an application using the vulnerable Jaeger exporter could send a single crafted span containing an extremely large number of tags or a single tag with a very long value. The exporter, upon processing this payload, would allocate an oversized internal list to hold the tag data. Because this enlarged list is returned to a global pool and reused for subsequent traces, all later, legitimate spans would cause the exporter to allocate memory as if they were equally large, drastically inflating the application’s memory footprint. By repeating this process or by sending a steady stream of high-cardinality data, an attacker could cause the application’s memory usage to grow linearly with the number of traces, eventually leading to an out-of-memory crash and denial of service.
Protection from this CVE
- Switch to a Supported Exporter: The primary and most effective mitigation is to migrate away from the deprecated Jaeger exporter. Use the OpenTelemetry Protocol (OTLP) exporter instead, which is actively maintained.
- Implement Resource Limits: If migration is not immediately possible, enforce strict limits on span attributes and events within the OpenTelemetry SDK configuration (e.g., limiting the maximum number of attributes per span and the maximum length of attribute values).
- Deploy Memory Monitoring: Implement robust memory monitoring and alerting on the host to detect anomalous growth patterns that could indicate an attempted exploitation.
Impact:
Availability: High. Successful exploitation leads to increased memory pressure, process instability, and potential denial of service. Confidentiality: None. Integrity: None. The vulnerability does not allow data theft or modification.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
