CVE-2026-81871: 
Grafana vulnerability analysis and mitigation

CVE-2026-81871 is a TLS configuration bypass vulnerability in the OpenTelemetry-Go OTLP log gRPC exporter (go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc) that allows a network attacker to intercept or tamper with log telemetry via a man-in-the-middle attack. The vulnerability affects all versions of the otlploggrpc package prior to v0.21.0. It was first published on September 2, 2026, and disclosed publicly on September 16, 2026. The CVSS v3.1 base score is 6.5 (Medium) and the CVSS v4.0 base score is 6.3 (Medium) (Github Advisory, Feedly).

The root cause is improper certificate validation (CWE-295) and improper restriction of communication channel to intended endpoints (CWE-923). The newConfig function in config.go correctly loads TLS settings — including CA certificates and client key/certificate pairs — from environment variables (OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, OTEL_EXPORTER_OTLP_LOGS_CLIENT_CERTIFICATE, OTEL_EXPORTER_OTLP_LOGS_CLIENT_KEY) into cfg.tlsCfg via loadEnvTLS. However, newGRPCDialOptions in client.go only checks cfg.gRPCCredentials and cfg.insecure when building gRPC transport credentials; when neither is set (the typical env-only path), it calls credentials.NewTLS(nil), which uses system root CAs and no client certificate, silently discarding the env-configured trust material. A proof-of-concept test (poc_env_tls_ignored_test.go) was included in the advisory, demonstrating that the env CA is parsed but ignored, resulting in an x509: certificate signed by unknown authority error when a private CA is used (Github Advisory, Fix Commit).

Successful exploitation allows a network-positioned attacker holding a system-trusted certificate to intercept (read) or modify (tamper with) OTLP log telemetry data in transit between the application and the OpenTelemetry collector. The confidentiality and integrity of log data are both at risk, while availability is unaffected. Operators who rely on private CA pinning or mutual TLS (mTLS) for collector authentication are most exposed, as those security controls are silently bypassed unless WithTLSCredentials is explicitly supplied in application code (Github Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code is known to be available beyond the validation artifact included in the security advisory itself, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.196% (10th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a network attacker to be in a position to intercept or spoof the gRPC connection to the collector and to possess a certificate trusted by the system root store (Github Advisory, Feedly).

1. Identify target: Locate applications using go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc at versions prior to v0.21.0 that configure TLS exclusively via environment variables (OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, etc.) without also calling WithTLSCredentials.
2. Gain network position: Position yourself on the network path between the application and its OpenTelemetry collector endpoint (e.g., via ARP spoofing, DNS hijacking, or a rogue network device on the same segment).
3. Obtain or use a system-trusted certificate: Acquire a TLS certificate for the collector's hostname that is trusted by the host system's root CA store (e.g., a certificate from a public CA, or one issued by a compromised/rogue CA already trusted by the system).
4. Impersonate the collector: Stand up a rogue gRPC server using the system-trusted certificate, listening on the intercepted connection. Because the vulnerable exporter falls back to credentials.NewTLS(nil) (system roots, no client cert check), it will accept the rogue server's certificate without enforcing the private CA or mTLS policy.
5. Intercept or alter telemetry: Read plaintext log telemetry forwarded by the application, or inject modified log records before forwarding to the legitimate collector, without the application detecting the interception (Github Advisory).

• Network: Unexpected TLS handshakes to the OTLP gRPC collector endpoint using certificates issued by public CAs rather than the expected private CA; gRPC connections to collector endpoints from unusual IP addresses or intermediary hosts.
• Logs: Application-level errors such as x509: certificate signed by unknown authority in OpenTelemetry exporter logs when a private CA is configured via environment variables (may indicate misconfiguration or active interception attempts); unexpected changes in the TLS certificate presented by the collector endpoint as observed via network monitoring.
• Configuration: Presence of OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, or related environment variables set in the application environment without a corresponding WithTLSCredentials option in code — confirming the vulnerable configuration path is active (Github Advisory).

The primary remediation is to upgrade the go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc package to v0.21.0 or later, which fixes the issue by adding a case cfg.tlsCfg.Value != nil branch in newGRPCDialOptions that correctly applies env-configured TLS settings to gRPC transport credentials (Fix Commit, Release v0.21.0). As a workaround prior to patching, applications can explicitly supply TLS credentials using the WithTLSCredentials option when constructing the exporter, which bypasses the broken environment variable path and enforces the intended mTLS or CA pinning configuration (Github Advisory).

The vulnerability was reported by pellared and analyzed by MrAlias (Tyler Yahn) within the OpenTelemetry-Go project, with the fix co-authored by both. Red Hat tracked the issue via Bugzilla (Bug 2535725) with medium severity and assigned it to their Product Security DevOps Team, indicating downstream impact on Red Hat products consuming this Go module (Red Hat Bugzilla). No significant broader media coverage or notable public researcher commentary beyond the official advisory has been identified.