GHSA-45rx-2jwx-cxfr is a high-severity (CVSS 7.5) CWE-248 vulnerability in @opentelemetry/propagator-jaeger. O3 Security confirms whether GHSA-45rx-2jwx-cxfr is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenTelemetry JavaScript: Denial of service in `JaegerPropagator` via unhandled exception on a malformed header
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
@opentelemetry/propagator-jaegernpmDescription
Summary
@opentelemetry/propagator-jaeger decodes incoming HTTP header values with decodeURIComponent() without handling decode errors. A single request carrying a malformed percent-encoded value (for example a bare %) in an uber-trace-id or uberctx-* header throws an uncaught URIError, terminating any Node.js process that uses JaegerPropagator as its active propagator.
Impact
Denial of Service: Any unauthenticated remote attacker who can send an HTTP request to a service that has JaegerPropagator registered as the global propagator (e.g. via OTEL_PROPAGATORS=jaeger or propagation.setGlobalPropagator(new JaegerPropagator())) can terminate the process with a single request. Confidentiality and integrity are not affected.
Am I affected?
This issue affects only a specific, opt-in configuration. If you use OpenTelemetry's default propagators (W3C TraceContext and Baggage), you are not affected.
You are affected only if you have registered JaegerPropagator as the active propagator. Check for:
@opentelemetry/propagator-jaegerin your dependency tree, andOTEL_PROPAGATORSset tojaeger(Jaeger only), or a directpropagation.setGlobalPropagator(new JaegerPropagator())call in your code.
Note: if JaegerPropagator is combined with other propagators through a CompositePropagator (for example OTEL_PROPAGATORS=jaeger,tracecontext), the process does not terminate - the composite propagator catches the error - but affected requests silently fail to extract context. You should still upgrade.
Patched versions
@opentelemetry/propagator-jaeger2.9.0
Remediation
Update @opentelemetry/propagator-jaeger to 2.9.0 or later. The propagator now ignores header values it cannot decode instead of throwing.
Interim mitigation (if you cannot update): Trace-context headers should never be accepted unfiltered from untrusted callers. Until you can upgrade, strip or validate the uber-trace-id and uberctx-* headers on inbound requests at your edge - for example with a reverse proxy, API gateway, or load balancer (nginx, Envoy, etc.) - so that only trusted upstream services can set them.
Details
JaegerPropagator.extract() calls decodeURIComponent() on raw header values at two unguarded call sites: the uber-trace-id trace header and each uberctx-* baggage value. decodeURIComponent() throws URIError: URI malformed on invalid percent-encoding. Because the HTTP instrumentation extracts context before its request-handler error wrapper, and a single configured propagator is not wrapped in a CompositePropagator (which would otherwise catch the error), the exception propagates as an uncaughtException and terminates the process.
Proof of concept
Against a service using JaegerPropagator:
curl -H 'uberctx-user: %' http://target/
# or
curl -H 'uber-trace-id: %' http://target/
The Node.js process exits with URIError: URI malformed and subsequent requests are refused.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @opentelemetry/propagator-jaeger | all versions | 2.9.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @opentelemetry/propagator-jaeger. 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/propagator-jaeger to 2.9.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-45rx-2jwx-cxfr 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-45rx-2jwx-cxfr 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-45rx-2jwx-cxfr. 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-45rx-2jwx-cxfr in your dependencies?
O3 detects GHSA-45rx-2jwx-cxfr across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.