GHSA-w34q-cm8f-9c5x: Go/go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc vulnerability
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.
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 - Configuration
Patch the gRPC dial path (newGRPCDialOptions in exporters/otlp/otlplog/otlploggrpc/client.go:83-92) so that environment-resolved TLS material in cfg.tlsCfg is actually enforced when creating the gRPC transport credentials; do not ignore cfg.tlsCfg. This addresses the behavior where the exporter loads env CA/cert into cfg.tlsCfg (loadEnvTLS in config.go:451-492) but the default dial path trusts system roots and omits the env-supplied client certificate unless WithTLSCredentials is explicitly wired.
OTLP log gRPC exporter (exporters/otlp/otlplog/otlploggrpc) gRPC transport TLS credentials selection = Use cfg.tlsCfg (built from OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE and OTEL_EXPORTER_OTLP_LOGS_CLIENT_CERTIFICATE/KEY) when creating gRPC transport credentials instead of falling back to system roots / credentials.NewTLS(nil)
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using the OTLP log gRPC exporter are exposed if they rely on OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, or related client-certificate environment variables to provide a custom CA bundle or mTLS client identity.
What access does an attacker need to exploit it?
An attacker must be able to intercept or spoof the connection between the exporter and the OTLP collector, and present a certificate trusted by the system trust store. Under those conditions, the attacker can read or alter exported log telemetry.
How can I determine whether my configuration is affected?
Check whether the affected exporter is configured through the listed OTLP certificate or client certificate environment variables. In the path where explicit gRPC credentials and insecure mode are not set, the exporter does not apply the resolved TLS configuration when creating transport credentials.