GHSA-w9wp-h8wv-79jx
MEDIUMGHSA-w9wp-h8wv-79jx is a medium-severity (CVSS 5.3) CWE-770 vulnerability in opentelemetry_sdk. O3 Security confirms whether GHSA-w9wp-h8wv-79jx is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
opentelemetry_sdk has unbounded memory allocation in W3C Baggage propagation
Real-World Exposure
opentelemetry_sdkReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Summary
BaggagePropagator::extract_with_context in opentelemetry_sdk did not enforce the W3C Baggage size limits before parsing an inbound baggage header. A large attacker-controlled header could cause unnecessary CPU work and short-lived heap allocations while parsing entries that would later be discarded by the SDK's baggage storage limits.
The SDK now applies limits aligned with the W3C Baggage limits:
- 64 list-members
- 8192 bytes total
Impact
Services that accept untrusted inbound propagation headers may experience increased per-request resource usage when processing oversized baggage headers. This can contribute to denial-of-service risk, especially when application or transport-level header limits are absent or configured above the W3C Baggage limits.
The impact is limited to availability. This issue does not expose telemetry data, modify telemetry data, or allow code execution.
Patches
Upgrade opentelemetry_sdk to version 0.32.1 or later.
Version 0.32.1 rejects baggage header values larger than 8192 bytes and limits extraction to the first 64 list-members.
Workarounds
If upgrading immediately is not possible, reject or limit inbound baggage headers larger than 8192 bytes before invoking OpenTelemetry propagation extraction. This can be enforced at a proxy, gateway, middleware layer, or custom carrier boundary.
Resources
- W3C Baggage limits: https://www.w3.org/TR/baggage/#limits
- Related OpenTelemetry Java advisory: https://github.com/open-telemetry/opentelemetry-java/security/advisories/GHSA-rcgg-9c38-7xpx
- Related OpenTelemetry Go advisory: https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475
- CVE-2026-48504
Credit
tonghuaroot
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | opentelemetry_sdk | all versions | 0.32.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for opentelemetry_sdk. 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 opentelemetry_sdk to 0.32.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w9wp-h8wv-79jx 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-w9wp-h8wv-79jx 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-w9wp-h8wv-79jx. 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-w9wp-h8wv-79jx in your dependencies?
O3 detects GHSA-w9wp-h8wv-79jx across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.