Python 的 `str.lower()` 如何变成安全漏洞：错的不是小写，而是 Unicode 版本
Python 安全开发者 Seth Larson 披露，标准库 stringprep 在实现旧版国际化域名规则时调用了当前 Unicode 数据对应的 str.lower()，而协议要求固定使用 Unicode 3.2.0 的大小写折叠规则。这一差异被编号为 CVE-2026-17084。
林岚
Python 安全开发者 Seth Larson 披露，标准库 stringprep 在实现旧版国际化域名规则时调用了当前 Unicode 数据对应的 str.lower()，而协议要求固定使用 Unicode 3.2.0 的大小写折叠规则。这一差异被编号为 CVE-2026-17084。
一句话结论：安全漏洞不一定来自危险函数；当协议要求“永远按 2002 年的字符表解释”，一个持续升级、行为正确的 str.lower() 反而会制造跨系统不一致。
域名系统最初只支持 ASCII，但全球用户使用的文字远不止拉丁字母。IDNA 会把 Unicode 域名转换成可放入 DNS 的 ASCII 形式。Python 内置的 str.encode("idna") 实现的是 IDNA 2003，其中 NamePrep 又依赖 RFC 3454 定义的 StringPrep。
关键在“固定版本”。RFC 3454 的 B.2、B.3 表基于 Unicode 3.2.0。无论今天解释器使用 Unicode 17 还是未来版本，同一个输入都应该得到协议当年规定的结果。Python 的 stringprep 模块虽然导入了专用的 unicodedata.ucd_3_2_0 数据库，某个回退分支却直接执行 code.lower()，于是用上了解释器当前的 Unicode 规则。
Larson 用 Cherokee 字符 U+13A0 举例：按 RFC 3454 应得到一种 Punycode，按 Unicode 17 的大小写折叠却会得到另一种。两个都像合法域名，危险恰恰在这里——客户端、证书系统、过滤器或服务器若使用不同规则，可能对“它们是不是同一个名字”得出不同答案。
这种漏洞属于 interpretation conflict，也就是解释冲突。它不一定让攻击者直接执行代码，但可能破坏域名允许列表、证书匹配、反钓鱼检查或访问控制的前提。NVD 记录显示，问题影响 CPython 的 stringprep 与 idna 模块；公开记录暂未给出 NIST 自己的严重性评分，并注明影响集中于 Unicode 3.2.0 之后新增或属性发生变化的字符。
修复方法并不是冻结整个 Python 的 Unicode 支持，而是枚举当前规则与 Unicode 3.2.0 的差异，为这个特定协议补充例外，使旧算法继续按旧表运行。问题不在 lower() 写得差，而在调用者忘了自己实现的是一个带版本锁定的线缆协议。
开发者还应区分 IDNA 2003 与 IDNA 2008。Larson 建议新应用通常使用 PyPI 上的 idna 包实现较新的标准，而不是继续依赖内置 codec；但兼容老系统时仍可能必须处理 IDNA 2003，所以不能简单删除旧行为。升级到包含修复的 Python 版本，并在域名安全边界统一规范化实现，比在业务代码里多调用一次 .lower() 靠谱得多。
关键事实
- 漏洞编号：CVE-2026-17084。
- 影响模块：CPython 标准库
stringprep和 IDNA 2003 codec。 - 根因：协议固定 Unicode 3.2.0，代码却在一处分支使用解释器当前 Unicode 的小写规则。
- 修复方向：为版本差异建立例外表，使行为回到 RFC 3454。
OC 判断
这类问题提醒我们，协议实现中的“版本”也是输入。凡是涉及域名、证书、用户名和签名的规范化，都必须把 Unicode 版本、大小写折叠和字符禁止表写进测试，而不是相信语言运行时永远替你做对。
为什么重要
- 对 Python 开发者：使用国际化域名时应升级补丁，并明确依赖 IDNA 2003 还是 2008。
- 对安全团队：允许列表和认证链两端必须使用相同的规范化规则。
- 对普通用户：视觉相似只是风险的一部分，不同系统对同一字符得出不同域名才更隐蔽。
评论
围绕这篇文章补充信息、提出问题或分享观察。