Between April and May 2026, five CVEs were disclosed against OpenTelemetry components across .NET and Go. This is not a sign the project is falling apart — it is a sign that OTel has arrived as production infrastructure, and production infrastructure gets scrutinised. Security hardening is a distinct phase in any enterprise OTel migration playbook, and this CVE cluster is the reason that phase exists.
Your response comes down to three tracks. Patches exist for three CVEs — upgrade opentelemetry-dotnet to 1.15.3 and you are covered. The deprecated Jaeger exporter has no patch and never will — migration is your only option. And for the Go SDK CVE, an upstream fix exists at v1.43.0, but Linux vendor packages were still unpatched as of May 2026.
What ties all five together is trust boundaries. OTel processes HTTP propagation headers, connects to OTLP endpoints that may be attacker-controlled, writes payloads to disk, and calls system binaries at startup. Each of those is a point where data crosses between security zones. Treating OTel as a passive monitoring tool sitting safely outside your security perimeter is no longer a defensible position.
Why Is OpenTelemetry’s Growing CVE Cadence a Maturity Signal and Not a Crisis?
CVEs appearing against a project mean security researchers are actively reviewing it. That is exactly what happens when a framework graduates from developer tooling to production infrastructure. Zero CVEs against a widely-deployed framework is more concerning than a steady disclosure cadence. The April-May 2026 cluster was disclosed through the right channels — GitHub Security Advisories and NVD — with patches shipped ahead of or alongside public disclosure for three of the five.
A trust boundary is any point where data passes between zones with different trust levels. OTel receives HTTP propagation headers from arbitrary clients, spools payloads to disk, calls system utilities at startup, and sends data to OTLP endpoints you may not control. Each CVE in this cluster maps to one of those crossing points.
Your framing for the wider team: “Our observability stack is now mature enough to attract serious security scrutiny — we are treating it accordingly.” One exception to that framing: CVE-2026-39883 has an available exploit and no Linux patch as of writing. The maturity framing is not an excuse to sit on that one.
What Is CVE-2026-41078 and Why Does the Jaeger Exporter Vulnerability Have No Patch?
CVE-2026-41078 is a denial-of-service vulnerability (CWE-770) in the deprecated OpenTelemetry.Exporter.Jaeger NuGet package, versions 1.6.0-rc.1 and earlier.
Under high-cardinality telemetry, the exporter’s internal pooled-list grows without bound. No size limits, no automatic shrinking, no memory pressure detection. An attacker who can influence the attributes your application records in traces — even indirectly, through normal application behaviour — can trigger progressive memory exhaustion.
There is no patch and there will not be one. OpenTelemetry.Exporter.Jaeger was deprecated in 2023. Deprecated packages do not receive security fixes. Carrying deprecated dependencies is not a technical debt problem — it is a security posture problem.
Migrate to OpenTelemetry.Exporter.OpenTelemetryProtocol. You get a bonus alongside the security fix: migrating from the deprecated Jaeger exporter to OTLP also delivers vendor portability — OTLP is accepted by every modern observability platform, so you drop your Jaeger vendor dependency at the same time. For a detailed look at what vendor lock-in escape via OTLP actually gives you beyond the security fix, that analysis covers which backends support native OTLP ingestion and where semantic convention gaps remain.
What Do We Know About CVE-2026-40182 and CVE-2026-40894 in opentelemetry-dotnet?
Two moderate-severity vulnerabilities (both CWE-789, CVSS 5.3) in the opentelemetry-dotnet family, published April 23, 2026. The patch sequence matters here — one fix stops at 1.15.2 and leaves the other open.
CVE-2026-40182 affects OpenTelemetry.Exporter.OpenTelemetryProtocol versions 1.13.1–1.15.1. When the OTLP exporter receives an error response, it reads the full HTTP response body into memory with no size limit. A compromised or attacker-controlled OTLP backend can exhaust your application’s memory by returning oversized error bodies. Fixed in version 1.15.2.
CVE-2026-40894 affects OpenTelemetry.Api 0.5.0-beta.2–1.15.2 and OpenTelemetry.Extensions.Propagators 1.3.1–1.15.2. No privileges required. BaggagePropagator.Inject() does not enforce the documented 8192-character limit for single-item baggage, and the extract methods for Baggage, B3, and Jaeger propagators eagerly allocate intermediate arrays before applying size limits — a crafted propagation header exhausts memory. Fixed in version 1.15.3.
Here is the thing you cannot afford to miss: do not stop at 1.15.2. Teams who upgrade from 1.15.1 to 1.15.2 resolve CVE-2026-40182 but remain exposed to CVE-2026-40894. The correct target is 1.15.3, which covers all three opentelemetry-dotnet CVEs in one go.
These two CVEs also make the trust boundary model concrete. CVE-2026-40182 shows your outbound export path is a trust boundary — your OTLP backend can attack your application through error responses. CVE-2026-40894 shows that inbound propagation headers are external attacker input that must be bounded. The observability pipeline is a bidirectional attack surface.
What Is CVE-2026-42191 and How Does the Disk Retry Path Vulnerability Work?
CVE-2026-42191 (GHSA-4625-4j76-fww9) is a moderate-severity local blob injection vulnerability in OpenTelemetry.Exporter.OpenTelemetryProtocol, versions 1.8.0–1.15.2. Patched in 1.15.3.
The disk retry feature (OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk) spools undelivered OTLP payloads to disk when a backend is unavailable. When OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH is not set, the exporter falls back to Path.GetTempPath() — the system temp directory shared by all local users.
The impact compounds quickly. A local attacker can inject crafted .blob files that the exporter picks up and forwards to your OTLP endpoint under the application’s identity. Telemetry payloads are readable by any local user between export failures. Flood the temp directory and you exhaust disk space. That is integrity, confidentiality, and availability all in one flag.
The root cause is the classic debugging-flag-in-production pattern. Someone enabled this during integration testing or incident response and it was never cleaned up when the environment was promoted.
Remediation: upgrade to 1.15.3, then audit all environments for OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk. If that flag is present without the directory path override, the environment is vulnerable regardless of package version — and this audit requires zero downtime.
What Is CVE-2026-39883 and What Should Teams Do When No Vendor Patch Is Available?
CVE-2026-39883 (GHSA-hfvc-g4fc-pqhx) is the highest-urgency item here — a High-severity PATH hijacking vulnerability (CWE-426) in go.opentelemetry.io/otel/sdk, versions 1.15.0–1.42.0. CVSS v3: 7.0. CVSS v4: 7.3. Exploit confirmed available.
During resource detection at SDK initialisation, sdk/resource/host_id.go calls the BSD kenv utility using its bare name rather than an absolute path. An attacker with local filesystem access who places a malicious binary named kenv earlier in $PATH achieves arbitrary code execution when OTel initialises.
CVE-2026-24051 was a predecessor PATH hijacking in the same code path. That fix resolved the Darwin ioreg command but left kenv bare on BSD. Same attack vector, different platform branch — a lesson in validating your patches across all platform targets.
The upstream fix is in v1.43.0. Pin it in go.mod immediately.
Here is where it gets awkward. Tenable Nessus Plugin 306146 (updated May 6, 2026) confirms Ubuntu 22.04 LTS, 24.04 LTS, 25.10, and 26.04 had not shipped the patch as of that date. apt will report nothing outstanding while you are running vulnerable code.
What to do without a vendor patch:
- Upgrade the Go module directly — pin v1.43.0 in
go.mod. Do not wait. - Restrict local user access to hosts running OTel-instrumented Go services.
- Monitor startup process invocations for unexpected binary executions.
- Apply network isolation to reduce blast radius.
- Verify exposure using Nessus Plugin 306146 or an equivalent scanner.
Which OTel Components Need the Same Security Review Cycle as Your Application Code?
Most platform teams exclude OTel packages from patch SLA workflows because they file them under “observability tooling” rather than application code. This CVE cluster makes that classification indefensible.
Each trust boundary maps to a specific CVE: HTTP propagation headers entering the SDK (CVE-2026-40894), the outbound connection to the OTLP backend (CVE-2026-40182), the disk retry write path (CVE-2026-42191), and the OS startup context where resource detection calls system binaries (CVE-2026-39883).
The components that need patch discipline: OTel SDKs, OTel exporters, the OTel Collector if you have it deployed, and OTel propagator extensions.
For .NET teams: include OTel NuGet packages in dotnet nuget audit. Your minimum target is version 1.15.3. Subscribe to GitHub Security Advisories for each OTel repository in your dependency graph.
For Go teams: run govulncheck ./... against modules including go.opentelemetry.io/otel/sdk. Extend Nessus scanning scope to OTel-specific CPE identifiers.
The step that makes this stick: security and platform teams need a shared list of which OTel components fall inside patch SLAs. The absence of that list is what allows the misclassification to persist in the first place.
How Do You Reduce Your OTel Attack Surface Without Waiting for Patches?
The principle is simple: run only the OTel components you actively use, with only the features you have explicitly configured, against only the backends you control.
Build a custom Collector distribution. The OpenTelemetry Collector Builder (ocb) lets you define a builder-config.yaml listing only the receivers, processors, and exporters you actually need. A Collector built without the Jaeger exporter cannot be affected by any future Jaeger exporter CVE. Custom Collector distributions reduce exposure to unpatched CVEs by eliminating unnecessary components from the attack surface entirely — declarative configuration managed through GitOps makes this approach auditable and keeps configuration drift from quietly re-introducing removed components.
Audit your environment variables now. CVE-2026-42191 only affects deployments where OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk is set. Scanning for that flag across all environments takes minutes and requires no downtime.
Set a deprecation sunset policy. CVE-2026-41078 exists because a deprecated package ran in production for two years after its deprecation notice. A 90-day removal window applied to OTel packages through your existing NuGet audit workflow eliminates this class of exposure before the CVE even arrives.
Keep OTel config in version control. Environment variables in Kubernetes manifests rather than deployment scripts means experimental flags are visible for code review and cannot silently survive environment promotions.
Security hardening is not a one-time fix — it is an ongoing posture that belongs inside your migration plan. If you are working through the broader decision of moving from proprietary APM to OTel, security requirements are a migration gate: see the enterprise OpenTelemetry migration playbook for how the security hardening phase fits alongside instrumentation, Collector topology, and backend selection.
Frequently Asked Questions
Is CVE-2026-39883 in OpenTelemetry-Go patched?
The upstream fix is in v1.43.0. Linux distribution vendor packages (Ubuntu 22.04 LTS, 24.04 LTS, 25.10, 26.04) had not shipped the patched version as of May 6, 2026 per Tenable Nessus Plugin 306146. Pin the Go module directly in go.mod rather than waiting on your distro.
What is the minimum safe opentelemetry-dotnet version to cover all three dotnet CVEs?
Version 1.15.3. It patches CVE-2026-40182, CVE-2026-40894, and CVE-2026-42191 simultaneously. Version 1.15.2 patches CVE-2026-40182 only — you are still exposed if you stop there.
Should I still use the Jaeger exporter with OpenTelemetry?
No. OpenTelemetry.Exporter.Jaeger was deprecated in 2023 and will not receive security patches. CVE-2026-41078 is what happens when you keep running it. Replace it with OpenTelemetry.Exporter.OpenTelemetryProtocol, which works with Jaeger backends that accept OTLP and with all modern observability platforms.
Do I need to patch OpenTelemetry if I only use it for tracing?
Yes. CVE-2026-40894 affects all applications using B3, Jaeger, or Baggage propagation for distributed tracing. CVE-2026-40182 affects any application using the OTLP exporter to send traces to a backend. Both are present in a tracing-only deployment.
What is a trust boundary in the context of OpenTelemetry?
It is any point where data passes from one security zone to another. For OTel that means: HTTP propagation headers entering the SDK from untrusted clients; OTLP backend error responses from a potentially attacker-controlled endpoint; disk retry payloads in a shared temp directory; system binary calls during startup. Apply the same validation discipline as you would to user input in your application code.
What does “PATH hijacking” mean for CVE-2026-39883?
The OTel Go SDK calls the BSD kenv utility by its short name. The OS searches $PATH directories in order. An attacker with local filesystem access who places a malicious binary named kenv earlier in $PATH causes the OS to run it instead. Not remote code execution — but rated High (CVSS 7.0) because local access on shared or multi-tenant infrastructure is frequently achievable.
Can my telemetry pipeline be used to attack my own application?
Yes — CVE-2026-40182 demonstrates this directly. A compromised OTLP endpoint responds to export requests with an oversized error body, exhausting the application’s memory. An attacker positioned as a man-in-the-middle on the OTLP connection can use the export path as an inbound attack channel. That is why the OTLP endpoint is a trust boundary, not a trusted internal service.
Where should I check for new OpenTelemetry CVEs?
opentelemetry.io/docs/security/cve/ and GitHub Security Advisories on each component repository. NVD for canonical CVSS scores. Tenable Nessus Plugin 306146 for Linux vendor package patch status on OTel-Go. Subscribe to the GitHub Security Advisory feed for each OTel repository in your dependency graph.
