几年前，curl项目注册并成为CNA。这意味着我们是自己的CVE标识符的掌控者和分配者。对于在我们领域内的任何安全问题，我们决定是否应该为此问题分配CVE。不再有虚假的CVE。在这些年里，我们发布了五十七个独立的安全漏洞及其关联的CVE标识符。作为CNA，获得CVE非常简单，也非常迅速。没有麻烦，没有摩擦，而且由于我们是一个小型精干的安全团队，这一过程顺畅得令人满意。只需一次API调用，我们就有了新的编号。作为CNA的维护成本很低，因为实际上我们不需要做额外的事情。我们在成为CNA之前就已经建立了一个健全且经过验证的流程，用于接收、管理和评估漏洞报告，因为我们是一个负责任且运行良好的开源项目。成为CNA只是让这个过程变得更简单，因为现在我们完全不需要牵涉任何外部人员。评估对于每个报告，我们努力首先评估并决定该问题究竟是否为漏洞或安全问题。如果我们认为其中存在安全问题，我们会将其分级为低、中、高或关键。由于我们不知道用户如何使用curl或libcurl，因此无法考虑这一点，而是从纯curl的角度观察并设定问题的严重性。这是我们对问题的粗略判断，但当然每个实际上受到问题影响的用户可能会有不同的评分。低于低对于少数几种问题，我们可以想象可能存在微小的风险，但由于到达这种状态所需的极端要求和复杂步骤，我们认为风险非常小，实际上没有用户可能会接触到它。在内部，我们倾向于称其为严重性级别低于低的问题。我们相信，我们通过不发布CVE来更好地为人类服务。以避免在似乎不必要时进行的安全舞蹈。CVE的成本libcurl在全球约有三百亿个实例。如果我们想象，至少相当大一部分这些安装都是由希望确保使用安全版本的人管理的，这意味着我们发布的每个CVE都会触发全球许多安全团队的活动，导致大量的补丁和随后的软件更新。因此，每个CVE都有巨大的成本与之相关。这一成本并不会落到我们头上，我们也不会真的看到或感受到它，但我相信这对生态系统来说是一个我们不应忽视的成本。我们应该负责任地行动。当然，绝不要忽视真正的问题，但也要确保我们不会因理论上的问题而发出警报，这些问题不会引发任何漏洞。争议自从我们成为CNA以来的第一次CVE争议于2026年2月10日到达我们这里，这是一个两个月前提交的报告。报告者认为我们应该给他们报告的问题分配CVE，但我们认为不应该。现在他们希望无论如何强制要求此问题获得CVE，向MITRE升级这一情况。是的，这让你想知道为什么将其作为CVE如此重要，但我暂时会避免推测。我回复MITRE，解释我们考虑并讨论了这个问题，仍然对之前的决定感到满意。我向他们链接了原始报告和讨论以供参考。以点开头的主机名这个问题相当技术性（当然），但基于curl的一个功能上的缺陷，该功能检查使用的主机名是否与证书中提供的通配符相匹配。首先：用户必须在URL中使用以点开头的主机名，如https://.example.com/。这个名称在DNS中是无法使用的（在那是一个非法名称），但你可以在/etc/hosts文件或类似的地方为其提供一个IP地址，但这个条件已经使这个问题变得非常小众。用户为什么会这样做？好吧，如果应用程序允许重定向，恶意服务器可能会重定向到这样的主机名，但获取该主机的地址仍然是一个挑战，并且通常需要本地攻击者在场。然后：如果curl可以找到非法DNS主机名的地址，该curl连接的站点还需要拥有名为*.example.com的通配符证书，其中通配符的尾部需要与URL中的名称匹配。如果curl是为TLS构建的使用OpenSSL或Schannel（请记住，curl支持许多不同的TLS后端），它会调用Curl_cert_hostcheck()函数来检查通配符是否覆盖所用的主机名。这个函数存在一个bug。上述组合错误地返回TRUE。一个匹配。当实际上根据规范它并不匹配。我们在2025年12月8日修复了这个问题，并为这个特定场景添加了单元测试，以确保此问题不会再出现。对于所有严重性低于高的安全问题，我们会尽快修复，这就是我们的正常程序。