
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: < 0.21.0
Patched in 0.21.0
Details
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 OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, 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
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 OTEL_EXPORTER_OTLP[_LOGS]_CERTIFICATE and OTEL_EXPORTER_OTLP[_LOGS]_CLIENT_CERTIFICATE/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.
The validation artifact contains a ready-to-run test at validation-artifact.zip:./poc_env_tls_ignored_test.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:
FINDING_DIR=/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 ./poc_env_tls_ignored_test.go > exporters/otlp/otlplog/otlploggrpc/poc_env_tls_ignored_test.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:
OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://127.0.0.1:<test-port>
OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE=<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:
=== RUN TestEnvTLSIgnored
poc_env_tls_ignored_test.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.
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.
EPSS, exploit probability
Low0.20%
estimated chance of real-world exploitation in the next 30 days, higher than 9.4% of every CVE FIRST.org scores
Refreshed 11/2/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.