OpenTelemetry.Exporter.OneCollector CVE-2026-41484
MEDIUM
GHSA-55m9-299j-53c7
Severity by source
AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Adjacent network and high complexity reflect MitM or endpoint-control prerequisite; no confidentiality or integrity impact, only availability from OOM crash.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
4DescriptionGitHub Advisory
Summary
When exporting telemetry to a back-end/collector over HTTP using the OpenTelemetry.Exporter.OneCollector exporter, 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.
Details
The HttpJsonPostTransport class reads the response body when a non-200 HTTP status code is received when exporting telemetry to aid debugging by operators so that the error response is included in the logs emitted by the exporter.
An attacker who controls the configured endpoint, or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process.
Impact
If an application using the OneCollector exporter is configured to use a back-end/collector endpoint that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response the application could have its memory exhausted and create a denial-of-service condition.
Mitigation
The application's configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs.
Workarounds
Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the configured back-end/collector endpoint.
Remediation
#4117 updates the OneCollector exporter to limit the number of bytes read from the response body in an error condition to 4MiB.
Resources
AnalysisAI
Memory exhaustion in OpenTelemetry.Exporter.OneCollector (NuGet, versions <= 1.15.0) enables denial-of-service against .NET applications when the configured telemetry collector endpoint is attacker-controlled or susceptible to MitM interception. The HttpJsonPostTransport class reads the full HTTP response body into heap memory on any 4xx or 5xx error - with no byte cap - allowing a malicious or intercepted endpoint to send an arbitrarily large body that exhausts heap memory, stalls the garbage collector, or triggers an OutOfMemoryException that terminates the process. No public exploit code exists and EPSS is 0.02% (3rd percentile), consistent with the high attack complexity; however, the impact on availability is rated High by the CVSS vector.
Technical ContextAI
The vulnerability resides in HttpJsonPostTransport.cs within the OpenTelemetry.Exporter.OneCollector NuGet package (CPE: pkg:nuget/opentelemetry.exporter.onecollector). When exporting telemetry over HTTP and receiving a non-200 status code, the class invokes response.Content.ReadAsStringAsync() without any size constraint, allocating heap proportionally to the response body returned by the server. CWE-770 (Allocation of Resources Without Limits or Throttling) precisely describes this root cause: an externally-supplied value (response body size) drives unbounded resource allocation. The fix in PR #4117 introduces the HttpClientHelpers.TryGetResponseBodyAsString helper with a hard 4MiB cap using buffered ArrayPool<byte> reads, switching from HttpCompletionOption.ResponseContentRead to HttpCompletionOption.ResponseHeadersRead and streaming reads with a truncation probe.
RemediationAI
Upgrade OpenTelemetry.Exporter.OneCollector to version 1.15.1, which caps response body reads at 4MiB in error conditions as implemented in PR #4117 (https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4117) at commit 77dc5d14fcdf6c6b3aeba5f8bba5dfded90495c9. If an immediate upgrade is not feasible, apply network-level mitigations to prevent MitM interception: enforce mutual TLS (mTLS) between the application and its telemetry collector to authenticate both sides and prevent interception, accepting the trade-off of increased certificate management overhead; restrict egress via firewall rules so the exporter can only reach known, trusted collector IP ranges, accepting reduced deployment flexibility; or deploy a service mesh with encrypted, authenticated transport. If the exporter's informational logging can be disabled via configuration, doing so removes the code path that reads the response body, preventing exploitation at the cost of reduced debug visibility on export failures. Advisory: https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-55m9-299j-53c7.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today