CVE-2026-41078

MEDIUM

Uncontrolled Resource Consumption (CWE-400)

2026-04-18 https://github.com/open-telemetry/opentelemetry-dotnet

GHSA-38h3-2333-qx47

Denial Of Service

5.9

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

5.9 MEDIUM

AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Apr 18, 2026 - 01:22 vuln.today

Analysis Generated

Apr 18, 2026 - 01:15 vuln.today

CVE Published

Apr 18, 2026 - 01:05 nvd

MEDIUM 5.9

DescriptionGitHub Advisory

Summary

> [!IMPORTANT] > There is no plan to fix this issue as OpenTelemetry.Exporter.Jaeger was deprecated in 2023. It is for informational purposes only.

OpenTelemetry.Exporter.Jaeger may allow sustained memory pressure when the internal pooled-list sizing grows based on a large observed span/tag set and that enlarged size is reused for subsequent allocations. Under high-cardinality or attacker-influenced telemetry input, this can increase memory consumption and potentially cause denial of service.

Details

The Jaeger exporter conversion path can append tag/event data into pooled list structures. In affected versions, pooled allocation sizing may be influenced by large observed payloads and reused globally across later allocations, resulting in persistent oversized rentals and elevated memory pressure. In environments where telemetry attributes/events can be influenced by untrusted input and limits are increased from defaults, this may lead to process instability or denial of service.

Impact

Availability impact only. Confidentiality and integrity impacts are not expected.

Workarounds / Mitigations

Prefer maintained exporters (for example OpenTelemetry Protocol format (OTLP)) instead of the Jaeger exporter.

AnalysisAI

OpenTelemetry.Exporter.Jaeger allows memory exhaustion and denial of service when processing high-cardinality or attacker-influenced telemetry data due to pooled list structures that retain oversized allocations across subsequent requests. The affected .NET NuGet package may experience sustained memory pressure if telemetry attributes or events contain large payloads, particularly in environments where input originates from untrusted sources and memory limits are increased from defaults. Notably, this deprecated exporter (end-of-support since 2023) will not receive vendor patches and users should migrate to maintained alternatives such as OpenTelemetry Protocol (OTLP) exporters.

Technical ContextAI

The vulnerability resides in the Jaeger exporter conversion logic within the OpenTelemetry .NET instrumentation library (pkg:nuget/opentelemetry.exporter.jaeger). The exporter appends span and tag data into pooled list structures to optimize memory allocation. The underlying issue (CWE-400: Uncontrolled Resource Consumption) occurs because the pool's sizing mechanism does not decay or reset when processing payloads larger than the initial pool size. Once a large span or tag set is observed, the pool retains that enlarged size for all subsequent allocations globally, even for smaller payloads. This creates persistent over-allocation and memory fragmentation. Environments that accept telemetry from external or untrusted sources-common in service meshes, Kubernetes clusters, and multi-tenant platforms-amplify the risk by allowing attackers to craft spans with high-cardinality tag sets or extremely large event payloads to trigger this memory-sizing vulnerability.

RemediationAI

Primary remediation is immediate migration away from the deprecated OpenTelemetry.Exporter.Jaeger to a maintained exporter, preferably OpenTelemetry Protocol (OTLP) format exporter, which does not exhibit this pooling vulnerability. No patch will be released for the Jaeger exporter due to deprecation. For organizations unable to migrate immediately, implement strict input validation and cardinality limits on telemetry attributes and events before they reach the exporter-use OpenTelemetry SDK span processors or collectors (e.g., OpenTelemetry Collector) to enforce maximum attribute counts, event counts, and tag value lengths. Additionally, configure memory resource limits (via container orchestration, AppDomain MaxMemory, or process resource controls) to contain potential memory bloat and trigger graceful shutdown rather than cascading system failure. Monitor heap size and pooled allocation growth via .NET performance counters to detect exploitation attempts. These mitigations carry the operational cost of potential span data loss (if limits are enforced) and added latency (if validation is done in-process), and do not eliminate the underlying vulnerability-they only reduce attack surface and blast radius.