Vulnerability in opentelemetry_sdk (CVE-2026-48504)
Summary
Vulnerability in opentelemetry_sdk (CVE-2026-48504). Risk of unauthorized operations or information disclosure. Exploitable via opentelemetry_sdk. Mitigation: upgrade to 0.32.1 or later.
Original description
The description as published by the source.
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 adv…
Source: GitHub Security Advisories (Global) NVD GitHub Advisory
Auto-generated summary
Assembled by SecPulse from the source data (CVSS, CWE, affected versions) using templates — no AI involved. Check the original description and references below for exact details.
A vulnerability tracked as CVE-2026-48504 has been found in opentelemetry_sdk.
Attackers can target a specific entry point like opentelemetry_sdk over the network to misuse the product.
Risk of unauthorized operations or information disclosure. CVSS score: 5.3/10.
What to do: upgrade opentelemetry_sdk to 0.32.1 or later.
If unsure, ask your IT team or search "opentelemetry_sdk CVE-2026-48504" on the vendor's site.
CVE-2026-48504 (opentelemetry_sdk) — CWE-770 / CVSS v3 5.3
Attack vector: remote (network-reachable) / unauthenticated / no user interaction
Attack surface: opentelemetry_sdk / baggage
Patched: 0.32.1 — apply immediately
Plan: 1) Audit SBOM/dependencies, 2) Stage→prod upgrade, 3) Add WAF/proxy monitoring on affected endpoints, 4) Hunt IOCs in logs.
Refs: see the GHSA / vendor advisory / patched release linked on this page.
A vulnerability (CWE-770) exists in opentelemetry_sdk. Attackers reach the vulnerable code path via opentelemetry_sdk without authentication.
Check the vendor advisory for the affected versions of opentelemetry_sdk. Attack surface: opentelemetry_sdk / baggage.
Severity: Medium (CVSS 5.3/10). Risk of unauthorized operations or information disclosure.
Update to 0.32.1.
Until the patch is applied: disable the affected feature, apply WAF rules, or restrict access via network ACLs.
Search webserver/proxy logs for unusual request patterns matching this CVE's known IOCs. Run grep -r 'opentelemetry_sdk' . against your dependency files (package-lock.json, requirements.txt, go.sum) to find affected services.
Response actions
Concrete steps and command examples for SOC/SRE teams to execute in order
-
1Identify exposure identify
grep -r 'opentelemetry_sdk' . | grep -v node_modulesリポジトリと本番環境の依存ファイル (package-lock.json / requirements.txt / go.sum / Gemfile.lock 等) で
opentelemetry_sdkを grep し、稼働しているサービス・バージョンを把握する。 -
2Apply patch patch
Upgrade opentelemetry_sdk to 0.32.1ステージング環境で 0.32.1 に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスを含めること。
-
3Post-deployment verification verify
Confirm patched version is live in productionパッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番ではアクセスログ・WAF でアラート再発が無いか継続監視。