OTel OpenTracing Bridge CVE-2026-45404

Exploitation requires three specific, concurrent conditions: (1) the application must import and use go.opentelemetry.io/otel/bridge/opentracing - core OpenTelemetry SDK users who have not imported this bridge package are not affected; (2) the application must have installed correlation hooks via tracer.NewHookedContext(ctx), which wires up the correlationGetHook read path; and (3) two goroutines must concurrently access the same bridgeSpan instance - one calling Span.SetBaggageItem(...) (the write path) and another calling otelcorrelation.MapFromContext(ctx) (the read path). Exploitation is limited by the non-default nature of the bridge package (only used during OpenTracing-to-OTel migration), the requirement for correlation hooks to be explicitly installed, and the need for concurrent goroutine access to a shared span, which depends on application architecture. Authentication level is not a limiting factor in the traditional sense - any code path reaching the shared span triggers the race.

No CVSS score or EPSS probability was provided for this CVE, which limits quantitative risk comparison. The available qualitative signals point uniformly toward lower real-world priority. The vulnerability requires a specific and non-default software stack: the application must import the OpenTracing bridge package, install correlation hooks via tracer.NewHookedContext, and have concurrent goroutines operating on the same bridgeSpan instance. This combination is uncommon even among OpenTelemetry adopters. Impact, when conditions are met, is total: Go's runtime panic kills the entire process, making availability loss complete and immediate with no graceful degradation. However, a deliberate external attacker triggering this would need the target application to expose concurrent request paths that share a single span - a coincidence of architecture and workload rather than a direct attack primitive. A proof-of-concept exists (noted in the advisory), confirming the race is reproducible, but no public exploit kit or CISA KEV listing indicates broader weaponization. Even a small operations team running a bridge-instrumented service should treat this as a routine patch-cycle fix rather than an emergency, given that upgrading to v1.45.0 is straightforward and no exploitation evidence exists at time of analysis.

An attacker sends a high volume of concurrent HTTP requests to a Go service instrumented with the OpenTelemetry OpenTracing bridge and correlation hooks, where the service's request handler shares a single bridgeSpan across multiple goroutines - for example, in a middleware that propagates baggage context while other goroutines call SetBaggageItem on the same span. The Go runtime detects the concurrent map access and terminates the process with a fatal panic, crashing the service. A proof-of-concept demonstrating this exact pattern has been published as part of the advisory.