opentelemetry-java: Quadratic CPU consumption in W3C tracestate parsing
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.67.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The OpenTelemetry Java SDK and API, specifically its W3C trace context propagator used when extracting tracestate headers from incoming requests, are affected. An unauthenticated attacker sending crafted headers with long runs of spaces or tabs can force excessive CPU use, potentially tying up request or event-loop threads, though the practical effect depends on header size limits, proxies, and threading setup.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
opentelemetry-java is the Java implementation of the OpenTelemetry API for recording telemetry, and SDK for managing telemetry recorded by the API. Prior to 1.67.0, W3CTraceContextPropagator.extract() uses regex delimiter processing that can exhibit quadratic backtracking while parsing tracestate headers containing long runs of spaces or tabs without a following comma. An unauthenticated attacker whose headers reach extraction can repeatedly block request or event-loop threads and cause excessive CPU consumption, with practical impact bounded by ingress header-size limits, proxy configuration, and threading. This issue is fixed in version 1.67.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- open-telemetry opentelemetry-java
fixed in 1.67.0
- io.opentelemetry:opentelemetry-apiMaven
fixed in 1.67.0