IngressNightmare：Ingress NGINX 中存在 9.8 严重未经身份验证的远程代码执行漏洞

Wiz Research 发现了 CVE-2025-1097、CVE-2025-1098、CVE-2025-24514 和 CVE-2025-1974，这是 Kubernetes Ingress NGINX Controller 中一系列未经身份验证的远程代码执行漏洞，被称为#IngressNightmare。利用这些漏洞会导致攻击者未经授权访问 Kubernetes 集群中所有命名空间存储的所有机密，从而导致集群接管。 

此攻击媒介的 CVSS v3.1 基本评分为 9.8。 

在这篇博文中，我们分享了我们发现IngressNightmare的关键经验，该漏洞影响了 Kubernetes 的 Ingress NGINX Controller 的准入控制器组件。根据我们的分析，大约 43% 的云环境容易受到这些漏洞的影响，我们的研究发现，包括财富 500 强公司在内的 6,500 多个集群将易受攻击的 Kubernetes 入口控制器的准入控制器公开暴露在公共互联网上，使它们面临直接的严重风险。 

我们建议尽快修补。这篇博文详细介绍了该漏洞的技术要素，并包含针对防御者的缓解和检测指南。

我们要感谢 Ingress-NGINX 维护人员，特别是Marco Ebert，感谢他们帮助解决 IngressNightmare 漏洞。我们的团队与 Kubernetes 维护人员和安全团队密切合作，确保在公开披露之前完全消除此攻击面。Kubernetes 的博客可以在此处找到，亚马逊和Google Cloud也发布了自己的公告。

什么是 Kubernetes 的 Ingress NGINX 控制器？ 

Ingress NGINX Controller 是 Kubernetes 上最流行的入口控制器之一，也是 Kubernetes 的核心项目，在GitHub上有超过 18,000 颗星。使用 Ingress-NGINX 是向外部公开 Kubernetes 应用程序的最常用方法之一。作为入口控制器，它的工作是接受传入的流量并将其路由到相关的 Kubernetes 服务，然后服务根据一组规则将流量转发到适当的 Pod。具体来说，Ingress NGINX Controller 基于流行的NGINX 反向代理。  

图：来自 Kubernetes 文档的 Ingress 先决条件。 

Kubernetes 文档中明确强调了 Ingress-NGINX，将其作为 Ingress 控制器示例，满足在 Kubernetes 中使用 Ingress 的先决条件。我们的研究表明，超过 41% 的面向互联网的集群正在运行 Ingress-NGINX。 

漏洞  

Ingress NGINX 在其 pod 中部署了一个准入控制器，旨在在部署传入的入口对象之前对其进行验证。默认情况下，准入控制器无需身份验证即可通过网络访问，这使其成为极具吸引力的攻击媒介。 

当 Ingress-NGINX 准入控制器处理传入的入口对象时，它会从中构建 NGINX 配置，然后使用 NGINX 二进制文件对其进行验证。我们的团队在此阶段发现了一个漏洞，该漏洞允许通过网络将恶意入口对象直接发送到准入控制器，从而远程注入任意 NGINX 配置。  

在配置验证阶段，注入的 NGINX 配置会导致 NGINX 验证器执行代码，从而允许在 Ingress NGINX Controller 的 pod 上进行远程代码执行 (RCE)。 

准入控制器的提升权限和不受限制的网络可访问性创建了一条关键的升级路径。利用此漏洞，攻击者可以执行任意代码并访问命名空间中的所有集群机密，这可能导致完全接管集群。 

图：IngressNightmare 攻击向量 

需要明确的是，获得集群 pod 网络的初始访问权限并不像人们想象的那么困难 - 容器化本身并不是一个强大的安全边界，并且许多在 K8 上运行的应用程序都容易受到容器逃逸的影响，正如我们在过去几年对云和 SaaS 应用程序的研究中反复证明的那样。此外，这些漏洞与 SSRF 漏洞非常匹配，SSRF 漏洞在 Web 应用程序中可以说是很常见的情况。

缓解和检测 

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx首先，确定您的集群是否正在使用 ingress-nginx。在大多数情况下，您可以通过使用（至少）集群范围的只读权限运行来检查这一点。

此漏洞已在 Ingress NGINX Controller版本 1.12.1 和 1.11.5中修复。我们强烈建议集群管理员： 

• 更新到最新版本的 Ingress NGINX Controller。 

• 确保admission webhook 端点没有暴露给外部。 

