資訊安全新聞

Kubernetes 的隱藏危機？深入了解 Ingress-Nginx 的致命漏洞並採取行動

前言

Kubernetes 的 Ingress-Nginx Controller 是一個廣泛採用的開源解決方案，作為反向代理(Reverse proxy) 和負載平衡器(Load balancer)，讓 Kubernetes cluster內的服務可以透過 HTTP 和 HTTPS 路由從外部存取 1 。這個關鍵元件負責管理網路流量，在 Kubernetes 上部署的應用程式存取性中扮演重要角色。最近，Ingress-Nginx Controller 中發現了一系列重大安全漏洞，對 Kubernetes 環境構成嚴重威脅。這份報告根據最新研究結果，對這些被統稱為 "IngressNightmare" 的漏洞進行全面分析，詳細說明其技術細節、潛在影響以及建議的緩解策略(Mitigation strategies) 2 。

Kubernetes 的隱藏危機？深入了解 Ingress-Nginx 的致命漏洞並採取行動 | 資訊安全新聞

漏洞分析

Wiz 的研究發現 Kubernetes 的 Ingress-Nginx Controller 中存在四個主要的未經身份驗證的遠端程式碼執行 (RCE) 漏洞 2 。這些漏洞加上一個額外的檔案路徑串起問題，可能被利用來取得未經授權的存取權，甚至完全控制 Kubernetes cluster。

CVE-2025-1097: auth-tls-match-cn 中的Annotation注入漏洞

這個漏洞位於 Ingress-Nginx 准入控制器 (Admission controller) 中的 auth-tls-match-cn annotation 解析器 1 。auth-tls-match-cn annotation 用於客戶端憑證驗證，其值由 authtls 解析器透過 CommonNameAnnotationValidator 函式處理 2 。這個驗證器要求 annotation 值必須以 "CN=" 開頭，且後面的字元需構成一個有效的正規表達式 2 。

儘管有這些驗證要求，研究發現一個繞過方法，允許注入任意的 NGINX 設定 2 。透過精心設計一個惡意的 auth-tls-match-cn annotation 值，例如 "CN=abc #(\n){}\n }}\nglobal_injection;\n#" 2 ，攻擊者可以在臨時設定檔中插入非預期的 NGINX 指令。這個注入值會被放在一個 if 語句中，對 $ssl_client_s_dn 變數（儲存客戶端憑證的主體識別名稱）進行正規表達式匹配 2 。產生的 NGINX 設定片段展示了成功注入的 global_injection; 指令：

            ...
            set $proxy_upstream_name "-" ;
            if ( $ssl_client_s_dn ! ~ CN=abc #(
            ){} }}
            global_injection;
            # ) {
            return 403 "client certificate unauthorized" ; }
            ...

要利用這個漏洞，還需提供 nginx.ingress.kubernetes.io/auth-tls-secret annotation 2 。這個 annotation 指定cluster中的 TLS 憑證或 Keypair secret。關鍵在於，Ingress-Nginx 的服務帳戶擁有 Kubernetes cluster中所有命名空間的 Secret 存取權 1 。這讓攻擊者可以指定任何有效的 Secret name，可能利用受管理的 Kubernetes 解決方案中常見的 Secret 2 。auth-tls-match-cn annotation 的輸入驗證漏洞允許攻擊者注入任意 NGINX 設定，進一步結合 CVE-2025-1974 實現遠端程式碼執行，進而存取cluster中的敏感 Secret 2 。這種簡單的前綴與正規表達式檢查的輸入驗證機制不足以阻止複雜的注入攻擊，而 Ingress-Nginx 控制器服務帳戶的廣泛存取權限更違反了最小權限原則，加劇了風險 1 。

CVE-2025-1098: Mirror UID 注入漏洞

這個漏洞位於 Ingress-Nginx Controller 的 mirror annotation 解析器中 1 。解析器直接將 ingress 物件的 UID (唯一識別碼) 併入臨時 NGINX 設定檔中的 *$location.Mirror.Source* 變數 2 。這個漏洞的關鍵在於攻擊者可以控制 ing.UID 欄位 2 。與 Kubernetes 的 annotation 不同，這個欄位未受應用於 annotation 值的正規表達式清理規則限制 2 。因此，未經清理的攻擊者控制輸入直接插入 NGINX 設定中，允許輕鬆跳脫預期環境，注入任意 NGINX 設定指令 2 。這種注入設定可與 CVE-2025-1974 結合，實現遠端程式碼執行並存取 Kubernetes 環境中的 Secret 1 。這個漏洞突顯了輸入驗證實務的不一致性，物件欄位未受到與 annotation 同等嚴格的審查。假設只有 annotation 需要嚴格驗證，而忽略對所有使用者控制輸入一致應用安全措施，是一個重大疏忽 2 。

