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