CVE-2026-81871 in OpenTelemetry
Summary
by MITRE • 09/16/2026
OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to version 0.21.0, the exporters/otlp/otlplog/otlploggrpc package loads OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, and related client certificate environment variables through loadEnvTLS into cfg.tlsCfg, but newGRPCDialOptions does not apply cfg.tlsCfg when creating gRPC transport credentials. The environment-only TLS path instead uses credentials.NewTLS with system roots and no configured client certificate, bypassing intended private CA pinning and mutual TLS unless the application also supplies WithTLSCredentials. A network attacker able to intercept or spoof the collector connection with a system-trusted certificate can read or alter log telemetry. This issue is fixed in version 0.21.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified within OpenTelemetry-Go prior to version 0.21.0 represents a critical misconfiguration in the transport layer security implementation for gRPC-based logging exporters. The core of this flaw lies in an inconsistency between how TLS configuration parameters are loaded and how they are subsequently applied during the establishment of network connections. Specifically, the package responsible for handling OTLP log exports via gRPC correctly parses environment variables such as OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE and OTEL_EXPORTER_OTLP_CERTIFICATE through a function named loadEnvTLS. These variables are intended to configure mutual TLS (mTLS) by specifying client certificates and private certificate authority roots, ensuring that the exporter authenticates itself to the collector and verifies the integrity of the connection using custom or private CA trust stores rather than relying solely on public system roots.
Despite these environment variables being successfully loaded into the internal configuration structure cfg.tlsCfg, a subsequent function responsible for creating gRPC dial options fails to utilize this TLS configuration when instantiating transport credentials. Instead of applying the configured tlsCfg which contains the specific client certificates and private CA settings, the code defaults to using credentials.NewTLS with only system-trusted root certificates. This oversight effectively bypasses any intended private certificate authority pinning or mutual authentication requirements defined by the user through environment variables. Consequently, if an application relies solely on these environment variables for security configuration without explicitly passing WithTLSCredentials in its gRPC dial options, it will operate under a weaker security posture than anticipated.
The operational impact of this vulnerability is severe, particularly in environments where private certificate authorities are used to secure telemetry data transmission between applications and OpenTelemetry collectors. An attacker positioned on the network path who can intercept or spoof connections may exploit this flaw by presenting a valid system-trusted certificate rather than one signed by the organization's private CA. Since the client no longer enforces verification against the specific private CA nor presents its own client certificate for mutual authentication, the connection becomes vulnerable to man-in-the-middle attacks. This allows an adversary to potentially read sensitive log telemetry data or alter it before it reaches the collector, compromising both confidentiality and integrity of observability data.
This issue aligns with CWE-295 Improper Certificate Validation as the system fails to properly validate certificates against the intended trust store, and CWE-319 Use of a Hard-coded or Insecure Cryptographic Key if one considers the implicit reliance on default system roots over configured private ones. From an ATT&CK perspective, this vulnerability facilitates Network Sniffing (T1040) and Data Manipulation during transit, as the lack of mutual TLS removes strong authentication guarantees that would otherwise prevent unauthorized interception or modification. The flaw underscores the importance of ensuring that configuration loading mechanisms are strictly coupled with their application in transport layer setup routines to maintain security boundaries.
To mitigate this vulnerability, organizations must upgrade OpenTelemetry-Go to version 0.21.0 or later where the discrepancy between environment variable parsing and gRPC credential creation has been resolved. In environments running older versions that cannot be immediately upgraded, a temporary mitigation involves explicitly configuring TLS credentials using WithTLSCredentials in the gRPC dial options rather than relying exclusively on environment variables for mTLS setup. This ensures that the intended client certificates and private CA roots are actively applied to the transport layer, restoring mutual authentication and proper certificate validation against the specified trust store. Regular auditing of telemetry configuration practices is recommended to ensure alignment with security policies regarding data in transit protection.