Disclosure summary
### Summary 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 returns `false` (`sdk/log/batch.go:289-314`). Therefore, while the exporter is backpressured, `EnqueueExport` fails, the queue remains at or above one full batch,
Source-specific records & product guidance
Sources retain their own attribution and scoring. Follow the original record to confirm affected versions, fixed releases, and configuration conditions.
GitHub Reviewed Security Advisories · GHSA-hjf4-fphr-2h65
Open original source · Updated Sep 29, 2026
OpenTelemetry-Go: BatchProcessor can busy-spin when export buffer is full
Source severity: MEDIUM / 6.3
| Ecosystem | Package | Affected range | First patched |
|---|---|---|---|
| go | go.opentelemetry.io/otel/sdk/log | < 0.21.0 | 0.21.0 |
Original records & references
- NIST NVD record
- CVE Program record
- github.com — Reviewed advisory
PUBLISHED 2026-09-29T13:59:53-04:00
MODIFIED 2026-09-29T13:59:54-04:00
INGESTED 2026-10-06T11:43:08-04:00