一个主机名末尾多出来的点，在 curl 项目和漏洞编号体系之间引发了一场持续四个多月的拉锯。2026 年 6 月 24 日，这场争议以 MITRE 的一纸判决收尾：不分配 CVE 编号。同一天，curl 发布 8.21.0，一次性修复了多个与主机名尾点有关的问题，其中包括一个拿到了编号的低危漏洞。把这两件事放在一起看，正好能回答一个开发者迟早会碰到的问题：一个安全问题的 CVE 编号，到底是谁说了算。
先把角色说清：CVE、CNA、MITRE
要理解这场争议，得先弄清楚三个角色的分工。
CVE（Common Vulnerabilities and Exposures） 是安全漏洞的统一编号体系。一个漏洞拿到 CVE 编号，才会进入各大厂商的漏洞数据库，触发补丁管理工具的告警、合规审计的检查项、安全团队的工单流程。没有编号，漏洞在评估体系里就不存在。
CNA（CVE Numbering Authority，CVE 编号授权机构） 是 CVE 体系里的"片区警局"。MITRE 作为 CVE Program 的运营方，把特定范围的编号分配权下放给各机构和项目：微软给微软的产品编号，红帽给红帽的产品编号。curl 项目几年前注册成为 CNA，从那以后，curl 自己的漏洞要不要发编号，由 curl 安全团队自己决定。
MITRE 是这套体系的最上游仲裁方。当报告者和 CNA 意见不合时，报告者可以申诉到 MITRE，由它做最终裁决。
这个设计本来是为了双赢。Stenberg 在博客里回顾，成为 CNA 之前，curl 也遇到过外部机构给"伪漏洞"强行编号的麻烦；成为 CNA 后，分配编号变成一次 API 调用的事，几年来 curl 已经发布了 57 个 CVE。每次评估都从同一个问题开始：这到底是不是一个安全漏洞？是的话，再定 LOW、MEDIUM、HIGH 或 CRITICAL 级别。
争议主角：主机名开头的一个点
事情要从一个看起来不可能出现在 URL 里的主机名说起。
Stenberg 给出的例子是 https://.example.com/，主机名以点开头。这种名字在 DNS 里是非法的，解析必然失败，正常用户永远碰不到它。但它并非完全不可用：在 /etc/hosts 这类本地解析机制里写一条记录，再配一张 *.example.com 的通配符证书，这个连接就能建立起来。
curl 检查"证书里的通配符是否覆盖当前主机名"的函数是 Curl_cert_hostcheck()。这个函数存在一个缺陷：在上述场景下，本该返回"不匹配"的检查，错误地返回了 TRUE。一个对 .example.com 没有合法证书的攻击者，如果能让一个使用 curl 的应用以带前导点的主机名连接他控制的主机，curl 会错误地认为证书校验通过，接受这条连接，攻击者由此可以向应用投递恶意数据。
这里的关键词是"如果"。要凑齐这个攻击场景，需要同时满足四个条件：应用使用带前导点的主机名；该名字通过本地解析而非 DNS 解析成功；目标主机持有匹配的通配符证书；攻击者控制这台主机。Stenberg 的判断是，DNS 严格拒绝这类名字，前导点主机名基本只出现在受控的内网环境，而恶意重定向加上本地攻击者的组合把概率压到了几乎为零。
curl 团队把这一类问题称为 "lower than LOW"：一个理论上存在、实践中几乎不可能触发的缺陷。这个级别的问题照修不误（事实上 2025 年 12 月 8 日就已修复，并补上了针对性的单元测试），但不发 CVE 编号。理由是成本：libcurl 全球装机量约 300 亿实例，每一个 CVE 都会在世界各地的安全团队那里触发评估、排期、打补丁的连锁动作。为一个用户实际碰不到的理论问题拉动这批资源，是 curl 项目认为不该转嫁出去的生态成本。
四个月的拉锯：三次转交，一份判决
报告者（博客中称呼为 Yuhao）不接受这个结论，把争议升级到了 MITRE。时间线是这样的：
- 2025 年 12 月前后：报告提交至 curl 项目（HackerOne 平台），curl 评估后定级 lower than LOW，修复但不发编号。
- 2026 年 2 月 10 日：curl 成为 CNA 以来第一次收到 CVE 争议（dispute）通知，MITRE 转交报告者的诉求，要求 curl 给出理由。curl 回复了原始报告和讨论链接，维持原判。
- 2026 年 5 月 28 日：MITRE 第二次转来同一个案例，询问不做编号的理由。curl 给出与上次几乎相同的回复。
- 2026 年 6 月 15 日：MITRE 第三次转来，还是同一个问题。curl 第三次回复同样的内容。
- 2026 年 6 月 24 日：MITRE 终审结果送达，结论：不分配 CVE 编号。
判决书的结论部分值得原样看一下。MITRE TL-Root 写道：经审查各方提交的信息，同意 CNA 的认定，认为该事项已获解决。所引 CNA 认定摘要为："This is a bug, now fixed in the master branch. It is not considered a security vulnerability because of how it requires a local attacker with privileges present to make it so."（这是一个缺陷，现已在 master 分支修复。由于它需要本地攻击者具备相应权限才能构成为害条件，不视为安全漏洞。）作为争议仲裁方，MITRE TL-Root 的决定是该案的最终决定。
Stenberg 对这段流程的评语很简短："This seems like a great system."（这个系统看起来真不错。）一句反讽，说的是同一家仲裁机构把同一个问题转来三次，每次都得到同样的答复。
还有一个细节。Stenberg 提到报告者当时曾把这件事投诉到 Grok（xAI 的聊天机器人）那里。安全争议的最后一步是找聊天机器人评理，这件事本身也成了讨论区调侃的对象。至于报告者为什么如此执着于拿一个编号，Stenberg 表示不愿猜测。
同一天发布的 8.21.0：真正值得关注的尾点问题
判决书里那个"不够格"的 CVE 没拿到编号，但主机名尾点（trailing dot）这个字符家族在 curl 里惹出的麻烦远不止这一个。6 月 25 日，Stenberg 发了篇后续博客，标题就叫 "Trailing dots are the worst"。curl 8.21.0（6 月 24 日发布）里至少修复了三个新的尾点问题：
数字 IPv4 地址带尾点。 把 192.168.0.1. 传给 curl，问题出在 inet_pton()：这个函数用于判断主机名是不是数字 IP 地址，但它对"以点结尾的 IPv4 地址"返回 false，curl 随后把它当作普通主机名处理，错误地允许了通配符证书匹配。修复方式是把尾点当作解析错误，在 URL 解析阶段直接吞掉，与浏览器行为一致。
双尾点主机名。 example.com.. 在 DNS 里同样是非法名，但通过 /etc/hosts 或注入 DNS 缓存的方式仍能让 curl 处理它。curl 内部有些逻辑会剥掉一个尾点，剥完发现还剩一个，HSTS（HTTP 严格传输安全）处理因此出乱子。8.21.0 起直接禁止双尾点。
Cookie 域名校验绕过。 这是最实际的一个，拿到了正式编号 CVE-2026-8924。浏览器规则禁止服务器给"太宽"的域设 Cookie（比如给 co.uk 设 Cookie，就能跨所有英国网站生效），客户端靠 Public Suffix List（PSL，公共后缀清单）判断域名是否属于这类"公共后缀"。curl 用 libpsl 库做这个检查，而 libpsl 被尾点骗过了：example.co.uk. 这个带尾点的主机名尝试给 co.uk. 设 Cookie 时，PSL 检查失效，本该拒绝的 Cookie 被存储并回传。按官方通告，这是 CWE-201（通过已发送数据造成的信息暴露），严重级别 Low，影响 curl 7.46.0 至 8.20.0，在 8.21.0 修复，5 月 13 日由 HackerOne 用户 vegagent 报告。官方给出的临时缓解措施之一，就是不要在主机名里使用尾点。
这场争议对开发者意味着什么
第一，CVE 编号的成本账。 curl 每发一个 CVE，全球约 300 亿装机实例背后的维护者都要评估一遍。这正是 CNA 机制存在的意义：最了解软件的人来决定哪个问题值得全世界拉响警报。这次 MITRE 的判决维持了这条边界，等于确认了"lower than LOW"这类分级的正当性。反过来讲，如果你的工作依赖 CVE 数据做风险评估，"没有 CVE 编号"并不严格等于"没有风险"，修复日期比编号更接近事实。
第二，仲裁机制是真实的。 报告者与 CNA 意见不合时，MITRE 会接手并给出最终裁决，CNA 的专业判断在这个案例里经受住了三轮申诉。对安全研究者来说，这条通道存在，但转三圈拿到同一份答复的成本，报告者自己最清楚。
第三，主机名尾点值得自查。 这次判决涉及的前导点场景几乎无法在真实环境触发，但 CVE-2026-8924 是实打实可利用的 Cookie 边界问题。对多数开发者，动作只有两条：用包管理器把 curl/libcurl 升到 8.21.0 或更新版本；检查自己的系统里有没有用尾点主机名的配置，有就删掉。
一个点，四个月，三次转交，一份维持原判的终审文书。判定一个漏洞"够不够格"的权力，最终留在了最熟悉这套代码的人手里。
参考来源：
- Daniel Stenberg, a CVE dispute, 2026-06-24
- Daniel Stenberg, Trailing dots are the worst, 2026-06-25
- curl 官方通告, CVE-2026-8924
- Lobsters 讨论帖