curl 專案於 2026 年 9 月 2 日隨 curl 8.22.0 發布 CVE-2026-80230。此低嚴重性問題影響使用 OpenSSL 或相容分支的 libcurl 建置，觸發前提是同時設定公開金鑰釘選，並關閉標準對端驗證與主機名稱驗證。
在另一個異常條件下——連線建立時伺服器未提供憑證——libcurl 可能略過釘選檢查，讓未經驗證的連線成功。curl 8.22.0 已包含修正。
觸發範圍雖窄，但營運結論很重要：公開金鑰釘選是額外身分檢查，不能取代標準憑證驗證。
受影響條件
官方公告列出以下條件：
- libcurl 使用 OpenSSL 或 BoringSSL、AWS-LC、LibreSSL、QuicTLS 等分支；
- 設定
CURLOPT_PINNEDPUBLICKEY； CURLOPT_SSL_VERIFYPEER設為零；CURLOPT_SSL_VERIFYHOST設為零；- 連線在伺服器未提供憑證的情況下繼續；
- curl 版本為 7.45.0 至 8.21.0。
形成相同有效條件時，curl 命令列工具也受影響。curl 8.22.0 及以上版本不受此問題影響。
公告不代表什麼
它不代表 curl 的所有公開金鑰釘選連線都失效，也不描述啟用正常 CA、對端與主機名稱驗證的常規連線。更不能因等待升級而關閉驗證。
不要實施範圍過大的緊急變更。先確認受影響工作負載的 TLS 後端、curl 版本和最終有效驗證開關。
代理營運要分別檢查兩段 TLS
HTTPS 代理可能形成兩個獨立憑證驗證情境：
- 客戶端到代理的 TLS 連線；
- 經代理到目的地的 TLS 連線。
應分別盤點兩段鏈路的釘選與驗證政策。代理 TLS 和目的地 TLS 的選項名稱及行為可能不同。目的地政策正確不能證明代理鏈路同樣嚴格，反之亦然。
一般 HTTP 代理承載 CONNECT 通道時，代理鏈路本身不是 TLS，但通道內目的地連線仍需正常憑證與主機名稱驗證。
立即回應步驟
- 記錄實際部署的 curl 與 libcurl 版本。
- 記錄每個建置使用的 TLS 後端，不能只看套件名稱。
- 搜尋公開金鑰釘選及關閉對端或主機名稱驗證的設定。
- 把代理鏈路選項與目的地鏈路選項分開檢查。
- 將受影響系統升級至 curl 8.22.0 或包含修正的供應商建置。
- 恢復所有不應關閉的標準對端與主機名稱驗證。
- 在擴大推出前執行釘選正向與負向測試。
- 新版本啟動後排空舊程序和連線集區。
若暫時不能升級，不要把釘選本身視為緩解措施。應恢復標準驗證，並依供應商支援的方式套用修補程式。
建立有效的釘選迴歸測試
只能使用自行控制的端點與憑證，不要對第三方系統執行憑證操弄測試。
測試夾具至少包括：
- 有效憑證鏈、相符主機名稱和相符公開金鑰釘選；
- 有效憑證鏈和主機名稱，但使用故意錯誤的釘選；
- 來自不受信任測試 CA 的憑證；
- 主機名稱不相符；
- 已過期測試憑證；
- 在重疊窗口內同時接受新舊釘選的核准輪換。
結果應完全確定。只有核准組合成功；錯誤釘選、不受信任鏈、主機名稱不相符和過期憑證必須故障關閉。
測試最終有效設定，而非只看原始碼
安全開關可能來自環境變數、封裝器、範本、命令列組合或回退程式碼。應在執行階段記錄最終有效政策，但不能記錄秘密。
每次測試建議記錄：
- curl 版本與 TLS 後端；
- 代理端點和目的地端點標籤；
- 對端驗證與主機名稱驗證布林值；
- 釘選集合 ID 與輪換版本；
- 新建或重用連線狀態；
- 憑證驗證結果分類；
- 重試次數與最終路線。
禁止記錄密碼、權杖、完整代理 URL、私密金鑰或原始釘選資料。不含秘密的釘選集合 ID 足以關聯事件。
禁止不安全回退
憑證失敗不能觸發更弱的路線或 TLS 政策。
- 失敗後不能修改驗證開關；
- 不能自動移除釘選後重試；
- 未經明確核准不能回退直接連線；
- 確定性的 TLS 政策錯誤不能觸發無限住宅代理輪換；
- 憑證失敗應與代理容量或逾時指標分開統計。
使用代理繞過稽核尋找意外直接連線，並參考TLS 信任設定隔離依有效政策隔離連線集區。
正確規劃憑證輪換
若沒有重疊計畫，公開金鑰釘選可能在憑證變更時造成中斷。輪換窗口內至少保留一個目前釘選和一個已核准的新釘選。先部署新釘選集合，再更換憑證；在受控環境驗證兩個金鑰，並在回復風險消失後移除舊釘選。
釘選應像憑證一樣有負責人、審查與監控。可搭配代理憑證輪換，讓秘密與信任資料彼此獨立變更。
升級驗收清單
- 已盤點所有 curl 版本和 TLS 後端。
- 受影響建置已升級或套用供應商修補程式。
- 對端驗證與主機名稱驗證保持開啟。
- 代理鏈路和目的地鏈路已分別審查。
- 正確釘選測試成功。
- 錯誤釘選、錯誤 CA、主機名稱不相符和過期憑證測試失敗。
- 連線重用不會攜帶過期信任設定。
- 重試有上限且保留原 TLS 政策。
- 不存在未核准的直接連線回退。
- 日誌不揭露憑證、私密金鑰或完整代理 URL。
- 推出後舊程序和連線集區已排空。
- 釘選輪換具有重疊和回復方案。
常見問題
公開金鑰釘選可以取代 CA 與主機名稱驗證嗎？
不可以。釘選應作為附加控制，標準對端驗證與主機名稱驗證必須保持啟用。
所有 TLS 後端都受影響嗎？
公告把問題限定於 OpenSSL 及相容分支。應檢查實際部署二進位檔使用的後端，不能依作業系統猜測。
所有代理請求都受影響嗎？
不是。它要求關閉標準驗證、設定釘選、使用受影響後端和版本，以及連線沒有伺服器憑證等條件同時成立。
首選修正是什麼？
升級 curl 與 libcurl 至 8.22.0，或使用包含修正的官方供應商套件，然後驗證最終有效 TLS 設定。
來源說明與合規
來源：curl 專案，《OpenSSL pinning bypass》，CVE-2026-80230，發布於 2026 年 9 月 2 日。外部來源地址只保留在內部營運記錄中。
代理只能用於獲授權的系統與資料。請遵守合約、隱私義務、存取控制、速率限制及適用法律。憑證測試必須使用受控基礎設施，不得用於攔截或繞過第三方保護。
