EUVD-2026-25266
GHSA-q834-8qmm-v933
Severity by source
AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Adjacent vector and high complexity because exploitation requires network adjacency plus endpoint control or MitM; no confidentiality or integrity impact applies.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
6DescriptionGitHub Advisory
OpenTelemetry dotnet is a dotnet telemetry framework. From 1.13.1 to before 1.15.2, When exporting telemetry to a back-end/collector over gRPC or HTTP using OpenTelemetry Protocol format (OTLP), if the request results in a unsuccessful request (i.e. HTTP 4xx or 5xx), the response is read into memory with no upper-bound on the number of bytes consumed. This could cause memory exhaustion in the consuming application if the configured back-end/collector endpoint is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response. This vulnerability is fixed in 1.15.2.
AnalysisAI
Memory exhaustion in the OpenTelemetry dotnet OTLP exporter (versions 1.13.1 through 1.15.1) enables a denial-of-service condition when an attacker controls the configured telemetry backend or can MitM the export connection. Both the gRPC and HTTP/protobuf transport paths in OtlpGrpcExportClient and OtlpHttpExportClient read the full HTTP error response body into memory without any size cap, allowing an adversary to return an arbitrarily large body and exhaust the process heap. No active exploitation is confirmed (absent from CISA KEV, EPSS 0.01%), and vendor-released patch 1.15.2 is available.
Technical ContextAI
The vulnerability resides in the NuGet package OpenTelemetry.Exporter.OpenTelemetryProtocol (CPE: cpe:2.3:a:open-telemetry:opentelemetry-dotnet:*:*:*:*:*:*:*:*), specifically in OtlpExportClient.cs. CWE-789 (Uncontrolled Memory Allocation) is the root cause: PR #6564 introduced a TryGetResponseBody helper that reads the HTTP response body via ReadAsStream or ReadAsStringAsync with no byte ceiling whenever a non-200 status code is received, so that operators could see error responses in exporter logs. Both the gRPC export path (OtlpGrpcExportClient) and the HTTP/protobuf path (OtlpHttpExportClient) call this helper on failure. The upstream OpenTelemetry Protocol specification was also updated (opentelemetry-proto PR #781) to mandate that all OTLP clients enforce a 4 MiB default response size limit, codifying the fix as a protocol-level requirement.
RemediationAI
Upgrade the OpenTelemetry.Exporter.OpenTelemetryProtocol NuGet package to version 1.15.2, which applies the fix from PR #7017 (https://github.com/open-telemetry/opentelemetry-dotnet/pull/7017) adding an explicit byte-read limit to both the gRPC and HTTP/protobuf export clients. The GHSA advisory confirms no workarounds are known. As a compensating control where immediate upgrade is not possible, restrict the OTLP export endpoint to a trusted internal network segment and enforce mutual TLS (mTLS) between the application and collector, which eliminates the MitM vector; note that mTLS requires collector reconfiguration and does not protect against a compromised collector endpoint itself. Ensuring the collector is a well-behaved, vendor-maintained implementation (e.g., OpenTelemetry Collector) that does not return excessively large error bodies also reduces practical exposure, but this is a defense-in-depth measure rather than a fix.
More in Opentelemetry Dotnet
View allUncontrolled memory allocation in OpenTelemetry dotnet's propagation header parsing exposes .NET applications to denial
Memory exhaustion via unbounded protobuf allocation in OpenTelemetry.Exporter.OpenTelemetryProtocol (NuGet) affects vers
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today