Aspire 13.2.4 Patches CVE-2026-40894: Baggage Header DoS in OpenTelemetry .NET
Aspire 13.2.4 ships an OpenTelemetry bump for CVE-2026-40894, a Gen0 allocation amplification in baggage, B3, and Jaeger propagator parsing. Update OpenTelemetry.Api and OpenTelemetry.Extensions.Propagators to 1.15.3 even if you are not on Aspire.
Aspire 13.2.4 shipped on April 24 with a single line that matters: “Bumped OpenTelemetry dependencies to address CVE-2026-40894.” The advisory itself, filed against open-telemetry/opentelemetry-dotnet, is the more interesting half of the story. It is a Gen0 allocation amplification in the propagator parsing code, and it ships in OpenTelemetry.Api and OpenTelemetry.Extensions.Propagators versions 0.5.0-beta.2 through any release before 1.15.3. If you are on a recent Aspire 13.2 line, the patch lands by upgrading. If you are on bare ASP.NET Core with manual OpenTelemetry wiring, you have to bump the packages yourself.
How a comma string turns into a Gen0 storm
The vulnerable code paths live in the parsers for the W3C baggage header and the legacy b3 and uber-trace-id (Jaeger) headers. All three split on delimiters before they validate length, so allocation scales linearly with the number of separator characters, not with the amount of real data. A single inbound request like
GET /orders/42 HTTP/1.1
Host: api.example.com
baggage: ,,,,,,,,,,,,,,,,,,,,,,,,,,,,, [...5000 commas...]
triggers the framework to materialize thousands of empty string objects in Gen0 before any of them get inspected. There is no remote code execution and no integrity impact, hence the medium 5.3 CVSS score, but a steady drip of crafted requests will pin GC and stall the server. The CWE classification is CWE-789: Memory Allocation with Excessive Size Value, and the fix in 1.15.3 caps the parser before delimiter splitting.
Where this hits in a typical .NET app
Anything that calls AddOpenTelemetry().WithTracing() and accepts a propagator from inbound HTTP is in scope. That includes default Aspire AppHosts, the standard OpenTelemetry.Extensions.Hosting wiring, and the new Microsoft.Extensions.Telemetry defaults that opt into baggage by default:
builder.Services.AddOpenTelemetry()
.WithTracing(tracing => tracing
.AddAspNetCoreInstrumentation()
.AddSource("OrderService")
.AddOtlpExporter());
// Aspire 13.2 ServiceDefaults wire the same propagators in by default.
// builder.AddServiceDefaults() pulls in baggage + W3C tracecontext.
The AddAspNetCoreInstrumentation call registers a TextMapPropagator chain that runs on every inbound request. There is no opt-in needed for the bug to be reachable; the parsers run unconditionally as soon as a matching header is present.
The minimum viable patch
For Aspire users, aspire stop on the running AppHost and pin the package to 13.2.4:
dotnet workload update
dotnet add package Aspire.AppHost --version 13.2.4
dotnet add package Aspire.ServiceDefaults --version 13.2.4
For projects that reference OpenTelemetry directly, the relevant lines are:
<PackageReference Include="OpenTelemetry.Api" Version="1.15.3" />
<PackageReference Include="OpenTelemetry.Extensions.Propagators" Version="1.15.3" />
<PackageReference Include="OpenTelemetry.Extensions.Hosting" Version="1.15.3" />
Transitive references count. Run dotnet list package --include-transitive --vulnerable after the update to confirm none of your indirect dependencies still pull in a pre-1.15.3 OpenTelemetry.Api. If you operate behind a WAF, the advisory suggests capping baggage, b3, and uber-trace-id headers at 1024 characters as a defense-in-depth layer, but the real fix is the package bump.
Aspire shipping a same-week patch for an upstream OpenTelemetry CVE is a useful signal: the SDK pin in Aspire.ServiceDefaults is no longer something you can ignore until the next minor version. Treat 13.2.x patch releases the same way you treat ASP.NET Core servicing updates.