您可以使用此Nuclei 模板https://gist.github.com/nirohfeld/7a7c82c62321de9c2ef95d266b241fcb来检查暴露的 Ingress-NGINX 准入控制器。 

• 如果您无法立即升级，请考虑以下缓解措施之一： 

• 实施严格的网络策略，以便只有 Kubernetes API 服务器可以访问准入控制器。 

• 如果您无法立即升级，请暂时禁用Ingress-NGINX 的准入控制器组件。

• 如果您已使用 Helm 安装了 ingress-nginx，请使用 重新安装controller.admissionWebhooks.enabled=false。 

• 如果您已经手动安装了 ingress-nginx，请删除ValidatingWebhookConfiguration调用并从容器的 Deployment 或 DaemonSet 中ingress-nginx-admission删除参数。--validating-webhookingress-nginx-controller

• 升级后请记住重新启用验证准入控制器，因为它为您的 Ingress 配置提供了重要的保障。

如果您想测试 IngressNightmare 的检测，可以使用以下流程使用 Terraform启动故意存在漏洞的集群：

git clone https://github.com/ofirc/ingress-nightmare.git
cd ingress-nightmare
terraform init
terraform plan
terraform apply -auto-approve

kubectl port-forward svc/ingress-nginx-controller-admission -n ingress-nginx 8443:443
curl -vk https://localhost:8443/validate -H \"Content-Type: application/json\" --data-binary @admission-review.json

Wiz 客户可以使用 Wiz 威胁中心中预先构建的查询和咨询。Wiz 还使用 Wiz 动态扫描仪验证暴露的准入控制器。最后，Wiz 运行时传感器通过持续监控入口流量、实时捕获恶意准入审查请求以及标记异常库负载来检测 IngressNightmare 等零日漏洞，以防止类似的攻击。

请注意，CVE-2025-24513 的性质与 IngressNightmare 链中的其他漏洞不同，因为它不会导致 RCE。

我们是如何发现 IngressNightmare 的？ 

研究动机 

Kubernetes 准入控制器是 Kubernetes 环境中一个有趣且经常被忽视的攻击面。它们由 Kubernetes API 服务器触发，在处理请求之前对其进行审查并可能修改或阻止请求 ( AdmissionReview)，并且它们通常在集群内以相对较高的权限运行。准入控制器通常不需要身份验证，本质上充当 Web 服务器，在集群中引入额外的内部网络可访问端点。这种架构允许攻击者直接从网络中的任何 pod 访问它们，从而大大增加了攻击面。 

Kubernetes 的 Ingress NGINX 控制器背景 

Ingress NGINX Controller是一个使用 NGINX 作为反向代理和负载均衡器的入口实现。它是最受欢迎的入口之一，也是 Kubernetes 的核心项目。 

为了在 Kubernetes 和 NGINX 配置（非 Kubernetes 原生技术）之间架起桥梁，控制器尝试将 Kubernetes Ingress 对象转换为 NGINX 配置。为了确保 NGINX 服务器的稳定性，控制器采用了验证准入 Webhook，在应用最终配置之前对其进行验证。

图：Ingress NGINX Controller 简化图

从攻击者的角度来看，准入控制器是一个负责复杂操作的未经身份验证的 HTTP 端点，并且默认以 Kubernetes 角色运行，允许访问所有环境的机密，这使其成为一个有吸引力的研究目标。  

远程 NGINX 配置注入 

在审查 Ingress NGINX Admission Controller 代码的过程中，我们发现了一个有趣的代码路径：当它处理传入的AdmissionReview请求时，它会根据模板文件和提供的 Ingress 对象生成一个临时的 NGINX 配置文件。然后，它使用nginx -t命令测试临时配置文件的有效性。我们发现了多种在此代码路径中注入新配置指令的方法。 

