Skip to content
Patch Next
Sign inAdd to your agent

← Public intelligence

Go package

go.opentelemetry.io/otel/sdk/log

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 6.3GoAmendedPublished

    OpenTelemetry-Go: BatchProcessor can busy-spin when export buffer is full

    CVE-2026-81872 · GHSA-hjf4-fphr-2h65

    Affected
    • Go go.opentelemetry.io/otel/sdk/log < 0.21.0
    Fixed in
    0.21.0· Vendor fix available
    Issue
    A BatchingProcessor in go.opentelemetry.io/otel/sdk/log can enter a tight CPU loop when the asynchronous export buffer is full. Under exporter backpressure, attacker-driven high-volume log emission can keep the queue at or above the batch size, causing repeated immediate export retries and a denial of service through CPU exhaustion. Introduced in commit: 4af9c20 Details NewBatchingProcessor wraps the exporter with newBufferExporter(exporter, 1) (sdk/log/batch.go:116-122), so the asynchronous export input can fill quickly when the downstream exporter blocks. The poll goroutine dequeues a batch with b.q.TryDequeue, calls b.exporter.EnqueueExport(r), and then immediately sends on b.pollTrigger whenever qLen = b.batchSize (sdk/log/batch.go:129-165). bufferExporter.EnqueueExport is non-blocking: it sends to e.input if possible and returns false in the default case when the channel is full (sdk/log/exporter.go:221-248). TryDequeue leaves q.len unchanged when the write callback…

    Recommended action: Upgrade to 0.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)osv.dev (2)github.com (3)Source checked Evidence →