OpenTelemetry-Go: Eager W3C baggage-property materialization causes bounded memory-allocation amplification

Early releases have a 4,096-byte per-member limit. They reproduce the same mechanism with a 4,095-byte member containing 2,046 properties; the 8,191-byte single-member input is rejected there. The 8 KB example and its numerical allocation result must not be projected onto every historical version.

Root cause and input bounds

For the valid dense input, each short property becomes a Go Property, and the slice grows as parsing proceeds. The parser subsequently serializes the member and copies its properties into the internal representation. A two-byte wire fragment can therefore produce substantially more than two bytes of allocation work. Temporary parser objects and internal retained objects must not be added together and described as permanently retained memory.

In the currently measured parser, the raw 8,192-byte limit and 64-member limit still apply. The number of accepted properties is consequently bounded by input length even though there is no separate property-count guard. Eager representation and copying are the defect described here; the absence of an arbitrary count cap is not, by itself, the defect.

The primary input is constructed as "k=v" + strings.Repeat(";a", 4094) (8,191 bytes); the equal-size value-only control is "k=" + strings.Repeat("v", 8189). Call baggage.Parse once for each measured result. To verify the property count separately, inspect bag.Members()[0].Properties() outside the measured interval; this accessor itself allocates. The primary example remains the valid 8,191-byte, 4,094-property input already supplied in this private report. Empty-property input discussed in the maintainer review is malformed and is supplementary parser-hardening evidence, not the standards-compliant primary example or the basis of the severity score.

HTTP reachability and authentication ordering

The Go global propagator is initially a no-op. Installing the library alone does not expose this path. Baggage must be enabled explicitly or by applicable auto-configuration; standardized auto-configuration defaults do not establish an individual application's configuration.

An ordinary HTTP composition can place otelhttp.NewHandler outside the authentication handler. With propagation.Baggage{} enabled and the request not excluded by a filter, the checked otelhttp implementation calls h.propagators.Extract(r.Context(), propagation.HeaderCarrier(r.Header)) before next.ServeHTTP. Authentication inside next therefore runs after extraction, including for a request that is ultimately rejected with 401/403. Reversing the composition so authentication rejects before entering otelhttp prevents this unauthenticated extraction path. This is a source-level ordering check of a normal integration, not a claim about all services or an executed HTTP benchmark.

Source checked: otelhttp handler at ce138eb092f223e4e41e0420c58fc34910bc2b56, extraction at line 98 and downstream handler at line 185. A filter that bypasses instrumentation takes a separate path and is outside this stated composition.

Remote reachability requires all of the following: Baggage extraction is enabled; attacker-controlled input reaches it; the transport and proxy accept the relevant header size; and extraction runs before authentication or on a public route. Material service impact further depends on request rate, concurrency, request lifetime, GC behavior, and resource limits. Authentication is a mitigation only if it precedes extraction. A path that requires a properly authenticated triggering client must also be evaluated under the project's authenticated-client DoS exclusion.