{"id":"CVE-2026-40182","aliases":["EUVD-2026-25266","GHSA-q834-8qmm-v933"],"status":"published","title":"OpenTelemetry dotnet: OTLP exporter reads unbounded HTTP response bodies","description":"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.","severity":{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00304,"percentile":0.23457,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-789"],"published":"2026-04-23T17:51:34Z","modified":"2026-10-28T02:30:42Z","fixes":[{"ecosystem":"NuGet","package":"OpenTelemetry.Exporter.OpenTelemetryProtocol","fixed_in":["1.15.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"NuGet","package":"OpenTelemetry.Exporter.OpenTelemetryProtocol","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.13.1"},{"fixed":"1.15.2"}]}]},{"source":"osv","ecosystem":"NuGet","package":"OpenTelemetry.Exporter.OpenTelemetryProtocol","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.13.1"},{"fixed":"1.15.2"}]}],"versions":["1.13.1","1.14.0","1.15.0","1.15.1"]}],"products":[{"vendor":"open-telemetry","product":"opentelemetry-dotnet"},{"vendor":"opentelemetry","product":"opentelemetry"}],"references":[{"url":"https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-q834-8qmm-v933","tags":["x_refsource_CONFIRM","Vendor Advisory","advisory","web"]},{"url":"https://github.com/open-telemetry/opentelemetry-dotnet/pull/6564","tags":["x_refsource_MISC","Issue Tracking","Patch","fix","web"]},{"url":"https://github.com/open-telemetry/opentelemetry-dotnet/pull/7017","tags":["x_refsource_MISC","Issue Tracking","Patch","fix","web"]},{"url":"https://github.com/open-telemetry/opentelemetry-proto/pull/781","tags":["x_refsource_MISC","Issue Tracking","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-40182","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-q834-8qmm-v933"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/40xxx/CVE-2026-40182.json","tags":["advisory"]},{"url":"https://github.com/open-telemetry/opentelemetry-dotnet","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-40182","title":"OpenTelemetry dotnet: OTLP exporter reads unbounded HTTP response bodies","description":"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.","status":"published","published":"2026-04-23T17:51:34.961Z","modified":"2026-04-23T18:38:57.155Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T13:43:00.288193Z"}],"euvd":[{"id":"EUVD-2026-25266","description":"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.","status":"published","published":"2026-04-23T17:51:34Z","modified":"2026-04-23T18:38:57Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T19:24:19.171803Z"}],"ghsa":[{"id":"GHSA-q834-8qmm-v933","title":"OpenTelemetry dotnet: OTLP exporter reads unbounded HTTP response bodies","description":"### Summary\n\nWhen 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.\n\nThis 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.\n\n### Details\n\nhttps://github.com/open-telemetry/opentelemetry-dotnet/pull/6564 introduced a change to read 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 for both [gRPC](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpGrpcExportClient.cs#L123-L134) and [HTTP/protobuf](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpHttpExportClient.cs#L36-L41).\n\nAn unintended consequence of this change is that the response body is [fully read into memory when received with no upper-bound](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpExportClient.cs#L68-L89).\n\nThis vulnerability was surfaced during the investigation of GHSA-w8rr-5gcm-pp58.\n\n### Impact\n\nIf an application using the OTLP 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.\n\n### Mitigation\n\nThe 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.\n\n### Workarounds\n\nNone known.\n\n### Remediation\n\n[#7017](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7017) updates the OTLP exporter for both gRPC and HTTP to:\n\n- Limit the number of bytes read from the response body in an error condition to 4MiB (see https://github.com/open-telemetry/opentelemetry-proto/pull/781);\n- Only attempt to read the response body if OpenTelemetry error logging is enabled.","status":"published","published":"2026-04-23T21:26:10Z","modified":"2026-04-23T21:26:11Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T14:39:56.453138Z"}],"nvd":[{"id":"CVE-2026-40182","description":"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.","status":"published","published":"2026-04-23T18:16:28.13Z","modified":"2026-10-26T22:10:00.163Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"secondary"},{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"primary"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T14:12:15.867234Z"}],"osv":[{"id":"CVE-2026-40182","title":"OpenTelemetry dotnet: OTLP exporter reads unbounded HTTP response bodies","description":"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.","status":"published","published":"2026-04-23T17:51:34.961Z","modified":"2026-10-28T02:30:42.080689014Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T15:45:03.424067Z"},{"id":"GHSA-q834-8qmm-v933","title":"OpenTelemetry dotnet: OTLP exporter reads unbounded HTTP response bodies","description":"### Summary\n\nWhen 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.\n\nThis 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.\n\n### Details\n\nhttps://github.com/open-telemetry/opentelemetry-dotnet/pull/6564 introduced a change to read 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 for both [gRPC](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpGrpcExportClient.cs#L123-L134) and [HTTP/protobuf](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpHttpExportClient.cs#L36-L41).\n\nAn unintended consequence of this change is that the response body is [fully read into memory when received with no upper-bound](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpExportClient.cs#L68-L89).\n\nThis vulnerability was surfaced during the investigation of GHSA-w8rr-5gcm-pp58.\n\n### Impact\n\nIf an application using the OTLP 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.\n\n### Mitigation\n\nThe 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.\n\n### Workarounds\n\nNone known.\n\n### Remediation\n\n[#7017](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7017) updates the OTLP exporter for both gRPC and HTTP to:\n\n- Limit the number of bytes read from the response body in an error condition to 4MiB (see https://github.com/open-telemetry/opentelemetry-proto/pull/781);\n- Only attempt to read the response body if OpenTelemetry error logging is enabled.","status":"published","published":"2026-04-23T21:26:10Z","modified":"2026-09-10T03:51:02.815079557Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T15:46:54.40888Z"}]}}