// testTemplate checks if the NGINX configuration inside the byte array is valid 
// running the command "nginx -t" using a temporal file. 
func(n *NGINXController)testTemplate(cfg []byte)error { 
... 
    tmpfile, err := os.CreateTemp(filepath.Join(os.TempDir(), "nginx"), tempNginxPattern) 
... 
    err = os.WriteFile(tmpfile.Name(), cfg, file.ReadWriteByUser) 
... 
    out, err := n.command.Test(tmpfile.Name()) 

func(nc NginxCommand)Test(cfg string)([]byte, error) { 
    //nolint:gosec // Ignore G204 error 
    return exec.Command(nc.Binary, "-c", cfg, "-t").CombinedOutput() 
}

通常，只有 Kubernetes API 服务器才应该发送这些 AdmissionReview 请求。但是，由于 Admission Controller 缺乏身份验证，因此具有最低限度网络访问权限的攻击者可以从集群中的任何 pod 制作并发送任意 AdmissionReview 请求。 

为了进行测试，我们使用kube-review从 Ingress 资源清单创建准入审查请求，然后可以通过 HTTP 将其直接发送到准入控制器。

{ 
    "kind": "AdmissionReview", 
    "apiVersion": "admission.k8s.io/v1", 
    "request": { 
        "uid": 


    
"732536f0-d97e-4c9b-94bf-768953754aee", 
... 
        "name": "example-app", 
        "namespace": "default", 
        "operation": "CREATE", 
... 
        "object": { 
            "kind": "Ingress", 
            "apiVersion": "networking.k8s.io/v1", 
            "metadata": { 
                "name": "example-app", 
                "namespace": "default", 
... 
                "annotations": { 
                    "nginx.ingress.kubernetes.io/backend-protocol": "FCGI"
                } 
            }, 
            "spec": { 
                "ingressClassName": "nginx", 
                "rules": [ 
                    { 
                        "host": "app.example.com", 
                        "http": { 
                            "paths": [ 
                                { 
                                    "path": 


    
"/", 
                                    "pathType": "Prefix", 
                                    "backend": { 
                                        "service": { 
                                            "name": "example-service", 
                                            "port": {} 
                                        } 
                                    } 
                                } 
                            ] 
                        } 
                    } 
                ] 
            }, 
... 
    } 
}

图：入学审查对象的示例 

如上所示，我们可以控制许多字段，这显示出巨大的攻击面。在这篇博文中，我们将研究注释解析器中的两个漏洞，这些解析器解析.request.object.annotations 上述请求中的字段。此字段的属性随后包含在 NGINX 配置文件中 - 我们用它来注入任意指令。 

CVE-2025-24514 – auth-url 注释注入 

authreq解析器负责处理与身份验证相关的注释。注释需要设置 auth-url 字段，其中包含 URL，并最终传播到配置文件中，代码流程如下 ：

func(a authReq)Parse(ing *networking.Ingress)(interface{}, error) { 
    // Required Parameters 
    urlString, err := parser.GetStringAnnotation(authReqURLAnnotation, ing, a.annotationConfig.Annotations) 
    if err != nil { 
        returnnil, err 
    }

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 }}

nginx.ingress.kubernetes.io/auth-url: "http://example.com/#;\ninjection_point"

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

此漏洞不适用于v1.12.0。在此版本中，Ingress NGINX Controller 更改了其默认安全设置，以根据严格的正则表达式规则验证所有注释（包括 auth-url）。  

CVE-2025-1097 – auth-tls-match-cn 注释注入 

对于其auth -tls-match-cn 注释，authtls 解析器使用CommonNameAnnotationValidator来验证字段值： 

funcCommonNameAnnotationValidator(s string)error { 
    if !strings.HasPrefix(s, "CN=") { 
        return fmt.Errorf("value %s is not a valid Common Name annotation: missing prefix 'CN='", s) 
    } 
    


    
if _, err := regexp.Compile(s[3:]); err != nil { 
        return fmt.Errorf("value %s is not a valid regex: %w", s, err) 
    } 
    returnnil
}

换句话说，auth-tls-match-cn 注释需要： 

1. 该值必须以 CN= 开头。 

2. 所有剩余的字符必须形成有效的正则表达式。 

与上一个注入类似，$server.CertificateAuth.MatchCN 对应于注释的值auth-tls-match-cn。虽然有点棘手，但我们仍然可以绕过这两个要求，在模板的这一部分注入任意 NGINX 配置：

if ( $ssl_client_s_dn !~ {{ $server.CertificateAuth.MatchCN }} ) { 
    return 403 "client certificate unauthorized"; 
}

nginx.ingress.kubernetes.io/auth-tls-match-cn: "CN=abc #(\n){}\n }}\nglobal_injection;\n#"

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

kube-system/konnectivity-certs 
kube-system/azure-wi-webhook-server-cert 
kube-system/aws-load-balancer-webhook-tls 
kube-system/hubble-server-certs 
kube-system/cilium-ca
calico-system/node-certs 
cert-manager/cert-manager-webhook-ca
linkerd/linkerd-policy-validator-k8s-tls 
linkerd/linkerd-proxy-injector-k8s-tls 
linkerd/linkerd-sp-validator-k8s-tls

感谢您抽出

.

.

来阅读本文

点它，分享点赞在看都在这里