Skip to main content

Documentation Index

Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt

Use this file to discover all available pages before exploring further.

Published on March 26, 2025
Ingress Nightmare — CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974. On a Kubernetes cluster using Ingress NGINX, an attacker who can reach the admission webhook can execute arbitrary code and, by cascade, take over the cluster.

​
Scope

The flaw affects Ingress NGINX Controller (not to be confused with NGINX Ingress Controller, the F5/NGINX-maintained project, which is a different product). Vulnerable versions:
  • all versions < v1.11.0
  • v1.11.0 to v1.11.4
  • v1.12.0
Quick check: 
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{.items[*].spec.containers[*].image}'

​
How the attack works

When you install Ingress NGINX, an admission controller is deployed inside the cluster. Its job: validate Ingress objects before they are applied to NGINX. The problem: this webhook is reachable on the cluster network, without authentication, by default. An attacker who can reach the webhook (from a compromised pod, a poorly-isolated internal service, or sometimes directly from outside if the Service is exposed) sends a malicious Ingress object. The webhook processes the object, builds an NGINX configuration from it, and validates it by running the NGINX binary… which at that point interprets the injected payload. RCE in the controller pod. Then comes the cascade. The controller pod typically has rights to read Secrets across all namespaces (because it mounts TLS certificates). Once RCE is achieved, the attacker reads every secret in the cluster — internal credentials, cloud tokens, API keys. Cluster takeover.

​
Patching

Upgrade Ingress NGINX Controller to the latest stable version available — past anything listed as vulnerable. Follow your usual Helm/manifest procedure depending on your install.

​
If you cannot patch right away

Two surface-reduction measures to apply in the meantime:

​
1. Restrict network access to the webhook

A NetworkPolicy that only lets the Kubernetes API server talk to the admission webhook: 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress-nginx-admission-only-apiserver
  namespace: ingress-nginx
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/component: admission-webhook
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: <API server CIDR>
      ports:
        - port: 8443
          protocol: TCP
Tune the CIDR to your cluster.

​
2. Temporarily disable the admission webhook

If the NetworkPolicy is not workable and you intend to patch right after, you can disable the admission component. With Helm: 
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --reuse-values \
  --set controller.admissionWebhooks.enabled=false
You lose admission-time validation of Ingress objects — so preventive safety on malformed configs — but you close the attack path until the patch is in.

​
Wrap-up

This is an RCE → secret theft → takeover chain that requires no authentication, on a component many clusters expose by default. A PoC is public. Patch, and use the moment to double-check the NetworkPolicy around every one of your admission webhooks. For questions, open a ticket from your OnetSolutions client area.