OTel 1.67：tracestate 十万空格，抽取从 4 秒到 0

Spring Boot 4.1.2 的 BOM 仍把 opentelemetry.version 钉在 1.62.0。入口若走 W3C 传播抽取，遇到带超长空格、后面又不跟逗号的 tracestate，旧版 opentelemetry-api 会在解析上烧掉数秒 CPU。GitHub 于 2026-10-28 发布的 GHSA-ccrj-gw8r-854m（CVE-2026-118259）写明：升到 io.opentelemetry:opentelemetry-api 1.67.0 或更高。同输入对照：1.62.0 抽取约 4119 ms，1.67.0 为 0 ms。

许可证 Apache-2.0。仓库 open-telemetry/opentelemetry-java。主源见上述 GHSA、官方安全公告同页，以及修复 PR #8914、v1.67.0 发布说明。

场景

服务在网关或 Filter 里调用 W3CTraceContextPropagator.extract，把上游的 traceparent / tracestate 接进当前 Context。正常成员形如 vendor=value，成员之间用逗号分隔，逗号两侧允许空格或制表符。

官方公告描述的问题是：当 tracestate 里出现很长一串空格或制表符、后面又不跟逗号时，1.66.0 及更早版本用正则 [ \t]*,[ \t]* 做分隔，回溯会让解析时间近似平方增长，调用线程被拖住。公告原话是 permits excessive CPU consumption when extracting crafted tracestate headers。

Spring Boot 4.1.2 若用了 spring-boot-starter-opentelemetry 或 Micrometer Tracing 的 OTel 桥，BOM 默认仍是 1.62.0，落在受影响区间（GHSA：<= 1.66.0）。Boot 4.2.0-RC1 的 BOM 已经改成 1.67.0。

两个独立进程

同一台机器、JDK 21.0.12.1，两个独立 fat jar，分别打进 opentelemetry-api 1.62.0 与 1.67.0。输入对齐官方回归用例：foo=bar 后面跟 100000 个空格，再跟一个 x（中间没有逗号）。只测一次 extract 的耗时：

java -Dotel.api.version=1.62.0 -jar v162/target/otel-tracestate-162-0.0.1.jar 100000

java -Dotel.api.version=1.67.0 -jar v167/target/otel-tracestate-167-0.0.1.jar 100000

1.62.0（摘录）：

otel-api-version=1.62.0
padding-spaces=100000
tracestate-length=100008
extract-elapsed-ms=4119
trace-id=ff000000000000000000000000000041
valid=true
tracestate-size=0

1.67.0（摘录）：

otel-api-version=1.67.0
padding-spaces=100000
tracestate-length=100008
extract-elapsed-ms=0
trace-id=ff000000000000000000000000000041
valid=true
tracestate-size=0

两边 trace 都有效；畸形 tracestate 最终都落到空 TraceState（size=0）。差别只在抽取耗时：1.62.0 约 4.1 秒，1.67.0 不足 1 毫秒。另用 1.66.0 同命令跑过，extract-elapsed-ms=4398，与 GHSA 写的受影响上界一致。

1.67.0 改了什么

PR #8914 去掉正则分隔，改成按字面逗号从后往前扫，空格和制表符只做显式 trim。官方单测 extract_LargeTracestateWhitespace 用 100000 个空格或制表符，并加了 5 秒超时——对应的就是上面这种输入。

在 Boot 4.1.2 工程里把版本抬上去，可以覆盖 BOM 属性：

<properties>
  <opentelemetry.version>1.67.0</opentelemetry.version>
</properties>

公告还写了临时办法：在抽取前丢掉或拒绝过大的 tracestate。Header 长度限制能降低单次代价，但按官方说法不能从根上消掉这次回溯问题。