Open Telemetry
Monthly
Denial of service in OpenTelemetry JavaScript (@opentelemetry/propagator-jaeger) before 2.9.0 allows an unauthenticated remote attacker to crash a Node.js service by sending a malformed percent-encoded uber-trace-id or uberctx-* HTTP header. The JaegerPropagator passes header values to decodeURIComponent() without catching the resulting URIError, so the uncaught exception terminates the process. No public exploit identified at time of analysis, and this is not listed in CISA KEV; the fix is version 2.9.0.
Denial of service in OpenTelemetry Java Instrumentation before 2.27.0 lets an attacker who can reach an RMI endpoint on an instrumented JVM send an oversized context-propagation payload that triggers excessive memory allocation. The RMI payload reader caps the number of context entries but never bounds the aggregate size of the strings it reads, so a single crafted request can exhaust heap and crash or stall the JVM. No public exploit is identified at time of analysis, EPSS is low (0.24%), and CISA SSVC records no observed exploitation, but the flaw is network-reachable and unauthenticated wherever RMI instrumentation is enabled and exposed.
The OpenTelemetry .NET OTLP exporter's experimental disk-retry feature can be abused by an authenticated local attacker when `OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk` is set without `OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH`, causing retry blobs to be written to and read from fixed `traces`, `metrics` and `logs` subdirectories under the shared system temp root. An attacker holding a separate local account with read/write access to that temp directory can inject crafted `*.blob` files that the exporter later forwards to the configured OTLP endpoint under the application's identity and credentials, read the application's own serialized telemetry blobs, or flood the retry loop with oversized files to degrade performance and consume disk. The affected NuGet package is `OpenTelemetry.Exporter.OpenTelemetryProtocol` from 1.8.0 through 1.15.2 and is fixed in 1.15.3; the feature is experimental and off by default, exposure only arises when the directory variable is omitted, and no public exploit code was identified at time of analysis (EPSS 0.01%, no KEV entry), so risk is real but conditional on shared-temp multi-user hosts.
OpenTelemetry eBPF Instrumentation versions 0.4.0 through 0.7.x allow local attackers controlling a Java workload to overwrite arbitrary host files via path traversal when Java injection is enabled and the agent runs with elevated privileges. The vulnerability exploits unsafe file creation in the Java agent injection path, where the injector trusts the target process's TMPDIR environment variable and lacks boundary checks, enabling symlink-based file clobbering and filesystem escape. Vendor-released patch available in version 0.8.0. No public exploit identified at time of analysis, but CVSS 8.4 reflects high integrity and availability impact with scope change from container to host.
Unbounded baggage processing in the optional OpenTelemetry Python Jaeger propagator (opentelemetry-propagator-jaeger before 1.45.0) lets a remote sender force unnecessary CPU work and short-lived heap allocations by supplying a carrier with numerous or oversized uberctx-* entries, degrading availability of the receiving service. According to the CVSS vector, no authentication is required (PR:N), but exploitation depends on specific deployment conditions (AT:P): the separately installed Jaeger propagator must be explicitly enabled - it is not part of the default OpenTelemetry Python configuration - and the service must accept untrusted inbound propagation headers. Practical impact is modest because common Python servers cap request headers before they reach the propagator (Gunicorn defaults to 100 header fields and 8,190 bytes per field; Uvicorn/h11 buffers incomplete events at 16,384 bytes), with materially higher exposure for non-HTTP transports, custom TextMapGetter implementations, or deployments that have raised or disabled server and gateway limits. No public exploit code has been identified at time of analysis, and the vendor has released a fix in 1.45.0.
Denial of service in OpenTelemetry Python (opentelemetry-api through 1.45.0) lets a single unauthenticated request carrying an oversized W3C tracestate header burn roughly 6-12 seconds of CPU, and on asyncio servers stall every other connection on the event loop for that duration. The flaw is a quadratic-time regex split in TraceState.from_header that is reached automatically through the default tracecontext propagator, so any service instrumented with something like opentelemetry-instrumentation-asgi is affected without special configuration; exploitation is gated by the fronting HTTP parser's header-size limit, with gunicorn and uvicorn's h11 parser rejecting the header while waitress and uvicorn's default httptools parser accept it. A working proof-of-concept with measured timings is included in the upstream advisory (public PoC reference), but no confirmed active exploitation (CISA KEV) is indicated in the supplied intelligence, and the assessed CVSS of 5.3 reflects availability-only impact (C:N/I:N/A:L).
Database account usernames are silently emitted into telemetry traces by the OpenTelemetry JavaScript Contrib database instrumentation packages, which attach the `db.user` span attribute to every instrumented database operation by default, independent of the `enhancedDatabaseReporting` opt-in setting. Every deployment running the affected packages below their fixed versions - @opentelemetry/instrumentation-cassandra-driver before 0.66.0, -knex before 0.65.0, -mongoose/-mysql/-mysql2 before 0.67.0, -oracledb before 0.46.0, -pg before 0.73.0, and -tedious before 0.40.0 - that exports traces to a shared observability backend therefore leaks its database usernames, and indirectly hints about service topology, role assignment, and environment naming, to any actor with read access to that telemetry pipeline. Scored CVSS 5.8 (CWE-532), this is a default-configuration information-disclosure weakness rather than a remotely triggerable attacker compromise: no public exploit code has been identified at time of analysis, there is no confirmed active exploitation, and the only credential material exposed is account names - not passwords, query contents, or result data.
Log telemetry exported over gRPC by OpenTelemetry-Go versions prior to 0.21.0 can be silently intercepted or modified because the otlploggrpc exporter reads TLS certificate settings from environment variables into its config but never applies them to the gRPC transport credentials. When TLS is configured only through OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, and the related client-certificate/key variables - and the application does not additionally call WithTLSCredentials in code - the client falls back to credentials.NewTLS with system roots and no client certificate, so the intended private-CA pinning and mutual TLS are bypassed. A network attacker in a man-in-the-middle position who can present a certificate chaining to the victim host's system trust store can read or alter exported log data; misconfigured code paths that do pass WithTLSCredentials are unaffected, the system-trusted-certificate prerequisite is a significant limiting factor, and no public exploit was identified at time of analysis. The issue is fixed in otlploggrpc v0.21.0.
CPU exhaustion in the OpenTelemetry-Go sdk/log BatchProcessor (BatchingProcessor built via NewBatchingProcessor) before version 0.21.0 lets attacker-driven, high-volume log emission pin a process's CPU when the wrapped log exporter is simultaneously slow or backpressured. The poll loop repeatedly retries a non-blocking queue dequeue and a failed non-blocking EnqueueExport without waiting on its ticker, because the failed enqueue leaves the queue length unchanged at or above batchSize, producing a tight busy-spin that degrades or denies service in the embedding application. This is an availability-only flaw (CWE-400) with no confidentiality or integrity impact, no public exploit code identified at time of analysis, and no confirmed active exploitation (not in CISA KEV); the assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) is unauthenticated but requires the attacker to sustain log volume while the exporter is backpressured, which significantly narrows real-world exploitability.
Span attribute length limits can be bypassed in the OpenTelemetry-Go SDK trace package from 1.10.0 up to (but not including) 1.33.0, allowing an attacker who controls content recorded as a span attribute to retain string values far longer than the configured AttributeValueLengthLimit and thereby inflate per-span memory use inside the instrumented process. The root cause is a Unicode handling defect: the truncation helper misclassifies the valid replacement character U+FFFD as invalid UTF-8 and returns the original oversized value, and a fallback sanitization pass also leaves it unchanged. The impact is limited to a weakening of the SDK's built-in denial-of-service guard - there is no code execution, no confidentiality or integrity impact, and no public exploit code identified at time of analysis; the vendor scores it 5.1 (CVSS 4.0, AV:L, PR:N, VA:L) and our independent assessment is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L.
OpenTelemetry-Go versions 1.5.0 through 1.44.0 can write sensitive collector configuration into an application's own logs when the application explicitly opts into internal diagnostic logging through otel.SetLogger at Info verbosity: the TracerProvider created event serializes span processor, exporter, and client configuration, exposing OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. Anyone able to read those logs - local files, aggregated log stores, or a SIEM - can reconstruct internal collector topology and can recover credentials or tokens where operators embedded them in Zipkin URL user-info or query strings. The vendor CVSS 4.0 base score is 2.0 and no public exploit identified at time of analysis; note that OTLP authentication headers, TLS key material, and span payloads are never written by this path, and default OpenTelemetry configurations that do not install a logger are unaffected because the default logger does not emit the diagnostic event.
OpenTelemetry Java Instrumentation prior to 2.28.0 leaks clear-text database passwords into distributed trace span attributes when JDBC auto-instrumentation encounters double-quoted passwords in SQL CONNECT statements, bypassing the sanitization logic. These poisoned spans are then exported to any configured observability backend - Jaeger, Zipkin, OTLP collectors, or third-party SaaS monitoring - making database credentials visible to all parties with telemetry read access. No public exploit or confirmed active exploitation exists at time of analysis, but the impact of credential exposure is high given downstream database access risk.
Memory exhaustion in opentelemetry-cpp OTLP HTTP exporters (traces, metrics, logs) prior to 1.27.0 allows an attacker who controls the configured collector endpoint - or occupies a MITM position on the network path - to crash the instrumented process by returning an arbitrarily large HTTP response body. The curl-based HTTP client read response data into an unbounded in-memory buffer via io-equivalent copy with no size limit, making peak heap allocation entirely attacker-controlled. No public exploit has been identified at time of analysis, and EPSS at 0.02% (6th percentile) indicates low opportunistic exploitation probability, though the targeted threat model (supply-chain-adjacent collector compromise) is realistic in telemetry-heavy environments.
Unbounded HTTP response body allocation in OpenTelemetry.Sampler.AWS allows an attacker who controls the configured X-Ray sampling endpoint or who holds a network MitM position to exhaust heap memory and crash the consuming .NET process via OutOfMemoryException. Both NuGet packages OpenTelemetry.Sampler.AWS (versions below 0.1.0-alpha.8) and OpenTelemetry.Resources.AWS (versions below 1.15.1) are affected, with AWSXRaySamplerClient.DoRequestAsync calling ReadAsStringAsync() with no response size cap. No public exploit has been identified and EPSS sits at 0.01% (2nd percentile), consistent with SSVC exploitation status of none and CISA KEV absence, making this a low-urgency but patchable DoS risk.
Uncontrolled memory allocation in OpenTelemetry dotnet's propagation header parsing exposes .NET applications to denial of service. OpenTelemetry.Api versions 0.5.0-beta.2 through 1.15.2 and OpenTelemetry.Extensions.Propagators versions 1.3.1 through 1.15.2 contain BaggagePropagator, B3Propagator, and JaegerPropagator implementations that eagerly allocate intermediate arrays before enforcing size limits, allowing malformed headers with excessive delimiter characters to trigger disproportionate memory consumption. No active exploitation is confirmed (not in CISA KEV), EPSS is extremely low at 0.02%, and a vendor-released patch exists at version 1.15.3.
Memory exhaustion via unbounded protobuf allocation in OpenTelemetry.Exporter.OpenTelemetryProtocol (NuGet) affects versions 1.13.1 through 1.15.2 when exporting telemetry over OTLP/gRPC. An attacker controlling the gRPC collector endpoint or intercepting telemetry traffic can return a malformed grpc-status-details-bin trailer on a retryable response, causing the instrumented .NET process to attempt an arbitrarily large byte array allocation and exhaust available memory. No public exploit exists and SSVC confirms no active exploitation; a vendor patch is available in 1.15.3.
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.
Denial of service in OpenTelemetry JavaScript (@opentelemetry/propagator-jaeger) before 2.9.0 allows an unauthenticated remote attacker to crash a Node.js service by sending a malformed percent-encoded uber-trace-id or uberctx-* HTTP header. The JaegerPropagator passes header values to decodeURIComponent() without catching the resulting URIError, so the uncaught exception terminates the process. No public exploit identified at time of analysis, and this is not listed in CISA KEV; the fix is version 2.9.0.
Denial of service in OpenTelemetry Java Instrumentation before 2.27.0 lets an attacker who can reach an RMI endpoint on an instrumented JVM send an oversized context-propagation payload that triggers excessive memory allocation. The RMI payload reader caps the number of context entries but never bounds the aggregate size of the strings it reads, so a single crafted request can exhaust heap and crash or stall the JVM. No public exploit is identified at time of analysis, EPSS is low (0.24%), and CISA SSVC records no observed exploitation, but the flaw is network-reachable and unauthenticated wherever RMI instrumentation is enabled and exposed.
The OpenTelemetry .NET OTLP exporter's experimental disk-retry feature can be abused by an authenticated local attacker when `OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk` is set without `OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH`, causing retry blobs to be written to and read from fixed `traces`, `metrics` and `logs` subdirectories under the shared system temp root. An attacker holding a separate local account with read/write access to that temp directory can inject crafted `*.blob` files that the exporter later forwards to the configured OTLP endpoint under the application's identity and credentials, read the application's own serialized telemetry blobs, or flood the retry loop with oversized files to degrade performance and consume disk. The affected NuGet package is `OpenTelemetry.Exporter.OpenTelemetryProtocol` from 1.8.0 through 1.15.2 and is fixed in 1.15.3; the feature is experimental and off by default, exposure only arises when the directory variable is omitted, and no public exploit code was identified at time of analysis (EPSS 0.01%, no KEV entry), so risk is real but conditional on shared-temp multi-user hosts.
OpenTelemetry eBPF Instrumentation versions 0.4.0 through 0.7.x allow local attackers controlling a Java workload to overwrite arbitrary host files via path traversal when Java injection is enabled and the agent runs with elevated privileges. The vulnerability exploits unsafe file creation in the Java agent injection path, where the injector trusts the target process's TMPDIR environment variable and lacks boundary checks, enabling symlink-based file clobbering and filesystem escape. Vendor-released patch available in version 0.8.0. No public exploit identified at time of analysis, but CVSS 8.4 reflects high integrity and availability impact with scope change from container to host.
Unbounded baggage processing in the optional OpenTelemetry Python Jaeger propagator (opentelemetry-propagator-jaeger before 1.45.0) lets a remote sender force unnecessary CPU work and short-lived heap allocations by supplying a carrier with numerous or oversized uberctx-* entries, degrading availability of the receiving service. According to the CVSS vector, no authentication is required (PR:N), but exploitation depends on specific deployment conditions (AT:P): the separately installed Jaeger propagator must be explicitly enabled - it is not part of the default OpenTelemetry Python configuration - and the service must accept untrusted inbound propagation headers. Practical impact is modest because common Python servers cap request headers before they reach the propagator (Gunicorn defaults to 100 header fields and 8,190 bytes per field; Uvicorn/h11 buffers incomplete events at 16,384 bytes), with materially higher exposure for non-HTTP transports, custom TextMapGetter implementations, or deployments that have raised or disabled server and gateway limits. No public exploit code has been identified at time of analysis, and the vendor has released a fix in 1.45.0.
Denial of service in OpenTelemetry Python (opentelemetry-api through 1.45.0) lets a single unauthenticated request carrying an oversized W3C tracestate header burn roughly 6-12 seconds of CPU, and on asyncio servers stall every other connection on the event loop for that duration. The flaw is a quadratic-time regex split in TraceState.from_header that is reached automatically through the default tracecontext propagator, so any service instrumented with something like opentelemetry-instrumentation-asgi is affected without special configuration; exploitation is gated by the fronting HTTP parser's header-size limit, with gunicorn and uvicorn's h11 parser rejecting the header while waitress and uvicorn's default httptools parser accept it. A working proof-of-concept with measured timings is included in the upstream advisory (public PoC reference), but no confirmed active exploitation (CISA KEV) is indicated in the supplied intelligence, and the assessed CVSS of 5.3 reflects availability-only impact (C:N/I:N/A:L).
Database account usernames are silently emitted into telemetry traces by the OpenTelemetry JavaScript Contrib database instrumentation packages, which attach the `db.user` span attribute to every instrumented database operation by default, independent of the `enhancedDatabaseReporting` opt-in setting. Every deployment running the affected packages below their fixed versions - @opentelemetry/instrumentation-cassandra-driver before 0.66.0, -knex before 0.65.0, -mongoose/-mysql/-mysql2 before 0.67.0, -oracledb before 0.46.0, -pg before 0.73.0, and -tedious before 0.40.0 - that exports traces to a shared observability backend therefore leaks its database usernames, and indirectly hints about service topology, role assignment, and environment naming, to any actor with read access to that telemetry pipeline. Scored CVSS 5.8 (CWE-532), this is a default-configuration information-disclosure weakness rather than a remotely triggerable attacker compromise: no public exploit code has been identified at time of analysis, there is no confirmed active exploitation, and the only credential material exposed is account names - not passwords, query contents, or result data.
Log telemetry exported over gRPC by OpenTelemetry-Go versions prior to 0.21.0 can be silently intercepted or modified because the otlploggrpc exporter reads TLS certificate settings from environment variables into its config but never applies them to the gRPC transport credentials. When TLS is configured only through OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, and the related client-certificate/key variables - and the application does not additionally call WithTLSCredentials in code - the client falls back to credentials.NewTLS with system roots and no client certificate, so the intended private-CA pinning and mutual TLS are bypassed. A network attacker in a man-in-the-middle position who can present a certificate chaining to the victim host's system trust store can read or alter exported log data; misconfigured code paths that do pass WithTLSCredentials are unaffected, the system-trusted-certificate prerequisite is a significant limiting factor, and no public exploit was identified at time of analysis. The issue is fixed in otlploggrpc v0.21.0.
CPU exhaustion in the OpenTelemetry-Go sdk/log BatchProcessor (BatchingProcessor built via NewBatchingProcessor) before version 0.21.0 lets attacker-driven, high-volume log emission pin a process's CPU when the wrapped log exporter is simultaneously slow or backpressured. The poll loop repeatedly retries a non-blocking queue dequeue and a failed non-blocking EnqueueExport without waiting on its ticker, because the failed enqueue leaves the queue length unchanged at or above batchSize, producing a tight busy-spin that degrades or denies service in the embedding application. This is an availability-only flaw (CWE-400) with no confidentiality or integrity impact, no public exploit code identified at time of analysis, and no confirmed active exploitation (not in CISA KEV); the assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) is unauthenticated but requires the attacker to sustain log volume while the exporter is backpressured, which significantly narrows real-world exploitability.
Span attribute length limits can be bypassed in the OpenTelemetry-Go SDK trace package from 1.10.0 up to (but not including) 1.33.0, allowing an attacker who controls content recorded as a span attribute to retain string values far longer than the configured AttributeValueLengthLimit and thereby inflate per-span memory use inside the instrumented process. The root cause is a Unicode handling defect: the truncation helper misclassifies the valid replacement character U+FFFD as invalid UTF-8 and returns the original oversized value, and a fallback sanitization pass also leaves it unchanged. The impact is limited to a weakening of the SDK's built-in denial-of-service guard - there is no code execution, no confidentiality or integrity impact, and no public exploit code identified at time of analysis; the vendor scores it 5.1 (CVSS 4.0, AV:L, PR:N, VA:L) and our independent assessment is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L.
OpenTelemetry-Go versions 1.5.0 through 1.44.0 can write sensitive collector configuration into an application's own logs when the application explicitly opts into internal diagnostic logging through otel.SetLogger at Info verbosity: the TracerProvider created event serializes span processor, exporter, and client configuration, exposing OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. Anyone able to read those logs - local files, aggregated log stores, or a SIEM - can reconstruct internal collector topology and can recover credentials or tokens where operators embedded them in Zipkin URL user-info or query strings. The vendor CVSS 4.0 base score is 2.0 and no public exploit identified at time of analysis; note that OTLP authentication headers, TLS key material, and span payloads are never written by this path, and default OpenTelemetry configurations that do not install a logger are unaffected because the default logger does not emit the diagnostic event.
OpenTelemetry Java Instrumentation prior to 2.28.0 leaks clear-text database passwords into distributed trace span attributes when JDBC auto-instrumentation encounters double-quoted passwords in SQL CONNECT statements, bypassing the sanitization logic. These poisoned spans are then exported to any configured observability backend - Jaeger, Zipkin, OTLP collectors, or third-party SaaS monitoring - making database credentials visible to all parties with telemetry read access. No public exploit or confirmed active exploitation exists at time of analysis, but the impact of credential exposure is high given downstream database access risk.
Memory exhaustion in opentelemetry-cpp OTLP HTTP exporters (traces, metrics, logs) prior to 1.27.0 allows an attacker who controls the configured collector endpoint - or occupies a MITM position on the network path - to crash the instrumented process by returning an arbitrarily large HTTP response body. The curl-based HTTP client read response data into an unbounded in-memory buffer via io-equivalent copy with no size limit, making peak heap allocation entirely attacker-controlled. No public exploit has been identified at time of analysis, and EPSS at 0.02% (6th percentile) indicates low opportunistic exploitation probability, though the targeted threat model (supply-chain-adjacent collector compromise) is realistic in telemetry-heavy environments.
Unbounded HTTP response body allocation in OpenTelemetry.Sampler.AWS allows an attacker who controls the configured X-Ray sampling endpoint or who holds a network MitM position to exhaust heap memory and crash the consuming .NET process via OutOfMemoryException. Both NuGet packages OpenTelemetry.Sampler.AWS (versions below 0.1.0-alpha.8) and OpenTelemetry.Resources.AWS (versions below 1.15.1) are affected, with AWSXRaySamplerClient.DoRequestAsync calling ReadAsStringAsync() with no response size cap. No public exploit has been identified and EPSS sits at 0.01% (2nd percentile), consistent with SSVC exploitation status of none and CISA KEV absence, making this a low-urgency but patchable DoS risk.
Uncontrolled memory allocation in OpenTelemetry dotnet's propagation header parsing exposes .NET applications to denial of service. OpenTelemetry.Api versions 0.5.0-beta.2 through 1.15.2 and OpenTelemetry.Extensions.Propagators versions 1.3.1 through 1.15.2 contain BaggagePropagator, B3Propagator, and JaegerPropagator implementations that eagerly allocate intermediate arrays before enforcing size limits, allowing malformed headers with excessive delimiter characters to trigger disproportionate memory consumption. No active exploitation is confirmed (not in CISA KEV), EPSS is extremely low at 0.02%, and a vendor-released patch exists at version 1.15.3.
Memory exhaustion via unbounded protobuf allocation in OpenTelemetry.Exporter.OpenTelemetryProtocol (NuGet) affects versions 1.13.1 through 1.15.2 when exporting telemetry over OTLP/gRPC. An attacker controlling the gRPC collector endpoint or intercepting telemetry traffic can return a malformed grpc-status-details-bin trailer on a retryable response, causing the instrumented .NET process to attempt an arbitrarily large byte array allocation and exhaust available memory. No public exploit exists and SSVC confirms no active exploitation; a vendor patch is available in 1.15.3.
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.