CVE-2025-24514: auth-url 中的Annotation注入漏洞

CVE-2025-24514 是 Ingress-Nginx Controller 的 auth-url annotation 解析器中的一個 RCE 漏洞 1 。authreq 解析器處理與身份驗證相關的 annotation，特別是 auth-url annotation ，需要設定外部身份驗證服務的 URL 2 。在產生臨時 NGINX 設定檔時， auth-url annotation 的值（對應 $externalAuth.URL ）未經適當清理就直接併入設定中 2 。相關的 NGINX 設定模板如下：

Nginx

               proxy_http_version  1.1;
               proxy_set_header Connection "" ;
               set $target {{ changeHostPort $externalAuth.URL $authUpstreamName }};
               {{ else }}
               proxy_http_version {{ $location.Proxy. ProxyHTTPVersion }};
               set $target {{ $externalAuth. URL }};
               {{ end }}
               proxy_pass $target;
               ...

這種缺乏清理的做法讓攻擊者能透過精心設計的 auth-url annotation 注入任意 NGINX 設定指令。例如，攻擊者可以使用 annotation："http://example.com/#;\ninjection_point" 2 。當這個 annotation 被處理時，產生的 NGINX 設定將包含注入的指令：

Nginx

                ...
                proxy_http_version  1.1;
                set $target http://example.com/#;
                injection_point
                proxy_pass $target;
                ...

注入的 injection_point 指令會在執行 nginx - t 命令驗證設定時被驗證(Validate)，可能導致 Ingress-Nginx Controller 的 pod 上執行程式碼 2 。值得注意的是，這個漏洞已在 Ingress-Nginx Controller 1.12.0 版中更新，該版本引入了更嚴格的正規表達式規則來驗證所有 annotation，包括 auth-url 2 。這個漏洞強調了將未清理的(Unsanitized) 使用者輸入直接併入設定檔的風險，特別是當這些設定透過執行來驗證時。1.12.0 版的更新顯示了持續安全增強和加強輸入驗證機制的必要性 2 。

CVE-2025-1974: NGINX 設定程式碼執行

CVE-2025-1974 是一個漏洞，透過其他漏洞的注入能力，在 NGINX 設定測試階段實現任意程式碼執行 1 。雖然之前討論的漏洞允許注入任意指令到 NGINX 設定中，CVE-2025-1974 是透過特定 NGINX 指令實現程式碼執行的具體缺陷 2 。

研究團隊發現，Ingress-Nginx Controller 編譯的 NGINX 實例中包含的 OpenSSL 模組中的 ssl_engine 指令，可被濫用來載入共享函式庫(Shared libraries) 2 。這種行為未被正式記載 2 。與 load_module 指令不同， ssl_engine 可在設定檔的任何位置使用，使其成為注入的理想目標 2 。利用此漏洞分兩步進行。首先，攻擊者需將共享函式庫放入 pod 的檔案系統中 2 。這可透過 NGINX 的客戶端主體緩衝功能實現 2 。當一個帶有超過預設 8KB 門檻主體的 HTTP 請求被發送到同一 pod 運行的 NGINX 實例（埠 80 或 443）時，NGINX 會將主體儲存到臨時檔案 2 。雖然該檔案會立即被刪除，但透過 ProcFS 仍可存取其開放檔案描述符(Open file descriptor) 2 。透過將 Content-Length 標頭設為大於實際內容大小的值，連線會掛起，使檔案描述符保持開放一段時間 2 。

第二步涉及向 Ingress-Nginx Controller 的准入控制器發送精心設計的 AdmissionReview 請求，注入 ssl_engine 指令 2 。此指令被指示透過指定檔案上傳階段創建的 ProcFS 路徑載入共享函式庫 Payload 2 。若正確猜測 PID 和檔案描述符編號（在僅有少數程序的容器中是可行的），共享函式庫會被載入，從而在 Ingress-Nginx Controller 的 pod 中實現遠端程式碼執行 2 。這個漏洞尤為關鍵，因其展示了設定注入缺陷如何被串聯以實現任意程式碼執行。 ssl_engine 指令的未記載行為和客戶端主體緩衝機制的利用突顯了一個複雜的攻擊向量 2 。需要 pod 網路存取的要求 1 強調了 Kubernetes 環境中強健網路分段的重要性。

CVE-2025-24513: 認證 Secret 檔案目錄操控漏洞

