Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

CVE-2026-81872 is a Uncontrolled Resource Consumption vulnerability in go.opentelemetry.io/otel/sdk/log. A fix is available for go.opentelemetry.io/otel/sdk/log — see the affected versions and patch details below.

OpenTelemetry-Go: BatchProcessor can busy-spin when export buffer is full

Also known asGHSA-hjf4-fphr-2h65GO-2026-6615
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 24, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-81872.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs31th percentile — riskier than 31% of all scored CVEsHighest risk
0.00%0.29%0.59%0.88%0.4%0.4%Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐹go.opentelemetry.io/otel/sdk/log

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A BatchingProcessor in go.opentelemetry.io/otel/sdk/log can enter a tight CPU loop when the asynchronous export buffer is full. Under exporter backpressure, attacker-driven high-volume log emission can keep the queue at or above the batch size, causing repeated immediate export retries and a denial of service through CPU exhaustion.

Introduced in commit: 4af9c20

Details

NewBatchingProcessor wraps the exporter with newBufferExporter(exporter, 1) (sdk/log/batch.go:116-122), so the asynchronous export input can fill quickly when the downstream exporter blocks. The poll goroutine dequeues a batch with b.q.TryDequeue, calls b.exporter.EnqueueExport(r), and then immediately sends on b.pollTrigger whenever qLen >= b.batchSize (sdk/log/batch.go:129-165).

bufferExporter.EnqueueExport is non-blocking: it sends to e.input if possible and returns false in the default case when the channel is full (sdk/log/exporter.go:221-248). TryDequeue leaves q.len unchanged when the write callback returns false (sdk/log/batch.go:289-314). Therefore, 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.

PoC

validation-artifact.zip

The validation artifact contains a PoC bundle:

  • validation-artifact.tar:main.go: PoC source.
  • validation-artifact.tar:README.md: build/run notes.
  • validation-artifact.tar:build_failed.log: captured build failure from the validation environment.

The PoC configures a blocking exporter and a BatchingProcessor with WithExportMaxBatchSize(1), WithExportInterval(5*time.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.

Reproduction steps from an affected checkout at commit 4af9c20:

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.

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogo.opentelemetry.io/otel/sdk/logall versions0.21.0go get go.opentelemetry.io/otel/sdk/log@v0.21.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for go.opentelemetry.io/otel/sdk/log, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update go.opentelemetry.io/otel/sdk/log to 0.21.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-81872 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate
ProductFixed inAdvisory
Red Hat Hardened Imagesopentelemetry-collector-main-0.161.0-0.1.hum1RHSA-2026:68272
Red Hat Hardened Imagesopentelemetry-collector-contrib-main-0.161.0-0.1.hum1RHSA-2026:68290
Red Hat Hardened Imagesopentelemetry-collector-k8s-main-0.161.0-0.1.hum1RHSA-2026:68591
Red Hat Hardened Imagescaddy-main-2.11.4-0.4.hum1RHSA-2026:68715
Red Hat Hardened Imagesdistribution-main-3.1.1-0.2.hum1RHSA-2026:68716
Red Hat Hardened Imageshelm3-main-3.22.0-0.2.hum1RHSA-2026:68717
Red Hat Hardened Imageshelm4-main-4.3.0-0.2.hum1RHSA-2026:68729
Red Hat Hardened Imagesgrafana13-2-main-13.2.1-0.5.hum1RHSA-2026:68778

Frequently Asked Questions

### Summary A `BatchingProcessor` in `go.opentelemetry.io/otel/sdk/log` can enter a tight CPU loop when the asynchronous export buffer is full. Under exporter backpressure, attacker-driven high-volume log emission can keep the queue at or above the batch size, causing repeated immediate export retries and a denial of service through CPU exhaustion. Introduced in commit: 4af9c20 ### Details `NewBatchingProcessor` wraps the exporter with `newBufferExporter(exporter, 1)` (`sdk/log/batch.go:116-122`), so the asynchronous export input can fill quickly when the downstream exporter blocks. The po
O3 Security · Impact-Aware SCA

Is CVE-2026-81872 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-81872: log DoS — Fixed in 0.21.0