A CVE Dispute / 一场关于 CVE 的争议

A few 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 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 a new number. 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. 57 个 CVE 这些年来，我们已经发布了 57 个独立的漏洞及其关联的 CVE 标识符。作为 CNA，为问题获取 CVE 既简单又快捷。没有麻烦，没有摩擦，而且由于我们是一个精简的安全团队，整个流程顺畅得超乎想象。只需一个 API 调用，我们就能获得一个新编号。成为 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. 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. 评估 对于每一份报告，我们都会努力首先进行评估，以确定该问题是否确实是一个漏洞或安全问题。如果我们认为其中存在安全问题，我们会将其评级为“低”、“中”、“高”或“严重”。由于我们不知道用户如何使用 curl 或 libcurl，我们无法将其考虑在内，而是从纯粹的 curl 角度观察并设定问题的严重性。这只是我们看待问题的一个粗略指标，当然，每个实际受该问题影响的用户可能会有不同的评价。

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 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. 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 的代价 全球大约有 300 亿个 libcurl 实例。如果我们设想其中相当大一部分安装是由那些希望确保使用安全版本的用户管理的，这意味着我们发布的每一个 CVE 都会触发全球许多安全团队的行动，导致大量的补丁和随后的软件更新。因此，每一个 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. Yes, it makes you wonder why it is that important to have this as a CVE, but I will avoid speculations for now. 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. 争议 自我们成为 CNA 以来，我们遇到的第一次 CVE 争议发生在 2026 年 2 月 10 日，针对的是两个月前提交给我们的一份报告。报告者认为我们应该为他们报告的问题分配一个 CVE，但我们认为不应该。现在，他们试图通过将情况升级到 MITRE 来强行要求获得 CVE 编号。是的，这确实让人怀疑为什么非要将其定为 CVE 如此重要，但我暂时不做推测。我回复了 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. First: the user must use a hostname in a URL with a leading dot, like 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. 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. 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. 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. 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 severity below HIGH, we fix them asap so that was just our normal procedure. We then continued to discuss if this was worthy of a CVE or not. 带有前导点的域名 这个问题相当技术性（当然），其根源在于 curl 的一个函数中存在 Bug，该函数用于检查所使用的域名是否与证书中提供的通配符匹配。首先：用户必须在 URL 中使用带有前导点的域名，例如 https://.example.com/。这种名称在 DNS 中无法使用（它是非法名称），但你可以在 /etc/hosts 文件或类似文件中为其提供 IP 地址，但这使得该问题变得非常小众。为什么用户会这样做呢？好吧，如果应用程序允许重定向，恶意服务器可能会重定向到这样的域名，但获取该主机的地址仍然是一个挑战，且通常需要本地攻击者的存在。其次：如果 curl 能为这个非法的 DNS 域名找到地址，那么 curl 连接的站点还需要拥有一个针对 *.example.com 的通配符证书，且通配符的尾部需要与 URL 中的名称匹配。如果 curl 在构建时使用了 OpenSSL 或 Schannel 作为 TLS 后端（请记住 curl 支持多种不同的 TLS 后端），它会调用 Curl_cert_hostcheck() 函数来检查通配符是否覆盖了所使用的域名。这个函数存在一个 Bug。上述组合会错误地返回 TRUE，即匹配。而实际上根据规范，这并不匹配。我们在 2025 年 12 月 8 日修复了这个问题，并针对这种情况添加了单元测试，以确保问题不会复发。对于所有严重程度低于“高”的安全问题，我们都会尽快修复，这只是我们的正常流程。随后，我们继续讨论这是否值得发布一个 CVE。

Lower than LOW It should be extremely rare that anyone uses a dot prefixed name, unless you are in an internal and controlled environment where you use something else than DNS for resolving. It is not possible to trick an application to use a dot prefixed arbitrary name as it will fail to resolve. The explicitly set, weirdly dot prefixed name, then needs to connect to a host that has a wildcard set for that same name and an attacker manage to run this impostor host and can now serve the application malicious data because curl did not properly reject the connection because of the wildcard mismatch. A series of highly unlikely conditions that all need to be fulfilled for this to become a vulnerability. A lower than LOW situation. Too unlikely; no CVE. 低于“低”级 除非是在使用非 DNS 解析的内部受控环境中，否则几乎没有人会使用带有前导点的域名。你不可能诱骗应用程序使用带有前导点的任意名称，因为它无法解析。这种显式设置的、奇怪的带前导点的名称，需要连接到一个为该名称设置了通配符的主机，并且攻击者需要成功运行这个伪造主机，从而向应用程序提供恶意数据，因为 curl 没有因通配符不匹配而正确拒绝连接。要使这成为一个漏洞，需要满足一系列极不可能同时发生的条件。这属于低于“低”级的情况。可能性太小；不予发布 CVE。

Again in May On May 28, we were again contacted by MITRE in the same case, asking again for our rationale for not giving this issue a CVE. We responded with virtually the same wording. 五月再次联系 5 月 28 日，MITRE 就同一案件再次联系我们，询问我们不为该问题发布 CVE 的理由。我们回复了几乎相同的内容。