Listen to this Post
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. This vulnerability was introduced in commit 4af9c20. The root cause lies in the interaction between NewBatchingProcessor, which wraps the exporter with newBufferExporter(exporter, 1), and the poll goroutine that dequeues batches using b.q.TryDequeue. After dequeuing, the processor calls `b.exporter.EnqueueExport(r)` and then immediately signals `b.pollTrigger` whenever the queue length remains at or above the batch size. The `bufferExporter.EnqueueExport` method is non-blocking: it attempts to send to `e.input` and returns false if the channel is full. Critically, `TryDequeue` leaves the queue length unchanged when the write callback returns false. Consequently, while the exporter is backpressured, `EnqueueExport` fails, the queue remains at or above one full batch, and the poll loop continuously retriggers itself without waiting for the ticker. This results in a busy-spin retry loop that exhausts CPU resources and degrades or denies service for the embedding application.
DailyCVE Form:
Platform: OpenTelemetry-Go SDK
Version: Before 0.21.0
Vulnerability: CPU busy-spin loop
Severity: Medium
date: 2026-09-16
Prediction: Patch released 0.21.0
What Undercode Say:
cd /workspace/opentelemetry-go
git checkout 4af9c20
mkdir -p validation_poc/busyloop /workspace/validation_artifacts /tmp/batchingprocessor-busyloop-poc
tar -xf /path/to/this/finding/validation-artifact.tar -C /tmp/batchingprocessor-busyloop-poc
cp /tmp/batchingprocessor-busyloop-poc/main.go validation_poc/busyloop/main.go
go build -o validation_poc/busyloop/busyloop ./validation_poc/busyloop
./validation_poc/busyloop/busyloop
go tool pprof -top /workspace/validation_artifacts/busyloop.pprof
Expected program output:
cpu profile written to /workspace/validation_artifacts/busyloop.pprof
Expected profile evidence: hot functions should include (BatchingProcessor).poll, (queue).TryDequeue, and (bufferExporter).EnqueueExport, showing repeated export attempts while the exporter is blocked.
Exploit: (Educational Purposes!)
The PoC configures a blocking exporter and a BatchingProcessor with WithExportMaxBatchSize(1), WithExportInterval(5time.Second), and WithMaxQueueSize(2048). It emits 1000 records, records a CPU profile for 750 ms while the exporter is blocked, then writes /workspace/validation_artifacts/busyloop.pprof.
Protection: from this CVE
Upgrade to OpenTelemetry-Go version 0.21.0 or later. The fix implements a corrected polling strategy that properly handles export failures and incorporates appropriate wait intervals when buffers are full.
Impact:
This is an availability vulnerability: uncontrolled CPU consumption caused by a busy-spin retry loop. Applications using sdk/log BatchingProcessor are impacted when an attacker can cause sustained log emission and the configured exporter or downstream collector is slow, blocked, or otherwise backpressured. The impact is limited to the embedding process but can degrade or deny service for that application.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
