一樁 CVE 爭議 （★ 110 分）
curl 專案成為 CNA（CVE Numbering Authority，CVE 編號核發機構）後，可自行判定並核發 CVE（Common Vulnerabilities and Exposures，通用弱點揭露編號）。團隊已公布 57 項安全弱點，但強調 CVE 不只是編號：libcurl 約部署於全球 300 億個實例，每新增一筆 CVE，都可能促使大量企業資安團隊評估影響、套用修補與更新軟體。因此，除了不能漏掉真正的風險，也不該為實務上幾乎無法利用的瑕疵拉響警報。
爭議源自 curl 對 TLS（Transport Layer Security，傳輸層安全性）憑證萬用字元主機名稱比對的一項瑕疵。若網址主機名稱以句點開頭，例如 `https://.example.com/`，在極罕見的條件組合下，curl 使用 OpenSSL 或 Schannel 等 TLS 後端時，可能錯把不符合規範的萬用字元憑證視為相符。這種名稱無法經由 DNS（Domain Name System，網域名稱系統）正常解析，通常還得由本機攻擊者預先在 `/etc/hosts` 等位置加入對應位址，攻擊者另須掌控具備特定萬用字元憑證的假冒主機，整體利用門檻極高。curl 已在 2025 年 12 月修正並加入測試，但判為風險低於 LOW，不核發 CVE。
通報者不服此判定，向 MITRE（負責管理 CVE 計畫的美國非營利機構）提出爭議。MITRE 在 2 月、5 月與 6 月多次要求 curl 重述理由後，最終認同 CNA 的判斷：這是已修正的程式瑕疵，但必須有具權限的本機攻擊者介入才可能形成風險，不構成安全弱點，因此不會核發 CVE。作者藉此批評爭議流程重複要求相同說明，徒增行政負擔。
Hacker News 多數留言認同 curl 的取捨，指出即使資安團隊願意逐項審查，每筆 CVE 仍會耗費時間確認是否適用；若企業採取「見 CVE 就修補」的僵化做法，影響尤其龐大。有留言認為，阻止一筆幾乎無關的 CVE 流入整個供應鏈，能省下大量累積的人力成本。也有人建議將這類修正併入後續較高風險版本釋出；不過其他人澄清，curl 早已修正問題，爭點從來不是是否修正，而是是否應賦予 CVE 編號。
討論也將事件連結到 CVE 的職涯與聲望誘因：在知名專案找到 CVE，可能有助於求職、加薪或建立名聲，因此有人懷疑通報者執著於取得編號。另有維護者表示，大型語言模型（LLM，Large Language Model）讓人能大量產出安全通報，低價值報告與反覆申訴可能增加。相對地，也有人認為 CVE 制度本就同時承擔防禦情報與跨組織協調功能，若判定與爭議程序過於不透明，容易讓通報者與維護者都對制度失去信任。
👥 21 則討論、評論 💬
https://news.ycombinator.com/item?id=49508290