今年1月底：curl終止實施多年的漏洞獎勵計畫，不再為通報漏洞的研究人員提供獎金。
今年3月：curl恢復透過HackerOne平台接受漏洞通報，但維持不發放獎金的作法，通報仍須先私下提交。
10月26日：新制度正式上路。經團隊判定為低或中度風險的漏洞，改在GitHub Issues公開通報與討論；高風險及重大漏洞則繼續透過HackerOne私下處理。
curl是全球使用最廣泛的開源網路傳輸工具之一，除了提供命令列工具，它的函式庫libcurl更被無數軟體用來傳輸網路資料，從手機App到伺服器系統，幾乎無所不在。也正因為影響範圍如此之大，curl的漏洞處理方式一有變動，整個開源社群都會高度關注。
這次調整的核心原因，是維護團隊已經被漏洞通報淹沒。主要維護者Daniel Stenberg指出，持續湧入的漏洞報告讓維護團隊難以負荷，希望藉由公開處理的方式，把部分工作分攤給社群。過去幾年收到的通報中，超過九成可以迅速判定未達高風險等級，但即便如此，逐件檢查、確認、分類仍然耗費大量人力。
值得注意的是，這波通報潮與人工智慧的普及有直接關係。近來不少漏洞是研究人員利用AI模型，系統性地測試libcurl的各種選項、網路協定及操作順序後找出來的。AI讓漏洞挖掘的效率大幅提升，但也帶來一個副作用：大量被找出來的問題，實際嚴重程度並不高。有些異常只在實務上極少使用的操作組合下才會出現，另一些則是每次採用相關操作組合都會出現異常、開發者容易察覺的類型。Stenberg認為，這類問題實際影響到使用者的機會很低。
在原本的制度下，所有安全漏洞都必須先私下通報，由維護團隊確認、完成修補之後再公開。新政策上路後，流程將依風險等級分流：低或中度風險的漏洞直接在GitHub Issues上公開通報與討論，外部開發者可以參與問題確認、協助檢查修補程式是否完整，甚至參與安全公告的撰寫；高風險及重大漏洞則維持原本的私下處理流程，繼續透過HackerOne通報，避免在修補完成前讓攻擊者掌握細節。
對於不確定漏洞嚴重程度的研究人員，仍然可以先提交到HackerOne。如果curl團隊判定屬於低或中度風險，會要求研究人員改在GitHub重新提出，原本的HackerOne通報則會被註記為資訊性案件後結案，並將內容公開。這樣的設計保留了彈性，讓研究人員不必自己承擔風險分級的判斷責任。
公開處理中低風險漏洞，預期能帶來幾個好處。第一，更多人可以協助檢查修補程式是否完整，並找出相似的漏洞。實務上，curl每次公布CVE及修補程式後，經常有研究人員利用AI追查相似的缺陷或修補遺漏之處，如果在新版本發布前就展開公開審查，有機會更早發現問題。第二，Linux發行版及其他使用curl的專案，可以提早掌握修補進度，不必等到正式公告才開始準備。
當然，公開處理也有風險。提前公開尚未修補的漏洞，可能讓攻擊者有更長的時間研究並加以利用。這正是curl把公開處理嚴格限制在中低風險案件的原因：高風險與重大漏洞的細節，依然只在修補完成後才會公開，兼顧透明度與安全性。
回顧curl今年的政策變化，可以看出維護團隊在資源有限下的掙扎與調適。1月底終止漏洞獎勵計畫，3月恢復接受通報但不恢復獎金，如今再依嚴重程度決定公開或私下處理，每一步都是在「鼓勵通報」與「控制成本」之間找平衡。隨著AI輔助的漏洞挖掘越來越普遍，通報量只會繼續增加，curl這次的制度實驗，很可能成為其他開源專案的參考範本。
對一般使用者而言，這項改變的直接影響不大，因為高風險漏洞的處理流程維持不變。但對開源社群來說，這代表curl正式承認：單靠核心維護團隊，已經無法應付AI時代的漏洞通報量。把中低風險的審查工作交給社群，是不得已但務實的選擇。後續值得觀察的是，公開討論的品質能否達到預期，以及是否真能減輕維護團隊的負擔。