雖然初步研究主要聚焦於 RCE 漏洞，但也發現了另一個漏洞 CVE-2025-24513 1 。此漏洞涉及 Ingress-Nginx 准入控制器功能中的不當輸入驗證問題，攻擊者提供的資料被包含在檔案名稱中，可能導致容器內的目錄操控(Directory traversal) 22 。此漏洞的 CVSS 分數為 4.8 1 ，表明其直接影響相較於 RCE 漏洞較不嚴重。然而，與其他漏洞結合時，可能導致拒絕服務 (DoS) 或從 cCuster 中有限披露 Secret 物件 1 。此檔案目錄操控漏洞雖不直接啟用 RCE，但可作為攻擊者收集更多系統檔案結構資訊或促進其他攻擊鏈的踏板 1 。

潛在安全風險與影響

被統稱為 "IngressNightmare" 的這些已識別漏洞，對 Kubernetes 環境帶來嚴重安全風險 1 。最重大威脅是未經身份驗證的攻擊者可能在 Ingress-Nginx Controller 的 pod 上實現遠端程式碼執行 (RCE) 1 。成功利用這些漏洞可導致未經授權存取 Kubernetes cluster中所有命名空間儲存的 Secret 1 。預設情況下，Ingress-Nginx 控制器通常擁有cluster範圍的 Secret 存取權 1 ，這使得此存取權特別危險。最終，控制所有cluster Secret 可能導致惡意行為者(Threat actor) 完全接管 Kubernetes cluster 1 。

研究指出，大量雲端環境易受這些問題影響。Wiz Research 發現約 43% 的雲端環境易受這些漏洞影響 1 。他們的分析還發現超過 6,500 個公開暴露的有漏洞 Kubernetes ingress 控制器，包括財星 500 強公司(Fortune 500 companies)的控制器 1 。這種廣泛暴露使大量 Kubernetes 環境面臨即時且關鍵的風險。包括主要組織在內的大量環境有漏洞，凸顯了這些漏洞容易被忽視或在眾多 Cluster 中及時更新的挑戰。

緩解措施與建議

為應對這些漏洞帶來的嚴重風險，強烈建議 Cluster 管理員採取以下緩解措施：

升級至最新更新版本：最首要且有效的緩解措施是將 Ingress-Nginx Controller 升級至 1.12.1 或 1.11.5 版 1 。這些版本包含已識別漏洞的必要更新。需注意的是，1.10.7 版也包括更新 1 。受影響的版本包括 1.11.5 和 1.12.1 之前的版本，包括 1.12.0 2 。
確保准入 webhook 端點不對外暴露：確認 Ingress-Nginx Controller 的准入 webhook 端點不從cluster外部存取至關重要 1 。已提供一個 Nuclei template 以協助檢查暴露的准入控制器 2 。
執行嚴格的網路政策：若無法立即升級，實施網路政策限制對准入控制器的存取，僅允許 Kubernetes API Server 與其通訊，可顯著降低風險 1 。
暫時停用准入控制器元件：若無法立即升級，可考慮暫時停用 Ingress-Nginx 的准入控制器元件 1 。若使用 Helm 安裝 Ingress-Nginx，可透過重新安裝並設定參數 controller.admissionWebhooks.enabled=false 實現 2 。對於手動安裝，應刪除名為 ingress-nginx-admission 的 ValidatingWebhookConfiguration，並從 ingress-nginx-controller 的 Deployment 或 DaemonSet 中移除 --validating-webhook 參數 2 。升級後重新啟用驗證准入控制器至關重要，因其為 Ingress 設定提供重要保障 2 。

要判斷cluster是否使用 Ingress-Nginx，管理員可執行命令
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx 2 。立即更新的優先順序，結合網路安全措施和臨時解決方案，提供了一個分層的緩解這些關鍵漏洞的方法。根據安裝方法停用准入控制器的具體指示為管理員提供了實用指導(Practical guidance)。更新後重新啟用准入控制器的提醒，強調了安全與維持基本功能之間的平衡。

結論

Kubernetes 的 Ingress-Nginx Controller 中發現的一系列漏洞，統稱為 "IngressNightmare"，對 Kubernetes 環境構成重大安全威脅 1 。這些缺陷，包括 CVE-2025-1097、CVE-2025-1098、CVE-2025-24514、CVE-2025-1974 和 CVE-2025-24513，可能讓未經身份驗證的攻擊者實現遠端程式碼執行，並透過存取敏感 Secret 完全控制 Kubernetes cluster 1 。鑑於 Ingress-Nginx 的廣泛採用和高比例的有漏洞環境，立即採取行動至關重要。強烈建議cluster管理員將 Ingress-Nginx Controller 升級至最新更新版本（1.12.1 或 1.11.5），並實施建議的緩解措施，特別是確保准入 webhook 端點不公開暴露 1 。持續監控、定期安全稽核以及遵循安全最佳實務(Best practices)，包括服務帳戶的最小權限原則(Principle of least privilege)，對維持 Kubernetes 環境的安全至關重要。

前言