CVE-2026-81872: OpenTelemetry-Go DOS Vulnerability

CVE-2026-81872 Overview

CVE-2026-81872 is a resource exhaustion vulnerability [CWE-400] in the OpenTelemetry-Go SDK log module go.opentelemetry.io/otel/sdk/log. The BatchingProcessor component can enter a tight CPU loop when attacker-driven log emission fills its asynchronous export buffer while the exporter is backpressured. Versions prior to 0.21.0 retry EnqueueExport without waiting for the ticker, exhausting CPU cycles in the embedding process. The issue was fixed in version 0.21.0 of the log SDK.

Critical Impact
Remote attackers can degrade or deny service in any Go application embedding the vulnerable OpenTelemetry log SDK by driving log volume that saturates the export buffer.

Affected Products

go.opentelemetry.io/otel/sdk/log prior to v0.21.0
Go applications embedding the OpenTelemetry-Go log SDK BatchingProcessor
Services using backpressured log exporters with the vulnerable batching pipeline

Discovery Timeline

2026-09-16 - CVE-2026-81872 published to NVD
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-81872

Vulnerability Analysis

The vulnerability resides in the BatchingProcessor poll loop within the OpenTelemetry-Go log SDK. NewBatchingProcessor wraps the exporter with newBufferExporter(exporter, 1), constraining the buffered export channel to a single in-flight batch. The poll loop calls queue.TryDequeue and bufferExporter.EnqueueExport, then immediately signals pollTrigger whenever the queue length remains at or above batchSize.

When the downstream exporter applies backpressure, the nonblocking EnqueueExport fails without draining any records. The queue length stays unchanged, so the condition to signal pollTrigger remains true on the next iteration. The processor retries continuously without waiting for its ticker, consuming a full CPU core.

Root Cause

The root cause is a missing wait or backoff path when EnqueueExport fails under backpressure. Because a failed nonblocking send does not modify queue length, the retry predicate is never falsified, producing a busy loop. This is a classic uncontrolled resource consumption pattern classified as [CWE-400].

Attack Vector

Exploitation requires an attacker to drive sustained log emission at a rate that fills the asynchronous export buffer while the exporter cannot keep up. Any code path that translates attacker-controlled input into log records feeding the BatchingProcessor qualifies. The attack does not require authentication or user interaction and can be triggered remotely against services that log network-observable events. Successful exploitation degrades or fully denies service in the embedding Go process.

No verified proof-of-concept code is published. See the GitHub Security Advisory GHSA-hjf4-fphr-2h65 and GitHub Issue #6797 for maintainer analysis.

Detection Methods for CVE-2026-81872

Indicators of Compromise

Sustained 100% CPU utilization on a single goroutine within a Go service embedding go.opentelemetry.io/otel/sdk/log
Growth in the log export queue depth combined with stalled or failing exporter transmissions
Elevated log emission rate correlated with degraded application throughput or increased request latency

Detection Strategies

Inventory Go binaries and container images for dependencies on go.opentelemetry.io/otel/sdk/log at versions below v0.21.0 using go list -m or SBOM tooling.
Profile suspect services with pprof CPU profiles and look for hot frames inside the BatchingProcessor poll loop, TryDequeue, and EnqueueExport.
Correlate exporter error rates or exporter endpoint unavailability with CPU spikes in workloads that use the log SDK.

Monitoring Recommendations

Alert on process CPU saturation combined with elevated OpenTelemetry log exporter failure counters.
Track goroutine counts and scheduling latency in Go services and trigger investigations when values deviate from baseline.
Monitor log ingestion rates from untrusted request paths and rate-limit sources that generate anomalous volume.

How to Mitigate CVE-2026-81872

Immediate Actions Required

Upgrade go.opentelemetry.io/otel/sdk/log to version v0.21.0 or later and rebuild affected Go services.
Rebuild and redeploy container images or binaries that transitively depend on the vulnerable SDK version.
Verify exporter endpoints are reachable and healthy to reduce backpressure conditions that trigger the loop.

Patch Information

The fix is delivered in GitHub Release v0.21.0 of the sdk/log module. Review the corrective changes in the GitHub Commit Details and GitHub Pull Request #8620. Update go.mod to require go.opentelemetry.io/otel/sdk/log v0.21.0 and run go mod tidy to propagate the change.

Workarounds

Where upgrading is not immediately possible, replace BatchingProcessor with SimpleProcessor for log pipelines exposed to attacker-controlled input.
Apply application-level rate limiting on log-producing endpoints to prevent sustained queue saturation.
Ensure log exporter destinations are provisioned with sufficient capacity to avoid persistent backpressure on the SDK.

bash

# Configuration example
go get go.opentelemetry.io/otel/sdk/log@v0.21.0
go mod tidy
go build ./...