OpenTelemetry-Go CVE-2026-81872

Applies only to applications using go.opentelemetry.io/otel/sdk/log with the BatchProcessor (BatchingProcessor via NewBatchingProcessor) prior to version 0.21.0. Exploitation requires two concurrent conditions: (1) the attacker can drive sustained, high-volume log emission through the processor, and (2) the wrapped exporter is backpressured/slow so that non-blocking EnqueueExport calls fail while the queue remains at or above batchSize - only then does the poll loop retry without waiting for its ticker and busy-spin. The SimpleProcessor is not affected, and a fast/healthy exporter avoids the tight loop. No authentication is required (PR:N) and no user interaction is needed, but the AT:P attack requirement (dependence on exporter backpressure state) is the primary limiting factor.

This is a moderate, availability-only issue - a CPU busy-spin denial-of-service (CWE-400) in the go.opentelemetry.io/otel/sdk/log BatchProcessor, not a code-execution or data-exposure flaw. The vendor CVSS 4.0 vector (6.3, AV:N/AC:L/AT:P/PR:N/UI:N with only VA:L) is internally consistent with the description: network-reachable and unauthenticated, but the single impact is partial availability degradation, and AT:P correctly captures that exploitation is not unconditional - it requires the exporter to be in a backpressured state so that non-blocking EnqueueExport keeps failing while the queue stays at/above batchSize. There is no EPSS score, no CISA KEV listing, and no public exploit in the provided data, so this should be treated as no public exploit identified at time of analysis rather than an active threat. The realistic priority is low-to-moderate: it is a reliability/resilience bug that an attacker can only trigger indirectly by driving log volume against an already-slow/backpressured exporter, and the worst case is CPU exhaustion degrading the embedding process rather than a clean remote kill. Note the vendor scored availability as VA:L despite the description saying service can be 'denied'; the AT:P requirement and the drop-oldest ring-buffer 'release valve' likely justify the partial rather than total rating.

An attacker who can influence the rate of log records emitted by a Go service using the affected sdk/log BatchProcessor floods it with log activity while the downstream exporter is slow or backpressured (e.g., a stalled collector). Failed non-blocking EnqueueExport calls leave the queue length unchanged, so the poll loop re-signals pollTrigger immediately without waiting for its ticker, pinning a CPU core and degrading or denying the host process. No public proof-of-concept is referenced; exploitation is conditional on exporter backpressure.