CVE-2026-81872 in OpenTelemetry
Summary
by MITRE • 09/16/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified within OpenTelemetry-Go prior to version 0.21.0 represents a significant resource exhaustion flaw located specifically within the BatchingProcessor component of the go.opentelemetry.io/otel/sdk/log package. This issue arises from an inefficient handling mechanism when asynchronous log emissions overwhelm the internal export buffer while the underlying exporter is experiencing backpressure conditions. The core architectural design involves wrapping the primary exporter with a newBufferExporter instance configured with a batch size of one, which dictates how logs are queued and subsequently dispatched for processing. Under normal operational circumstances, this batching strategy optimizes throughput by grouping log records; however, it introduces a critical flaw in error handling during high-load scenarios where the export destination cannot keep pace with incoming data volume.
The technical root cause lies in the polling loop logic of the BatchingProcessor, which relies on a combination of queue operations and trigger signaling to manage workload distribution. When logs are emitted at a rate that exceeds the exporter's capacity, the processor attempts to dequeue items from the internal queue using TryDequeue and subsequently tries to enqueue them into the bufferExporter via EnqueueExport. Crucially, if this non-blocking EnqueueExport operation fails due to backpressure or buffer saturation, it returns an error without removing the item from the source queue. The current implementation logic dictates that whenever the queue length remains at or above the specified batchSize, the processor immediately signals pollTrigger to initiate another polling cycle. Because the failed enqueue does not reduce the queue size, this condition persists indefinitely, causing the loop to retry the same operation repeatedly in a tight CPU-bound sequence without yielding control back to the system scheduler via its ticker mechanism.
This behavior results in an infinite busy-wait state that consumes nearly one hundred percent of available CPU resources for the embedding process or application thread running the telemetry agent. The operational impact is severe, leading directly to service degradation and potentially causing a complete denial of service condition within the host environment. Applications relying on OpenTelemetry-Go for observability data may find their primary functionality compromised as system resources are diverted entirely to futile retry attempts rather than executing business logic or handling legitimate network requests. This aligns with CWE Category 789, which classifies such issues as a Race Condition leading to Resource Exhaustion, and specifically reflects ATT&CK technique T1496, representing Resource Hijacking where an attacker can exhaust system resources through automated high-frequency operations triggered by log injection or sustained traffic patterns designed to trigger the backpressure condition.
Mitigation for this vulnerability requires upgrading the OpenTelemetry-Go library to version 0.21.0 or later, which implements a corrected polling strategy that properly handles export failures and incorporates appropriate wait intervals when buffers are full. In environments where immediate patching is not feasible, operators should consider implementing rate limiting on log emission sources to prevent sudden spikes in throughput from overwhelming the exporter buffer. Additionally, configuring exporters with more robust backpressure handling mechanisms or switching to synchronous logging modes during high-load periods can reduce the likelihood of triggering this specific code path. Monitoring CPU usage metrics for telemetry agents and setting up alerts for abnormal resource consumption patterns can also serve as an effective detection mechanism for identifying when such a condition is occurring in production systems, allowing for rapid intervention before total service disruption occurs.