CVE-2026-81872: 
Grafana vulnerability analysis and mitigation

CVE-2026-81872 is a Denial of Service vulnerability in the OpenTelemetry-Go SDK's BatchingProcessor component (go.opentelemetry.io/otel/sdk/log) that allows an unauthenticated network attacker to cause CPU exhaustion via a busy-spin loop. All versions prior to v0.21.0 of the sdk/log module are affected. The vulnerability was published on September 16, 2026, with a fix released in sdk/log/v0.21.0. It carries a CVSS v3.1 base score of 5.3 (Medium) and a CVSS v4.0 base score of 6.3 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is a logic flaw (CWE-400: Uncontrolled Resource Consumption; CWE-834: Excessive Iteration; CWE-835: Loop with Unreachable Exit Condition) in the BatchingProcessor poll goroutine. NewBatchingProcessor wraps the downstream exporter with newBufferExporter(exporter, 1), creating a capacity-one asynchronous export channel. The poll loop calls queue.TryDequeue and then bufferExporter.EnqueueExport; when the export channel is full (backpressured), EnqueueExport returns false non-blockingly, leaving q.len unchanged. Because the queue length remains at or above batchSize, the loop immediately signals pollTrigger again without waiting for the ticker interval, creating a tight CPU spin. An attacker who can trigger sustained high-volume log emission while the downstream exporter or collector is slow or blocked can sustain this condition indefinitely (GitHub Advisory, Fix PR #8620).

Successful exploitation results in uncontrolled CPU consumption within the embedding Go process, degrading or completely denying service to legitimate application operations. The impact is limited to availability (no confidentiality or integrity loss), and is scoped to the affected process rather than subsequent systems. Applications using sdk/log.BatchingProcessor that expose any network-reachable log-emitting surface are at risk; the busy-spin can consume an entire logical CPU core, starving other goroutines and causing service degradation or outright unavailability (GitHub Advisory).

A proof-of-concept exploit (validation-artifact.zip) is publicly available in the GitHub Security Advisory, containing runnable Go source code (main.go) that demonstrates the busy-spin by configuring a blocking exporter and BatchingProcessor, emitting 1,000 records, and generating a CPU profile (busyloop.pprof) confirming the loop (GitHub Advisory). No in-the-wild exploitation has been reported as of the advisory date. The EPSS score is approximately 0.003 (0.3%), indicating low probability of near-term exploitation. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires no authentication and no user interaction, but does require the attacker to be able to trigger sustained log emission and the exporter to be backpressured.

1. Identify target: Locate a Go application using go.opentelemetry.io/otel/sdk/log with BatchingProcessor at a version prior to v0.21.0 that exposes a network-reachable interface capable of triggering log emission (e.g., an HTTP API endpoint that logs requests).
2. Induce exporter backpressure: Ensure the downstream OpenTelemetry collector or exporter is slow, unavailable, or saturated — this can occur naturally under load or by targeting the collector separately. The export channel (capacity 1) fills quickly under these conditions.
3. Flood log emission: Send a high volume of requests to the target application to trigger rapid log record generation. The PoC emits 1,000+ records in rapid succession to fill the BatchingProcessor queue to or above batchSize.
4. Trigger the busy-spin: Once the queue is at or above batchSize and EnqueueExport fails (channel full), the poll goroutine immediately re-signals pollTrigger without waiting for the ticker, entering a tight CPU loop (BatchingProcessor.poll → queue.TryDequeue → bufferExporter.EnqueueExport → repeat).
5. Sustain CPU exhaustion: Continue sending log-triggering requests to maintain the queue above batchSize. The poll goroutine consumes 100% of a CPU core, degrading or denying service to the embedding process (GitHub Advisory).

• Process: Sustained near-100% CPU utilization on a single core by the Go application process, particularly the goroutine running (*BatchingProcessor).poll, (*queue).TryDequeue, and (*bufferExporter).EnqueueExport (visible via go tool pprof CPU profiles or runtime metrics).
• Runtime Metrics: Go runtime goroutine profiles showing the poll goroutine in a hot loop; pprof CPU profiles with top functions including BatchingProcessor.poll, queue.TryDequeue, and bufferExporter.EnqueueExport.
• Application Logs: Increased latency or timeouts in application responses coinciding with high CPU usage; OpenTelemetry SDK internal error messages related to export failures or dropped log records.
• Network: Unusually high volume of inbound requests to log-emitting application endpoints; absence or timeout of outbound connections to the OpenTelemetry collector from the affected process (GitHub Advisory).

Upgrade go.opentelemetry.io/otel/sdk/log to version v0.21.0 or later, which replaces the dual poll-goroutine/buffered-exporter architecture with a single worker goroutine that owns dequeueing and all exporter calls, eliminating the no-progress retry loop (GitHub Release, Fix Commit). If immediate patching is not possible, consider: (1) implementing rate limiting on log-emitting application endpoints to prevent queue saturation; (2) increasing exporter throughput or ensuring collector availability to reduce backpressure; or (3) temporarily disabling BatchingProcessor in favor of SimpleProcessor if the application is under active attack. Note that WithExportBufferSize is deprecated in v0.21.0 and has no effect in the patched version.

The vulnerability was discovered and reported by pellared (a maintainer of the opentelemetry-go project), who also authored the fix in PR #8620. The issue was originally identified as a design concern in GitHub issue #6797 ("sdk/log: Redesign BatchProcessor") before being formally assigned a CVE. Red Hat and Microsoft both tracked the advisory, and it was picked up by OpenSUSE security announcements. No significant broader media coverage or notable external researcher commentary has been identified beyond the upstream project discussion (GitHub Issue #6797, Fix PR #8620).