CVE-2026-81871: OpenTelemetry-Go: Log gRPC exporter ignores env TLS certs, bypassing mTLS/pinning
Summary
The OTLP log gRPC exporter loads TLS settings from environment variables but does not apply them when creating gRPC transport credentials. Operators who rely on OTELEXPORTEROTLPLOGSCERTIFICATE, OTELEXPORTEROTLPCERTIFICATE, or related client certificate variables for CA pinning or mTLS get a connection that falls back to system roots and omits the env-supplied client certificate. A network attacker who can intercept or spoof the collector connection with a system-trusted certificate can read or alter log telemetry.
Introduced in commit: d99c76f
Details
The affected code is in exporters/otlp/otlplog/otlploggrpc.
newConfig resolves env-based TLS configuration into cfg.tlsCfg at exporters/otlp/otlplog/otlploggrpc/config.go:106-116. The finding also identifies loadEnvTLS at config.go:451-492 as the code that builds a tls.Config containing RootCAs and client certificates from OTELEXPORTEROTLP[LOGS]CERTIFICATE and OTELEXPORTEROTLP[LOGS]CLIENTCERTIFICATE/KEY.
However, newGRPCDialOptions in exporters/otlp/otlplog/otlploggrpc/client.go:83-92 only checks cfg.gRPCCredentials and cfg.insecure. When neither is set, which is the normal env-only TLS configuration path, it uses credentials.NewTLS(nil). That default trusts the host system root CAs and contains no env-supplied client certificate. The finding evidence reports no other tlsCfg use in the package, so env-based CA pinning and mTLS settings are loaded but not enforced.
PoC
validation-artifact.zip
The validation artifact contains a ready-to-run test at validation-artifact.zip:./pocenvtlsignoredtest.go and brief instructions at validation-artifact.zip:./README.md.
From a checkout of pellared/opentelemetry-go at commit d99c76f, with Go module dependencies available:
sh FINDINGDIR=/path/to/02-e6e2897a969c8191b260f243fbc99ebd-log-grpc-exporter-ignores-env-tls-certs-bypassing-mtls-pinning cd /path/to/opentelemetry-go git checkout d99c76f tar -xOf validation-artifact.tar ./pocenvtlsignoredtest.go > exporters/otlp/otlplog/otlploggrpc/pocenvtlsignoredtest.go cd exporters/otlp/otlplog/otlploggrpc GO111MODULE=on go test -v -run TestEnvTLSIgnored -count=1
The test generates a private CA and a TLS gRPC logs server certificate signed by that CA. It sets:
sh OTELEXPORTEROTLPLOGSENDPOINT=https://127.0.0.1:<test-port> OTELEXPORTEROTLPLOGSCERTIFICATE=<temp-dir>/ca.pem
Expected output includes an unknown authority failure for the first export call even though the env certificate points to the server CA, followed by a passing test after the same cfg.tlsCfg is explicitly wired through WithTLSCredentials:
text === RUN TestEnvTLSIgnored pocenvtlsignoredtest.go:...: export error (expected due to ignored tlsCfg): ... x509: certificate signed by unknown authority --- PASS: TestEnvTLSIgnored PASS
This demonstrates that the env CA is parsed into cfg.tlsCfg but ignored by the default gRPC dial path.
Impact
This is improper TLS certificate validation and endpoint authentication caused by ignoring configured trust material. Users of the OTLP log gRPC exporter who configure TLS, CA pinning, or mTLS through environment variables are impacted when they do not also supply explicit WithTLSCredentials. TLS still occurs with system roots, but the intended private CA pinning and client certificate authentication are bypassed. An attacker with a suitable network position and a system-trusted certificate for the collector endpoint can intercept or tamper with log telemetry that operators expected to be protected by the configured CA or mTLS policy.
Other sources
OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to version 0.21.0, the exporters/otlp/otlplog/otlploggrpc package loads OTELEXPORTEROTLPLOGSCERTIFICATE, OTELEXPORTEROTLPCERTIFICATE, 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.
— MITRE
OpenTelemetry-Go: Log gRPC exporter ignores env TLS certs, bypassing mTLS/pinning
— Microsoft
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpcto a version that resolves this vulnerability.Fixed in 0.21.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.7.0-1 - Upgrade
Upgrade
pellared/opentelemetry-goto a version that resolves this vulnerability.Fixed in 0.21.0 - Configuration
Ensure the gRPC dial path uses the TLS configuration derived from environment variables (cfg.tlsCfg built from OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE/OTEL_EXPORTER_OTLP_LOGS_CLIENT_CERTIFICATE and related env vars). Concretely, pass the resolved cfg.tlsCfg through WithTLSCredentials so env CA pinning and client certificates are enforced instead of falling back to system roots/credentials.NewTLS(nil).
OpenTelemetry-Go OTLP Log gRPC exporter (exporters/otlp/otlplog/otlploggrpc) TLS credentials wiring for env-based TLS = WithTLSCredentials(cfg.tlsCfg)
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using the OTLP log gRPC exporter before version 0.21.0 are exposed when they rely only on the OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, or related client-certificate environment variables for TLS configuration. Deployments that also explicitly provide WithTLSCredentials are not described as using the affected environment-only path.
What must an attacker be able to do to exploit this?
An attacker must be able to intercept or spoof the connection to the telemetry collector and present a certificate trusted by the system trust store. This can allow the attacker to read or alter exported log telemetry.
Why do private CA pinning and mutual TLS settings fail in affected configurations?
The exporter loads the environment TLS settings into its configuration, but does not apply that TLS configuration when creating gRPC transport credentials. It instead uses system roots and omits the configured client certificate, so private CA and client-certificate settings supplied only through environment variables are bypassed.
What can be done before upgrading?
Explicitly supply TLS credentials with WithTLSCredentials rather than relying solely on the TLS-related environment variables. Upgrade to version 0.21.0 to obtain the fix.