GHSA-w34q-cm8f-9c5x

### 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 `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

### 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 `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.

### PoC

[validation-artifact.zip](https://github.com/user-attachments/files/27493589/validation-artifact.zip)

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:

```sh 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:

```sh 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`:

```text === 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.

### 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.