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.
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.
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.
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.
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.