VYPR
Get started
← All vendors
Vendor

Open Telemetry

Sign in to watch
Products
7
CVEs
12
Across products
12
Status
Private

Products

7

Recent CVEs

12
CVESevRiskCVSSEPSSKEVPublishedDescription
CVE-2026-41433Hig0.558.40.00Apr 24, 2026OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. From 0.4.0 to before 0.8.0, a flaw in the Java agent injection path allows a local attacker controlling a Java workload to overwrite arbitrary host files when Java injection is enabled and OBI is running with elevated privileges. The injector trusted TMPDIR from the target process and used unsafe file creation semantics, enabling both filesystem boundary escape and symlink-based file clobbering. This vulnerability is fixed in 0.8.0.
CVE-2026-42602Hig0.538.10.00May 13, 2026azureauthextension is the Azure Authenticator Extension. From 0.124.0 to 0.150.0, a server-side authentication bypass in azureauthextension allows any party who holds a single valid Azure access token for any scope the collector's configured identity can mint for to authenticate to any OpenTelemetry receiver that uses auth: azure_auth. The extension's Authenticate method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client's token to the result with string equality — and the scope for that server-side token request is taken from the client-supplied Host header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching Host. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens).
CVE-2026-44902hig0.45——May 11, 2026## Summary A single malformed HTTP request crashes any Node.js process running the OpenTelemetry JS Prometheus exporter. The metrics endpoint (default `0.0.0.0:9464`) has no error handling around URL parsing, so a request with an invalid URI causes an uncaught `TypeError` that terminates the process. **You are affected by this vulnerability if either of the following apply to your application:** * you directly use `@opentelemetry/exporter-prometheus` in your code through its built-in server. * your `OTEL_METRICS_EXPORTER` environment variable includes `prometheus` **AND** * you use `@opentelemetry/sdk-node` * you use `@opentelemetry/auto-instrumentations-node` via `--require @opentelemetry/auto-instrumentations-node/register`/`--import @opentelemetry/auto-instrumentations-node/register` ## Impact **Denial of service.** Any application using the OpenTelemetry Prometheus exporter’s built-in server can be crashed by a single unauthenticated network packet sent to the metrics port. No authentication, special privileges, or prior access is required. ## Remediation ### Update to the fixed version Update `@opentelemetry/exporter-prometheus` and `@opentelemetry/sdk-node` to version **0.217.0** or later. Update `@opentelemetry/auto-instrumentations-node` to version **0.75.0** or later. This release adds proper error handling around the URL constructor, returning an HTTP `400` response on parse failure rather than allowing the exception to propagate and crash the process. ``` npm install @opentelemetry/exporter-prometheus@latest ``` ### Do Not Expose the Endpoint to Untrusted Users > [!IMPORTANT] > The following mitigations reduce exposure but do not fully remediate the vulnerability. Any client that *can* reach the metrics endpoint - including your own Prometheus scraper host if compromised - could still trigger the crash. Updating to **0.217.0** is the recommended resolution. If updating is not immediately feasible, restrict access to the metrics endpoint so that it is not reachable by untrusted or unauthenticated network clients. For example: * **Bind to localhost only** by setting the `host` option to `127.0.0.1` when configuring the `PrometheusExporter`, so the port is not exposed on public or shared network interfaces * **Use a firewall or network policy** to restrict access to port `9464` (or whichever port you have configured) to only trusted Prometheus scrape hosts * **Place the endpoint behind a reverse proxy** that filters or validates incoming requests before they reach the exporter ## Details In `PrometheusExporter.ts`, the `_requestHandler` calls `new URL(request.url, this._baseUrl)` without any error handling. Node's HTTP parser accepts absolute-form URIs (e.g. `http://`) for proxy compatibility, including malformed ones. When `request.url` is `"http://"`, the `URL` constructor throws `TypeError: Invalid URL`. Since there is no try-catch in the handler, the exception propagates as an uncaught exception and crashes the process. The Prometheus metrics endpoint is unauthenticated by design (Prometheus scrapes it) and binds to `0.0.0.0` by default, meaning it is reachable by any network client that can connect to the metrics port. ## Proof of Concept Start any Node.js application with the Prometheus exporter running on the default port `9464`, then send a single raw TCP packet: ``` echo -ne 'GET http:// HTTP/1.1\r\nHost: localhost\r\n\r\n' | nc localhost 9464 ``` The process crashes immediately with: ``` TypeError: Invalid URL at new URL (...) at PrometheusExporter._requestHandler (...) ```
CVE-2026-41173Med0.385.90.00Apr 23, 2026The AWS X-Ray Remote Sampler package provides a sampler which can get sampling configurations from AWS X-Ray. Prior to 0.1.0-alpha.8, OpenTelemetry.Sampler.AWS reads unbounded HTTP response bodies from a configured AWS X-Ray remote sampling endpoint into memory. AWSXRaySamplerClient.DoRequestAsync called HttpClient.SendAsync followed by ReadAsStringAsync(), which materializes the entire HTTP response body into a single in-memory string with no size limit. The sampling endpoint is configurable via AWSXRayRemoteSamplerBuilder.SetEndpoint (default: http://localhost:2000). An attacker who controls the configured endpoint, or who can intercept traffic to it (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. This vulnerability is fixed in 0.1.0-alpha.8.
CVE-2026-42191Med0.356.50.00May 12, 2026OpenTelemetry.Exporter.OpenTelemetryProtocol is the OTLP (OpenTelemetry Protocol) exporter implementation. From 1.8.0 to 1.15.2, the OTLP disk retry feature in OpenTelemetry.Exporter.OpenTelemetryProtocol silently fell back to Path.GetTempPath() when OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk was set but OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH was not configured. The exporter stored and loaded *.blob files under fixed, signal-named subdirectories (traces, metrics, logs) beneath that shared temporary root path. On multi-user systems where the temporary directory is accessible to other local accounts, this allows an attacker to write crafted *.blob files, read *.blob files written by the application between export failures, or deposit numerous or oversized blob files, degrading retry-loop performance or consuming disk space. This vulnerability is fixed in 1.15.3.
CVE-2026-42348Med0.315.90.00May 12, 2026OpenTelemetry.OpAmp.Client is the OpAMP client for OpenTelemetry .NET. Prior to 0.2.0-alpha.1, when receiving responses from the OpAMP server over HTTP, the OpAMP client allocates an unbounded buffer to read all bytes from the server, with no upper-bound on the number of bytes consumed. This could cause memory exhaustion in the consuming application if the configured OpAMP server is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response. This vulnerability is fixed in 0.2.0-alpha.1.
CVE-2026-41483Med0.315.90.00May 6, 2026OpenTelemetry.Resources.Azure is the .NET resource detector for Azure environments. In versions 1.15.0-beta.1 and earlier, the AzureVmMetaDataRequestor class makes HTTP requests to the Azure VM instance metadata service and reads the response body into memory without any size limit. An attacker who controls the configured endpoint, or who can intercept traffic to it via a man-in-the-middle attack, 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. As a workaround, disable the Azure VM resource detector or use network-level controls such as firewall rules, mTLS, or a service mesh to prevent man-in-the-middle attacks on the Azure VM instance metadata endpoint. This issue is fixed in version 1.15.1-beta.1, which streams responses rather than buffering them entirely in memory and ignores responses larger than 4 MiB.
CVE-2026-41484Med0.275.30.00May 6, 2026OpenTelemetry.Exporter.OneCollector is a .NET exporter that sends telemetry to a OneCollector back-end over HTTP. In versions 1.15.0 and earlier, when a request to the configured back-end or collector results in an unsuccessful HTTP 4xx or 5xx response, the HttpJsonPostTransport class reads the entire response body into memory with no upper bound on the number of bytes consumed in order to include the error response in operator logs. An attacker who controls the configured endpoint, or who can intercept traffic to it via a man-in-the-middle attack, 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. As a workaround, use network-level controls such as firewall rules, mTLS, or a service mesh to prevent man-in-the-middle attacks on the configured back-end or collector endpoint. This issue is fixed in version 1.15.1, which limits the number of bytes read from the response body in an error condition to 4 MiB.
CVE-2026-41310Med0.275.30.00May 6, 2026OpenTelemetry.Exporter.Zipkin is the .NET Zipkin exporter for OpenTelemetry. In versions 1.15.2 and earlier, the Zipkin exporter remote endpoint cache accepts unbounded key growth derived from span attributes. In high-cardinality scenarios, a process using Zipkin export for client or producer spans could experience avoidable memory growth under sustained unique remote endpoint values, increasing process memory usage over time and degrading availability. This issue is fixed in version 1.15.3, which introduces a bounded, thread-safe LRU cache for remote endpoints with a fixed maximum size.
CVE-2026-44213med0.26——May 8, 2026### Summary The `OpenTelemetry.Exporter.Instana` NuGet package does not validate HTTPS/TLS certificates are valid when sending telemetry to a configured Instana back-end when a proxy is configured using the `INSTANA_ENDPOINT_PROXY` environment variable. If a network attacker can Man-in-the-Middle (MitM) the proxy connection, all OpenTelemetry telemetry data and the Instana API key are exposed to the attacker. ### Details The [`Transport.ConfigureBackendClient()`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/b53b6a74fde21a4cee344e584b51a0fe5bf1f337/src/OpenTelemetry.Exporter.Instana/Implementation/Transport.cs#L132-L158) method creates an `HttpClient` instance that completely disables TLS server certificate validation if the `INSTANA_ENDPOINT_PROXY` is configured with a valid proxy URL with no ability to re-enable it. ### Impact If the configured proxy is attacker-controlled (or a network attacker MitM the connection), or if it is possible for the process' configuration to be changed to add an attacker-provided value for `INSTANA_ENDPOINT_PROXY` then all Instana telemetry could be read by an unauthorized party and the service's Instana API key compromised, potentially before being forwarded to Instana presenting no noticeable loss of telemetry data without a valid TLS server certificate being presented to the client that matches the expected hostname or IP address. ### Mitigation The proxy configured by the `INSTANA_ENDPOINT_PROXY` environment variable must be malicious or be possible to be subject to a MitM attack. ### Workarounds Do not configure the `INSTANA_ENDPOINT_PROXY` environment variable. ### Remediation [#4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153) refactors `HttpClient` creation so that TLS certificate validation is no longer disabled by default when using a proxy. In environments where this capability is required, for example for local development, the previous behaviour can be restored using the `` option: ```csharp builder.AddInstanaExporter((options) => { options.HttpClientFactory = () => { var handler = new HttpClientHandler() { #if NET ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator, #else ServerCertificateCustomValidationCallback = static (_, _, _, _) => true, #endif }; return new HttpClient(handler, disposeHandler: true); }; }); ``` ### Resources - [PR #4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153)
CVE-2026-452920.00——May 14, 2026## Overview A vulnerability affects the baggage propagation implementation in `opentelemetry-api` and `opentelemetry-extension-trace-propagators`. Parsing oversized baggage causes unbounded memory allocation and CPU consumption. Because baggage is automatically re-injected into every outgoing request, the effect can fan out to downstream services that never received the original malicious request. ## Technical Details - `W3CBaggagePropagator` did not enforce any limit on the total size or entry count of the `baggage` header. The parser iterated character-by-character through the entire value regardless of length. - `JaegerPropagator` and `OtTracePropagator` had the same gap in their respective baggage extraction paths. - The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; none of these limits were enforced. ## Impact The practical availability impact for most deployments is limited. Every major Java HTTP server enforces its own header size limit (Tomcat, Jetty, Netty, Vert.x, and gRPC-Java all default to 8 KiB), constraining what an external attacker can deliver before the application is reached. The risk is higher when transport-layer limits are absent — e.g., a compromised internal service communicating over a non-HTTP or custom transport. ## Remediation Update to version 1.62.0 or later ([#8380](https://github.com/open-telemetry/opentelemetry-java/pull/8380)). The fix enforces limits consistent with the W3C Baggage specification at the propagator level: - Maximum total baggage size: 8,192 bytes across all `baggage` header values - Maximum number of entries: 64 Headers that would exceed either limit are dropped at the point the limit is reached; already-extracted valid entries are retained. ## Workarounds Ensure HTTP header size limits are configured at the server or gateway level. Most Java HTTP servers enforce an 8 KiB header limit by default, which mitigates external attack vectors independently of this fix. ## References - [W3C Baggage Specification §Limits](https://www.w3.org/TR/baggage/#limits)
CVE-2026-240510.00—0.00Feb 2, 2026OpenTelemetry-Go is the Go implementation of OpenTelemetry. The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. A fix was released with v1.40.0.