GHSA-w8rr-5gcm-pp58
MEDIUMGHSA-w8rr-5gcm-pp58 is a medium-severity (CVSS 5.3) CWE-789 vulnerability in go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp. O3 Security confirms whether GHSA-w8rr-5gcm-pp58 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
opentelemetry-go: OTLP HTTP exporters read unbounded HTTP response bodies
Blast Radius
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp🐹go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp🐹go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttpReal-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
overview:
this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer without a size cap.
this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection).
severity
HIGH
not claiming: this is a remote dos against every default deployment. claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.
callsite (pinned):
- exporters/otlp/otlptrace/otlptracehttp/client.go:199
- exporters/otlp/otlptrace/otlptracehttp/client.go:230
- exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170
- exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201
- exporters/otlp/otlplog/otlploghttp/client.go:190
- exporters/otlp/otlplog/otlploghttp/client.go:221
permalinks (pinned):
- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199
- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230
- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170
- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201
- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190
- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221
root cause:
each exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error paths, with no upper bound.
impact: a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).
affected component:
- go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp
- go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp
- go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp
repro (local-only):
unzip poc.zip -d poc
cd poc
make canonical resp_bytes=33554432 chunk_delay_ms=0
expected output contains:
[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512
control (same env, patched target):
unzip poc.zip -d poc
cd poc
make control resp_bytes=33554432 chunk_delay_ms=0
expected control output contains:
[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232
attachments: poc.zip (attached)
Fixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp | all versions | 1.43.0 |
| 🐹Go | go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp | all versions | 1.43.0 |
| 🐹Go | go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp | all versions | 0.19.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp to 1.43.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w8rr-5gcm-pp58 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-w8rr-5gcm-pp58 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-w8rr-5gcm-pp58. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w8rr-5gcm-pp58 in your dependencies?
O3 detects GHSA-w8rr-5gcm-pp58 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.