GHSA-HJF4-FPHR-2H65
Vulnerability from github – Published: 2026-09-29 17:59 – Updated: 2026-09-29 17:59Summary
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
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": [
{
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/otel/sdk/log"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.21.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-81872"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-834"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-29T17:59:53Z",
"nvd_published_at": "2026-09-16T21:17:22Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA `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.\n\nIntroduced in commit: 4af9c20\n\n### Details\n\n`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 \u003e= b.batchSize` (`sdk/log/batch.go:129-165`).\n\n`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.\n\n### PoC\n\n[validation-artifact.zip](https://github.com/user-attachments/files/27494002/validation-artifact.zip)\n\nThe validation artifact contains a PoC bundle:\n\n- `validation-artifact.tar:main.go`: PoC source.\n- `validation-artifact.tar:README.md`: build/run notes.\n- `validation-artifact.tar:build_failed.log`: captured build failure from the validation environment.\n\nThe 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`.\n\nReproduction steps from an affected checkout at commit `4af9c20`:\n\n```sh\ncd /workspace/opentelemetry-go\ngit checkout 4af9c20\n\nmkdir -p validation_poc/busyloop /workspace/validation_artifacts /tmp/batchingprocessor-busyloop-poc\ntar -xf /path/to/this/finding/validation-artifact.tar -C /tmp/batchingprocessor-busyloop-poc\ncp /tmp/batchingprocessor-busyloop-poc/main.go validation_poc/busyloop/main.go\n\ngo build -o validation_poc/busyloop/busyloop ./validation_poc/busyloop\n./validation_poc/busyloop/busyloop\ngo tool pprof -top /workspace/validation_artifacts/busyloop.pprof\n```\n\nExpected program output:\n\n```text\ncpu profile written to /workspace/validation_artifacts/busyloop.pprof\n```\n\nExpected profile evidence: hot functions should include `(*BatchingProcessor).poll`, `(*queue).TryDequeue`, and `(*bufferExporter).EnqueueExport`, showing repeated export attempts while the exporter is blocked.\n\n\n### Impact\n\nThis 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.",
"id": "GHSA-hjf4-fphr-2h65",
"modified": "2026-09-29T17:59:53Z",
"published": "2026-09-29T17:59:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-hjf4-fphr-2h65"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81872"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/issues/6797"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/pull/8620"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/commit/ba71b09e6ed272e93a669aeaec1e98b1df4cc582"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-go"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/releases/tag/sdk/log/v0.21.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenTelemetry-Go: BatchProcessor can busy-spin when export buffer is full"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.