OpenTelemetry-Go EUVD-2026-81262

Exploitation requires all of the following: (1) the application uses the otlploggrpc logs exporter at a version < 0.21.0; (2) TLS to the OTLP collector is configured ONLY through environment variables (OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, and the client-certificate/key variables) WITHOUT also calling WithTLSCredentials in code - if WithTLSCredentials is supplied programmatically the connection is not vulnerable; (3) the deployment relies on that env-configured private-CA pinning or mutual TLS as its trust boundary (a deployment already using a public/system-trusted CA gains no protection from pinning and is not meaningfully weakened); and (4) the attacker holds a man-in-the-middle position on the client-to-collector network path AND can present a certificate that chains to the victim host's system trust store. The system-trusted-certificate requirement is the primary limiting factor (reflected as AT:P in CVSS 4.0), meaning arbitrary self-signed spoofing does not work.

This is a genuine but moderate-severity confidentiality/integrity risk, not a high-urgency emergency. The vendor CVSS 4.0 base is 6.3 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N) - the AT:P (attack requirement present) metric correctly reflects that exploitation depends on the attacker achieving a network-interception position AND presenting a certificate trusted by the victim host's system roots, which materially raises the bar. No KEV listing, no EPSS score, and no public exploit code are present in the input, so exploitation status is: no public exploit identified at time of analysis - treat this as a defense-in-depth/misconfiguration-exposure issue rather than an actively hunted target. Importantly, the flaw only manifests when an application configures collector TLS exclusively through environment variables and relies on private-CA pinning or mutual TLS; applications that pass WithTLSCredentials programmatically are unaffected, which sharply narrows the real-world exposed population below what the network-vector CVSS alone would imply. My independent read lowers the effective severity slightly (assessed ~4.8 in CVSS 3.1 with AC:H) because the MITM prerequisite plus the need for a system-trusted certificate is closer to high attack complexity than low.

A Go service uses the otlploggrpc logs exporter and configures mTLS/private-CA pinning to its OTLP collector purely via OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE and related environment variables, expecting the connection to be pinned. Because newGRPCDialOptions never applies the env-loaded cfg.tlsCfg, the client silently falls back to system roots with no client certificate. An attacker positioned on the network path (e.g., compromised router, rogue proxy, or DNS/ARP spoofing) who can present any certificate chaining to a system-trusted CA intercepts the gRPC connection and reads or tampers with the exported log telemetry. No public exploit code is identified in the provided data.