CVE-2026-81870 in OpenTelemetry-Go
Summary
by MITRE • 09/16/2026
OpenTelemetry-Go is the Go implementation of OpenTelemetry. From version 1.5.0 to 1.44.0, sdk/trace.NewTracerProvider emits a TracerProvider created internal Info-level diagnostic event whose MarshalLog implementations recursively include span processor, exporter, and client configuration. Applications that call otel.SetLogger to enable OpenTelemetry internal Info logging can therefore record OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. A person or system with access to those logs can learn internal collector topology and can recover credentials or tokens embedded in Zipkin URL user information or query strings. The default OpenTelemetry logger does not emit the event, and this path does not log OTLP authentication headers, TLS key material, or span payloads. This issue is fixed in version 1.45.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified within the Go implementation of OpenTelemetry, specifically affecting versions from 1.5.0 through 1.44.0, represents a significant information disclosure risk stemming from improper logging practices during tracer provider initialization. The core technical flaw resides in the sdk/trace.NewTracerProvider function, which emits an internal Info-level diagnostic event when creating a TracerProvider instance. This event is designed to provide visibility into the tracing configuration for debugging purposes; however, its implementation contains a critical logical error where the MarshalLog method recursively includes sensitive components of the telemetry pipeline. Specifically, this recursive serialization captures detailed configurations for span processors, exporters, and client connections without adequate sanitization or filtering of high-value secrets.
The operational impact of this flaw is substantial when an application developer explicitly enables OpenTelemetry internal Info logging by calling otel.SetLogger with a logger that processes these events. In such scenarios, the resulting log output exposes critical infrastructure topology details, including OTLP gRPC and HTTP collector endpoints as well as complete Zipkin collector URLs. This exposure allows any entity with access to the application logs, whether through direct file system access, centralized logging aggregation systems like ELK or Splunk, or compromised monitoring tools, to map out the internal telemetry architecture. More critically, because the serialization process includes raw configuration strings, it can reveal credentials and authentication tokens embedded within Zipkin URL user information fields or query parameters. This transforms what might appear as benign diagnostic logs into a direct vector for credential theft and lateral movement within the infrastructure.
From a classification perspective, this vulnerability aligns with CWE-532, which covers Information Exposure Through Log Files, as sensitive data is inadvertently written to log outputs that may have broader accessibility than intended by the developer. Furthermore, it relates to CWE-798, Use of Hard-coded Credentials, if those credentials were statically configured in the application settings and subsequently leaked via logs rather than being retrieved securely at runtime. In terms of adversary behavior mapping under MITRE ATT&CK, this flaw facilitates Discovery techniques such as T1005 (Data from Local System) or potentially T1530 (Data from Cloud Storage Object), depending on where the logs are aggregated and accessed by an attacker who has gained initial foothold access to the application environment.
It is important to note that the default OpenTelemetry logger configuration does not emit this specific diagnostic event, meaning applications using standard defaults without explicit internal logging enablement remain unaffected by this particular vector. Additionally, the vulnerability scope is limited; it does not result in the leakage of OTLP authentication headers, TLS key material, or actual span payload data during normal operation. The risk is strictly tied to the initialization phase and the specific configuration structures passed to the tracer provider when internal logging is active. To mitigate this issue, organizations must ensure they are running OpenTelemetry-Go version 1.45.0 or later, where the MarshalLog implementation has been corrected to exclude sensitive endpoint details and credentials from the diagnostic output. For environments already using vulnerable versions, immediate remediation involves upgrading the library and auditing existing log storage systems for any previously recorded instances of exposed collector URLs or embedded tokens, followed by credential rotation if compromise is suspected.