限制写了却没生效：OpenTelemetry Go 的 Unicode 截断边界
背景与趋势
OpenTelemetry Go 公告发布于 2026-09-02 ，GitHub 数据库在 9 月 29 日 审核收录 CVE-2026-81869。这不是刚发现的新攻击。
遥测通常运行在业务进程内。因此，采集外部输入不仅关系到隐私，也关系到内存预算。把完整请求参数写进 span，即使不参与业务决策，也可能影响业务可用性。
技术原理：合法替换字符并不是非法编码
已确认缺陷涉及字符串和字符串数组属性的长度限制。旧逻辑把解码出的 RuneError 当成非法 UTF-8，清理后再次尝试；但合法编码的 U+FFFD 本身也会解码成这个值，清理不会移除它，最终可能返回未截断的原始输入。
Go 标准库文档提供关键语义：判断解码错误要结合返回宽度，不能仅比较 rune 值。
**工程分析：**一个函数返回特殊值，并不总能单独表达失败。类似的错误也会出现在空结果与未授权、零长度与读取失败、默认枚举与未知状态之间。调用方应遵守接口完整契约，避免丢掉第二个返回值。
更深一层的问题是：清洗后应重新验证目标安全属性。删除非法编码与限制输出长度不是同一操作。只要最终长度不满足约束，无论中间发生了什么，都不能返回原始大对象作为"兼容性回退"。
影响范围与版本
受影响的是 Go SDK trace 相关处理，版本范围为 1.10.0 至小于 1.33.0 ，修复起点 1.33.0 。数据库以模块 go.opentelemetry.io/otel/sdk 标识依赖，项目正文聚焦其 trace 包，两种写法不是两个独立产品。
实际前提包括启用属性长度限制，以及把攻击者可控内容写入 span 属性。已证实的是内存控制减弱，不是一次小输入必然导致进程崩溃，更不是代码执行。项目正文称该发现低严重性，而页面及数据库标为 Moderate；本文保留这个表述差异，不用评分代替暴露分析。
| 验证维度 | 应检查内容 |
|---|---|
| 数据来源 | 属性是否来自外部输入 |
| 限制是否开启 | 配置是否实际传入运行 SDK |
| 字符语义 | 字节、码点还是用户感知字符 |
| 聚合预算 | 属性数量、span 数量、队列深度 |
安全示例：分别验证两种长度预算
下面是 Python 防御性模型，不加载旧 SDK，不制造大内存分配。U+FFFD 通过转义构造，避免把源文件显示问题混入测试。
python
s = 'AB' + '\ufffd' + '中文CD'
def cap_codepoints(value, limit):
if limit < 0:
raise ValueError('negative limit')
return value[:limit]
def cap_bytes(value, limit):
if limit < 0:
raise ValueError('negative limit')
return value.encode('utf-8')[:limit].decode('utf-8', errors='ignore')
for n in range(8):
assert len(cap_codepoints(s, n)) <= n
assert len(cap_bytes(s, n).encode('utf-8')) <= n
assert '\ufffd' in cap_codepoints(s, 3)
print('bounded output checks passed')两种函数实现不同契约，不能随意互换。实际 SDK 的长度语义应按对应版本规范和实现确认。示例的意义是要求团队在测试名称里明确单位，并在输出端断言上限。
研发与安全团队行动清单
P0：升级与数据最小化
核对最终二进制使用的 SDK 模块，升级至修复版本或包含回补的受支持版本。减少不必要的大字段采集，不把完整正文、令牌或秘密放入属性。数据最小化同时改善隐私和资源预算，但不能取代补丁。
P1：把异常字符纳入属性测试
测试空字符串、ASCII、多字节字符、合法 U+FFFD、非法字节以及限制边界。对字符串数组逐项验证，同时验证数组总规模。用固定小样本证明逻辑，不需要对生产服务施加大量数据。
P2：预算应覆盖整个管道
单属性长度限制并不限制属性个数，也不限制队列中的 span 总数。应将采样、队列上限、导出超时和丢弃计数分别纳入监控。日志中记录截断或丢弃数量，避免为调查超长属性而再次记录完整超长内容。
总结
资源安全需要可验证的最终约束。解码成功、清洗成功、截断成功是不同事实。把它们拆开测试，才能避免"配置有上限，输出却无上限"。