CVE-2026-45404: Race Condition

Published Aug 20, 2026
·
Updated

Summary

go.opentelemetry.io/otel/bridge/opentracing introduced an unsynchronized extraBaggageItems map on bridgeSpan. One goroutine can write this map through Span.SetBaggageItem while another goroutine reads and iterates it during correlation baggage propagation, which can trigger Go's fatal concurrent map access panic and crash the process. The finding is low severity because exploitation requires a specific OpenTracing bridge configuration and concurrent use of the same span.

Introduced in commit: 8cddf30

Details

bridge/opentracing/bridge.go:80-85 adds extraBaggageItems map[string]string to bridgeSpan without a mutex or other synchronization primitive. bridge/opentracing/bridge.go:219-234 shows SetBaggageItem calling updateOtelContext, which lazily creates the map and writes s.extraBaggageItems[restrictedKey] = value without locking. bridge/opentracing/bridge.go:359-377 shows correlationGetHook reading bSpan.extraBaggageItems, checking len(items), and iterating for k, v := range items without locking. The finding evidence also identifies api/correlation/context.go:160-165 as the path where correlation.MapFromContext invokes the get hook, allowing a read path to run concurrently with baggage writes.

Because Go maps are not safe for concurrent read/write access, concurrent SetBaggageItem and correlation.MapFromContext calls on the same hooked bridgeSpan can terminate the process with a runtime error such as fatal error: concurrent map read and map write or fatal error: concurrent map iteration and map write.

PoC

validation-artifact.zip

The validation artifact contains a PoC at validation-artifact.tar:validationpocconcurrentmap.go and supporting notes at validation-artifact.tar:validationpocREADME.txt.

Use a checkout of pellared/opentelemetry-go at commit 8cddf30 with Go module downloads enabled. The local validation environment could not complete the run because GOPROXY=off blocked dependency resolution; that blocked output is saved in validation-artifact.tar:validationpocrun.log.

Commands:

sh cd /path/to/opentelemetry-go git checkout 8cddf30 tar -xOf /path/to/finding-directory/validation-artifact.tar validationpocconcurrentmap.go > ./validationpocconcurrentmap.go GOPROXY=https://proxy.golang.org,direct go run ./validationpocconcurrentmap.go

The PoC starts a BridgeTracer, creates a span, installs correlation hooks with tracer.NewHookedContext(ctx), initializes baggage once, then runs one goroutine repeatedly calling span.SetBaggageItem(...) while another repeatedly calls otelcorrelation.MapFromContext(ctx). A vulnerable build is expected to terminate with a Go runtime concurrent map access error, for example:

text fatal error: concurrent map read and map write

or:

text fatal error: concurrent map iteration and map write

Impact

This is a race condition / improper synchronization vulnerability in a shared Go map. Applications using the OpenTelemetry OpenTracing bridge with correlation hooks can crash if the same bridgeSpan is accessed concurrently, with one execution path setting baggage and another propagating correlation baggage. The practical impact is denial of service for the affected application process; exposure depends on whether application request handling or internal concurrency can trigger those operations on the same span.

Affected Software

1 affected componentFixes available
go/go.opentelemetry.io/otel/bridge/opentracing>=0.11.0<1.45.0
1.45.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/go.opentelemetry.io/otel/bridge/opentracing to a version that resolves this vulnerability.

    Fixed in 1.45.0

Event History

Aug 20, 2026
Advisory Published
via GitHub·05:26 PM
Data Sourced
via GitHub·05:26 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are realistically exposed to this issue?

Deployments using the OpenTracing bridge with the specific correlation baggage propagation configuration are exposed when the same bridge span is used concurrently. The issue is not described as affecting applications that do not use this bridge path.

2

What must occur for an attacker or workload to trigger the crash?

One goroutine must call Span.SetBaggageItem and write the span's extra baggage map while another goroutine reads and iterates that map during correlation baggage propagation. This concurrent access can cause Go to terminate the process with a fatal concurrent map access panic.

3

How can I identify potentially affected code paths?

Look for concurrent use of a single OpenTracing bridge span where Span.SetBaggageItem may run at the same time as correlation context processing that calls correlation.MapFromContext. The relevant bridge operations are the SetBaggageItem path and the correlation get hook that propagates baggage.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203