OpenTelemetry-Go CVE-2026-81870

Requires the application to have explicitly called otel.SetLogger to enable OpenTelemetry internal Info-level logging - the default OpenTelemetry logger does NOT emit the diagnostic event, so default configurations are unaffected. The disclosed data appears only in the application's own logs, so an attacker must already have read access to those logs (local files, log aggregation, or SIEM). Value is further limited to what is actually configured: internal collector endpoints, the OTLP HTTP Insecure flag, and Zipkin collector URLs; credential recovery only occurs if operators embedded tokens in Zipkin URL user-info or query strings. OTLP authentication headers, TLS key material, and span payloads are never logged, capping the exposure.

This is a genuine but very low-severity information-disclosure issue, and the signals agree: vendor CVSS 4.0 base score is 2.0 (AV:L/AC:L/AT:P/PR:L/UI:N/VC:L only), CWE-200. There is no EPSS score, no CISA KEV listing, and no public exploit - exploitation status is 'no public exploit identified at time of analysis.' The AT:P (attack requirement present) and the description together confirm this only manifests under a non-default condition: the application must call otel.SetLogger to enable OpenTelemetry internal Info-level logging; the default logger does not emit the event. Even when triggered, impact is limited to VC:L (endpoints, the OTLP HTTP Insecure flag, and Zipkin URLs that may carry embedded credentials) - no integrity or availability impact, and the vendor explicitly notes OTLP auth headers, TLS key material, and span payloads are NOT logged. The real risk is secondary: it depends entirely on who can read the application's logs and whether operators put credentials in Zipkin URL user-info/query strings. This is a hardening/hygiene fix, not an urgent priority. No conflicting signals were found; the low CVSS and absence of exploitation evidence are mutually consistent.

An application enables OpenTelemetry internal Info logging via otel.SetLogger and initializes a TracerProvider; the SDK writes a diagnostic event whose MarshalLog serializes exporter/client configuration into the logs, including collector endpoints and full Zipkin URLs. A person with access to those logs (e.g., a log aggregation platform, SIEM, or shared log files) reads them to map internal collector topology and recover any credentials embedded in the Zipkin URL. No public exploit code exists; the 'attack' is passive log inspection requiring prior local/log access.