Istio sidecar 憑證解析失敗會悄悄退回明文傳輸
Istio 官方發布公告 · 2026-09-21
Istio sidecar 在解析 BackendTLSPolicy 所指定的 CA 憑證失敗時，並不會擋下連線，而是直接把原本該走 TLS 的上游流量改成明文傳送。Istio 官方在 2026-09-21 發布的 1.31.1 版釋出說明中，把這個編號 GHSA-qm8v-g4f9-qhjx、CVSS 評分 6.8（中度風險）的漏洞列為這次最重要的修補項目。
漏洞機制
BackendTLSPolicy 是 Gateway API 裡用來要求 Istio 對特定上游服務強制使用加密連線的設定，透過 caCertificateRefs 指向一個存放 CA 憑證的 ConfigMap，讓 proxy 拿這張憑證驗證上游的 TLS 憑證鏈。當這個 ConfigMap 被刪除、改名，或內容不是合法憑證時，Istio 就無法解析出可用的 CA，此時 BackendTLSPolicy 的狀態會出現 ResolvedRefs=False，但這個狀態旗標本身不會擋下任何流量。
問題出在 Istio 處理「CA 解析不到」這種失敗情境的方式：sidecar proxy 選擇 fail open，直接拔掉原本包住連線的 TLS transport socket，把連線退回明文，而不是擋下連線等設定修好。Gateway 端的 proxy 在同樣情境下的行為卻是 fail closed，會直接擋下連線，兩種代理對同一份設定的解讀完全相反。對能夠讓 CA 參照解析失敗（或剛好卡在 ConfigMap 尚未同步完的時間窗）的攻擊者而言，這個不對稱行為等於讓原本該加密的服務間流量變成明文，可以在路徑上竊聽或竄改資料。
官方給的 CVSS 向量是 AV:N/AC:H/PR:L/UI:N/C:H/I:H，意思是攻擊要能從網路上發動、條件不算簡單，但一旦成立，機密性與完整性都會整個失守，這也是分數落在 6.8 的原因。這個問題由研究者 thc1006 回報，官方在漏洞說明裡也提醒，唯一看得到的線索只有 BackendTLSPolicy 狀態上那個容易被忽略的 ResolvedRefs=False。
受影響版本
受影響對象是所有在 sidecar 模式下用 BackendTLSPolicy 強制上游 TLS 的叢集，傳統 sidecar 部署，或 ambient mode 裡仍混用 sidecar 注入工作負載的環境都算在內。官方公告確認的版本範圍是 1.29.0 到 1.29.6、1.30.0 到 1.30.3，分別在 1.29.7、1.30.4 修補；這次的 1.31.1 釋出說明把同一個 GHSA-qm8v-g4f9-qhjx 列為修補項目，代表剛起步的 1.31 分支同樣要升到 1.31.1 才算補齊。判斷自己是否中招最直接的方法，是檢查叢集裡所有 BackendTLSPolicy 物件的狀態，只要有任何一個處於 ResolvedRefs=False，代表對應的上游連線這段時間都在用明文傳輸。
修補與緩解
升級路徑很直接：依所在分支升到 1.29.7、1.30.4 或 1.31.1，patch 後 sidecar 在 CA 解析失敗時會恢復擋下連線的行為。升級前可以先用下面的指令抓出叢集裡所有 ResolvedRefs 不是 True 的 BackendTLSPolicy，確認自己有沒有處在風險窗口內。
kubectl get backendtlspolicy -A -o json | jq -r '
.items[] | select(
(.status.conditions[]? | select(.type=="ResolvedRefs").status) != "True"
) | "\(.metadata.namespace)/\(.metadata.name)"'
來不及馬上升級的話，官方建議兩個緩解方向：一是把 CA 設定改成 WellKnownCACertificates: System，並確保存放憑證的 ConfigMap 不會被誤刪、改壞或因權限問題讀不到，從源頭降低解析失敗的機率；二是不要只靠 BackendTLSPolicy 這一層防護，另外疊上 STRICT mTLS 的 PeerAuthentication，這樣即使 CA 解析失敗，STRICT 模式仍會擋下明文連線，不至於整條路徑都退回沒有加密的狀態。這兩個緩解手段可以先上，不用等維護窗口排到才處理。
這次 1.31.1 同時修掉大約二十項其他問題，包含 CNI iptables 後端偵測造成的重複轉導規則、CRL 清除功能失效、JWKS resolver 誤鎖 HTTP/1.1，以及 istiod CPU 使用量隨 AuthorizationPolicy 數量增加而攀升等，多半屬於維運層面的修正。這些項目值得升級時一併留意，但優先順序都排在這個會讓 mTLS 悄悄失效的資安修補之後。
原始來源：Istio 1.31.1 release notes、GHSA-qm8v-g4f9-qhjx security advisory