【文章标题】：A CVE Dispute
【文章标题】：一场关于CVE的争议
【文章正文】：
A few years years ago the curl project signed up and became a CNA. This means that we are masters of and can allocate our own CVE identifiers. For any security problems within our territory, it is we who decides if the issue should get a CVE or not. No more bogus CVEs.
几年前，curl项目注册成为CNA（CVE编号机构）。这意味着我们掌握了自主分配CVE标识符的权力。对于管辖范围内的任何安全问题，由我们决定是否为其分配CVE编号。从此不再有虚假CVE。
57 CVEs
57个CVE
During these years we have published fifty-seven separate security vulnerabilities with their associated CVE identifiers. Getting a CVE for an issue is easy and really quickly done when you are a CNA. No hassle, no friction and as we are a small and lean security team it just works as smoothly as you could ask. Just an API call and we have new number.
这些年我们发布了57个独立安全漏洞及其对应的CVE编号。作为CNA，为问题获取CVE编号既简单又快捷。没有繁琐流程，没有阻力——我们作为精干的小型安全团队，整个流程顺畅得超乎想象。只需一个API调用，新编号即刻生成。
Being a CNA is low maintenance, as there really is nothing extra we need to do. We already had an established and proven process for receiving, managing and assessing vulnerability reports before we became a CNA since we are a responsible and well-run Open Source project. Becoming a CNA just made the process easier as we now don’t need to involve any outsider at all.
担任CNA的维护成本极低，因为我们实际上无需额外工作。在成为CNA之前，作为负责任且运作良好的开源项目，我们已建立了成熟的漏洞报告接收、管理和评估流程。成为CNA只是让流程更简单——现在我们完全不需要任何外部介入。
Assess
评估标准
For every report we work hard to first assess and decide if the issue is actually a vulnerability or a security problem at all.
对于每份报告，我们首先会严格评估并判定它是否确实属于漏洞或安全问题。
If we deem that there is a security problem in there, we then grade it into LOW, MEDIUM, HIGH or CRITICAL. Since we don’t know how users use curl or libcurl we cannot take that into account but rather observe and set a severity of the problem from a pure curl point of view.
若确认存在安全问题，我们会将其分级为低危、中危、高危或严重。由于无法预知用户如何使用curl/libcurl，我们不会考虑使用场景，而是纯粹从curl角度评估问题严重性。
It’s a rough indication how we see the problem but of course every user that actually are affected by the problem might rate it differently.
这虽是我们对问题的基本判断，但实际受影响的用户可能会有不同评级。
Lower than LOW
低于”低危”的案例
For a rare few issues we can imagine that there could be a minuscule risk but because of the set of extreme requirements and convoluted steps to get there, we deem the risk so small that in practice no user is likely to ever reach it. Internally we tend to call that an issue with a severity level lower than LOW. Issues we believe we serve humanity better by not issuing a CVE for. To avoid the security dance when it seems unnecessary.
极少数情况下，某些问题可能存在理论风险，但由于触发条件苛刻且步骤复杂，我们认为实际风险微乎其微。内部我们称之为”低于低危”的问题——这类问题不分配CVE编号反而更符合公共利益，避免无谓的安全警报。
The cost of a CVE
CVE的代价
libcurl is installed in somewhere around thirty billion instances on the globe. If we imagine that at least a sizeable portion of those installs are managed by people who want to make sure they use a secure version, it means that every CVE we publish trigger activities in many security teams all over the world, leading to a significant number of patches and subsequent software updates.
全球约有300亿实例安装了libcurl。假设其中相当部分由注重安全的团队管理，那么我们发布的每个CVE都会触发全球安全团队的响应，导致大量补丁和软件更新。
Every CVE thus has this huge cost tied to it. A cost that does not land on us and we don’t really see or feel it, but a cost on the ecosystem I believe we should not ignore. We should act responsibly. Never ignore real problems of course, but also to make sure we don’t ring the alarm for theoretical problems that will not trigger any vulnerability.
因此每个CVE都伴随着巨大代价。这个代价虽不由我们直接承担，但作为生态系统的成本不容忽视。我们必须负责任地行事：既不忽视真实问题，也要避免为理论风险拉响警报。
The dispute
争议始末
Our first ever CVE dispute since we became a CNA reached us on February 10th, 2026 for a report submitted to us two months earlier. The reporter thinks we should have assigned their reported problem a CVE but we think not. Now they want to force the issue to get a CVE anyway, by escalating the situation to MITRE.
2026年2月10日，我们收到成为CNA后的首起CVE争议，涉及两个月前提交的报告。提交者认为其报告的问题应获得CVE编号，但我们持相反意见。对方现正试图通过向MITRE申诉强制分配CVE。
Yes, it makes you wonder why it is that important to have this as a CVE, but I will avoid speculations for now.
这不禁让人疑惑为何非要获得CVE编号，不过目前我不作揣测。
I replied to MITRE explaining that we considered and debated the issue and we remain happy with our previous decision. I linked them the original report and discussion to show them.
我已向MITRE回复说明：我们经过充分讨论仍坚持原决定，并附上原始报告及讨论记录供其查阅。
Hostname with a leading dot
带前导点的域名
The issue is quite technical (of course) but is based on a bug in curl’s function that checks if the used hostname matches a wildcard provided in a certificate.
这个问题技术性很强（当然），根源在于curl检查”所用主机名是否匹配证书通配符”的函数存在缺陷。
First: the user must use a hostname in a URL with a leading dot, like https://.example.com/
首先：用户必须在URL中使用带前导点的域名（如https://.example.com/）
This name is not possible to use with DNS (it is an illegal name there), but you can provide an IP address for it in your /etc/hosts file or similar, but still this condition is already making this issue really niche.
这种域名无法通过DNS解析（属非法命名），但可通过/etc/hosts文件等方式指定IP地址——仅此条件已使该问题极为边缘化。
Why would a user ever do this? Well, there could be a redirect to such a host name from a malicious server if the application allows redirects but getting the address for the host is still a challenge and mostly requires a local attacker present add that.
用户为何要这么做？当应用允许重定向时，恶意服务器可能诱导跳转至此类域名，但获取该主机地址仍具挑战性，通常需要本地攻击者配合。
Then: if curl can find an address for the illegal DNS hostname, the site curl connects to, also needs to have a wildcard certificate for the name .example.com where the tail of the wildcard needs to match the name in the URL.
其次：若curl能为该非法DNS主机名找到地址，目标站点还需持有.example.com的通配符证书，且通配符后缀必须与URL中的名称匹配。
If curl was built to use an OpenSSL flavor or Schannel for TLS (remember that curl supports many different TLS backends), it then calls the Curl_cert_hostcheck() function to check if the wildcard covers the used hostname.
如果curl编译时采用OpenSSL系或Schannel作为TLS后端（注意curl支持多种TLS后端），就会调用Curl_cert_hostcheck()函数来验证通配符是否覆盖所用主机名。
This function had a bug. The above mention combination then erroneously would return TRUE. A match. When in reality it is not a match according to the spec.
该函数存在缺陷。上述组合场景会错误返回TRUE（匹配），而根据规范实际并不匹配。
We fixed this problem on December 8, 2025, and we added unit tests for exactly this scenario to make sure that the problem doesn’t come back. For all security issues at several below HIGH, we fix them asap so that was just
我们已于2025年12月8日修复该问题，并为此场景添加单元测试以防复发。对于所有非高危的安全问题，我们都采取快速修复策略，因此…