Source: golang-opentelemetry-otel Version: 1.43.0-4 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for golang-opentelemetry-otel. CVE-2026-81870[0]: | 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. CVE-2026-81871[1]: | OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to | version 0.21.0, the exporters/otlp/otlplog/otlploggrpc package loads | OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, | and related client certificate environment variables through | loadEnvTLS into cfg.tlsCfg, but newGRPCDialOptions does not apply | cfg.tlsCfg when creating gRPC transport credentials. The | environment-only TLS path instead uses credentials.NewTLS with | system roots and no configured client certificate, bypassing | intended private CA pinning and mutual TLS unless the application | also supplies WithTLSCredentials. A network attacker able to | intercept or spoof the collector connection with a system-trusted | certificate can read or alter log telemetry. This issue is fixed in | version 0.21.0. CVE-2026-81872[2]: | OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to | version 0.21.0, the go.opentelemetry.io/otel/sdk/log | BatchingProcessor can enter a tight CPU loop when attacker-driven | log emission fills its asynchronous export buffer while the exporter | is backpressured. NewBatchingProcessor wraps the exporter with | newBufferExporter(exporter, 1), and the poll loop calls | queue.TryDequeue and bufferExporter.EnqueueExport before immediately | signaling pollTrigger whenever the queue remains at or above | batchSize. Because a failed nonblocking EnqueueExport leaves the | queue length unchanged, the processor repeatedly retries without | waiting for its ticker, exhausting CPU and degrading or denying | service in the embedding process. This issue is fixed in version | 0.21.0. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-81870 https://www.cve.org/CVERecord?id=CVE-2026-81870 [1] https://security-tracker.debian.org/tracker/CVE-2026-81871 https://www.cve.org/CVERecord?id=CVE-2026-81871 [2] https://security-tracker.debian.org/tracker/CVE-2026-81872 https://www.cve.org/CVERecord?id=CVE-2026-81872 Regards, Salvatore
