Ingress-NGINX CVEs That Actually Matter: Patch Paths, Real Blast Radius, and How to Prove You’re Safe

2026 status: CVE-2025-1974 was patched, but Ingress NGINX is retired

Current as of November 2, 2026: the Kubernetes project announced that best-effort maintenance would end in March 2026. That date has passed. The upstream project is retired; no further releases, bug fixes, or security updates are planned. Existing installations may continue to run and artifacts may remain available, but availability is not maintenance.

This changes the decision from “which patched controller version should I run?” to two separate tasks: prove that the historical CVE-2025-1974 fix is present, and plan migration away from an unmaintained controller. A fixed image reduces exposure to the known 2025 flaw; it does not provide a future security support commitment.

The official Kubernetes retirement announcement recommends that all users begin migration to Gateway API or another Ingress controller. Its original CVE notice lists ingress-nginx v1.12.1 and v1.11.5 as the releases fixing the March 2025 vulnerability batch. Use vendor-supported later images where available and preserve the exact image digest as evidence.

CVE-2025-1974: what patch verification must prove

CVE-2025-1974 affected the validating admission controller path. Under the documented conditions, an unauthenticated attacker with access to the Pod network could reach the admission surface and combine the issue with related configuration injection flaws. The security outcome could be code execution in the controller context and disclosure of Secrets the controller could access. The Kubernetes Security Response Committee’s original notice describes the risk and temporary mitigation. This is not a claim that every installation was exploitable or compromised.

For the historical fix, verify the running controller image and digest, not only Helm values or a desired Deployment manifest. Confirm all replicas have replaced old pods, identify whether a validating admission webhook is still configured, and review whether it is reachable from untrusted Pod-network sources. If admission was disabled as a temporary mitigation, record that state and the reason; do not silently re-enable an obsolete component and treat it as a long-term answer.

kubectl -n ingress-nginx get deploy,ds,pods -o wide
kubectl -n ingress-nginx get pods -o jsonpath='{range .items[*]}{.metadata.name}{"	"}{range .spec.containers[*]}{.image}{"
"}{end}{end}'
kubectl get validatingwebhookconfigurations
kubectl get ingressclass -o yaml

These are inventory commands for an authorized cluster. They do not test the exploit. Compare the observed image digest against the approved fixed artifact or vendor backport, then confirm that every controller replica is running it. A chart version alone is insufficient because charts can reference mutable image tags.

Retirement migration inventory

Build an inventory before selecting a replacement. Export every IngressClass and Ingress object, controller arguments, ConfigMaps, admission webhook configuration, Service and LoadBalancer addresses, certificates, and RBAC bindings. For each route, record hostnames, path types, backend services, TLS secrets, default backends, rewrite behavior, timeout and body-size settings, client IP handling, and health checks.

Search annotations individually. Pay special attention to snippet annotations, authentication URLs, custom error backends, rate limits, allowlists, canary behavior, rewrite-target, proxy protocol, upstream TLS, and vendor-specific WAF integrations. Snippets may contain raw NGINX directives and have no direct one-to-one Gateway API equivalent. Do not copy them into a new controller without security review.

Inventory TCP and UDP services separately; these may be configured through controller-specific ConfigMaps or flags rather than Ingress objects. Also map external DNS automation, certificate renewal, cloud load balancer health checks, source IP preservation, network policies, and observability labels. A route migration that preserves HTTP responses but drops client IP or WAF policy is not complete.

Choose and validate a replacement

Kubernetes lists multiple Ingress controller implementations. Gateway API is a separate API with role-oriented resources and implementation-specific support. Review the official migration guidance そして ingress2gateway as aids, not as proof of a lossless conversion. Generated resources require review against the selected Gateway controller’s conformance and feature support.

Run a representative test matrix in parallel: HTTP and HTTPS routes, redirects, large uploads, WebSockets or gRPC if used, authentication and authorization, source IP, timeouts, retries, rate limiting, WAF inspection, certificate rotation, health checks, and failure behavior. Compare status codes and headers as well as backend selection. Exercise the Admission path and confirm that configuration policy is enforced before cutover.

Cutover, rollback, and completion evidence

Deploy the replacement with isolated test hostnames or a controlled traffic slice. Keep DNS TTL, load balancer health, certificate issuance, and rollback ownership explicit. Define rollback triggers before moving traffic: failed health checks, authentication bypass, missing security headers, incorrect source IP, elevated 4xx/5xx, or policy drift. Ensure rollback does not reactivate a vulnerable or retired controller as the normal long-term state.

Close the migration only when the new controller is serving every required route, old ingress-nginx workloads and admission hooks are removed, stale load balancers and firewall paths are cleaned up, and dashboards and runbooks point to the new control plane. Retain a route-by-route mapping and test evidence. The project recommends Gateway API or another maintained controller; the correct choice depends on supported features, operating model, and vendor commitments.

1. Why “ingress-nginx cve” searches spike

When a high-severity Ingress-NGINX advisory drops, engineering teams usually face two immediate problems. First is the “What do I do today?” problem. CVE descriptions are often abstract; engineers need a direct map connecting the CVE to affected versions, fixed versions, and specific mitigation steps.

Second is the “Prove it” problem. Security teams and auditors need more than a verbal assurance that “we patched it.” They need evidence—commands, logs, and configuration diffs—to close tickets.

This guide skips the fluff. It focuses on the current 2026 disclosure landscape, the lingering lessons from 2025’s “IngressNightmare,” and how to verify your cluster is actually safe.

A Quick Glossary for This Guide

• Ingress: The Kubernetes object defining routing rules (HTTP/HTTPS).
• Controller: The Pod (ingress-nginx) that reads those rules and configures the NGINX binary.
• Admission Controller: The “bouncer” (ValidatingWebhook) that intercepts API requests to validate Ingress syntax before the Controller sees them.
• Annotations: Metadata attached to Ingress objects to customize NGINX behavior (often the vector for injection attacks).
• Secrets: Kubernetes objects holding TLS certs. By default, many controllers mount all Secrets, creating a high-value target.

2. The current 2026 ingress-nginx disclosure: CVEs, severity, fixed versions

2.1 The official patch line you can quote in a ticket

To remediate the vulnerabilities listed below, you must upgrade your Ingress-NGINX controller to one of the following versions (or later):

• Stable Track: v1.13.7
• Newer Feature Track: v1.14.3

注： Two tracks exist to allow teams to consume security patches on the stable line without forced adoption of potentially breaking features introduced in v1.14.x.

2.2 CVE-2026-24512: Config injection via rules.http.paths.path

This is the critical vulnerability in this batch. It involves unsafe input validation in the rules.http.paths.path field. If an attacker (or a user with limited permissions) creates an Ingress with a malicious path, they can inject raw NGINX configuration directives.

Practical Risk: Because the ingress controller runs with high privileges (often reading all Secrets in the cluster to handle TLS), “Ingress write permission” effectively equates to “Cluster Secret Compromise.”

2.3 CVE-2026-1580: Annotation-based injection variant

Consider this a sibling to 24512. It is the same class of bug—Command/Config Injection—but triggered via specific user-controlled annotations rather than the path field. While the entry point differs, the result (code execution within the controller context) is identical.

2.4 CVE-2026-24513: Auth-url protection bypass

This vulnerability is configuration-dependent. It impacts clusters using the auth-url annotation for external authentication. If your backend is misconfigured to ignore the X-Code header and you rely on custom 401/403 error pages, an attacker may bypass the authentication check.

Key takeaway: The default built-in backend is safe. Risk rises significantly when teams swap in custom error handling components without validating upstream header logic.

2.5 CVE-2026-24514: Admission controller DoS

This is a Denial of Service vector targeting the admission controller. By sending specially crafted, massive requests, an attacker can spike memory consumption, causing the controller pod to be OOMKilled (Out of Memory) or creating significant node pressure.

Summary Matrix

CVE	インパクト	前提条件	Fixed In	Check First
CVE-2026-24512	RCE / Secret Theft	Ingress Creation Rights	v1.13.7 / v1.14.3	Who can create Ingress?
CVE-2026-1580	RCE / Secret Theft	Ingress Creation Rights	v1.13.7 / v1.14.3	Specific annotations used
CVE-2026-24513	認証バイパス	Custom Error Pages + AuthURL	v1.13.7 / v1.14.3	nginx.ingress.kubernetes.io/auth-url 使用状況
CVE-2026-24514	DoS (Availability)	Network access to Admission API	v1.13.7 / v1.14.3	Admission webhook reachability

3. The 2025 baseline engineers still reference: IngressNightmare

3.1 CVE-2025-1974 and the “admission surface” lesson

In 2025, the industry learned a painful lesson about the admission controller as an attack surface. The Kubernetes Blog and research from ウィズ highlighted that while we often focus on the NGINX data plane, the admission webhook (the management plane) often lacks the same network restrictions.

This shifted the playbook: hardening Ingress isn’t just about NGINX config; it’s about protecting the Kubernetes API components that manage it.

3.2 What “43% vulnerable” really means

You may recall Wiz’s research finding that “43% of clusters were vulnerable.” It is vital to interpret this responsibly. This figure did not mean 43% of clusters were actively compromised. It meant that 43% of scanned environments had the combination of a vulnerable version, an exposed dashboard/webhook, and over-permissive RBAC. It measures exposure potential, not active exploitation.

3.3 Reusable engineering controls that still apply in 2026

The remediations for 2025’s “IngressNightmare” remain the foundation for 2026 defense:

1. Admission Endpoint Reachability: Ensure the admission controller is not exposed to the public internet via LoadBalancer.
2. RBAC: restrict create/update permissions on Ingress objects.
3. Secret Scoping: Do not run the controller with the -watch-all-namespaces flag unless absolutely necessary.

4. Fast triage: determine exposure in your cluster

Note: These commands are for identification and validation only. Do not run exploit scripts against production clusters.

4.1 Identify controller version and installation method

First, get the running image tag.

バッシュ

`# Check Deployment image kubectl -n ingress-nginx get deploy ingress-nginx-controller -o jsonpath='{.spec.template.spec.containers[0].image}’

If installed via Helm, check chart version

helm list -n ingress-nginx`

4.2 Confirm admission features are enabled and reachable

Check if the ValidatingWebhook exists and where it points.

バッシュ

kubectl get validatingwebhookconfigurations ingress-nginx-admission -o yaml

Risk Check: Look at the service definition associated with the admission controller. If the Service type is LoadBalancer または NodePort, check your firewall rules. If the admission port (usually 8443) is accessible from the internet, your risk score for CVE-2026-24514 (DoS) is High.

4.3 Find “who can mutate Ingress” (RBAC reality check)

The injection CVEs (24512/1580) require the ability to create or edit an Ingress object. Check permissions:

バッシュ

# Check if a specific user/service account can create ingress kubectl auth can-i create ingress --as system:serviceaccount:default:pipeline-bot -n production

なぜこれが重要なのか： In many organizations, CI/CD bots or “developer” roles have broad PR:L (Pull Request: Live) access. If a compromised developer account can post an Ingress manifest, they can exploit the controller.

4.4 Secret blast radius assessment

Determine what happens if the controller is compromised.

バッシュ

# Check the ClusterRole bound to the controller's ServiceAccount kubectl get clusterrole -l app.kubernetes.io/name=ingress-nginx

If the ClusterRole contains secrets with verb 得る または リスト at the cluster scope, a controller compromise results in total cluster secret exposure.

5. Mitigation playbook: what you can do before the upgrade window

5.1 The only durable fix: upgrade

There is no “patch” other than replacing the binary. Plan to upgrade to v1.13.7 または v1.14.3 immediately. Refer to the Kubernetes security announcement for hash verification.

5.2 Partial mitigations per vulnerability class

If you cannot upgrade immediately (e.g., waiting on a change freeze window):

• For Injection (CVE-2026-24512 / 1580):
  • Implement an external policy engine (OPA/Kyverno) to reject Ingress objects containing specific annotations or regex patterns in paths.
  • Temporarily restrict RBAC: remove create/patch Ingress permissions for non-admin users.
• For Auth Bypass (CVE-2026-24513):
  • Verify your backend configurations. Ensure custom error pages strictly validate headers or revert to the default backend.
• For DoS (CVE-2026-24514):
  • Apply stricter ResourceQuotas to the controller namespace.
  • Use NetworkPolicies to restrict access to the admission webhook port (8443) to only the Kubernetes API server.

5.3 Controls that reduce “controller as cluster admin” reality

To reduce the blast radius permanently:

• Scope Secrets: Run the controller with -watch-namespace (one controller per namespace) rather than cluster-wide.
• Network Policies: Isolate the controller. It should only talk to the endpoints it routes traffic to (North-South) and the API server. It should not have broad East-West access.

6. Verification: how to prove remediation

6.1 Post-upgrade checks

After upgrading, verify the running Pods are using the new image sha256.

バッシュ

kubectl get pods -n ingress-nginx -o jsonpath="{.items[*].spec.containers[*].image}"

6.2 Continuous detection signals

Security teams should monitor Kubernetes Audit Logs for suspicious activity:

• Spikes in Annotation Updates: A high frequency of updates to nginx.ingress.kubernetes.io/* annotations.
• Anomalous Webhook Traffic: Unexpected high-volume traffic targeting the admission service.

Example Audit Query Logic:

verb=create OR verb=patch AND resource=ingress AND user != [known_admin_users] AND response=2xx

6.3 A pragmatic security regression checklist

Platform teams should adopt this regression test for every Ingress upgrade:

1. バージョン Is the controller running a patched version?
2. Exposure: Is the admission webhook blocked from the public internet?
3. RBAC: Are permissions least-privilege (no wildcard Secret access)?
4. Config: Is enable-underscores-in-headers or other risky flags explicitly reviewed?

7. Turning CVE advisories into repeatable verification

CVE advisories provide the data, but they don’t provide the workflow. Penligent bridges the gap between “we think we patched it” and “we verified the fix,” without the need for destructive exploit testing.

Instead of running risky exploit code, you can use Penligent to run an automated, non-intrusive audit of your cluster’s exposure. Penligent can instantly map the admission controller’s reachability, validate the running version against the CVE database, and map the RBAC blast radius of the controller’s Service Account. This generates a verifiable evidence report you can attach directly to your remediation ticket.

• Penligent: Overview of Penligent’s Automated Penetration Testing Tool

8. Appendix: CVE reference table and upgrade decision tree

8.1 One-page CVE table (engineer-friendly)

Year	CVE	タイプ	固定バージョン
2026	CVE-2026-24512	Config Injection	v1.13.7, v1.14.3
2026	CVE-2026-1580	Annotation Injection	v1.13.7, v1.14.3
2026	CVE-2026-24513	認証バイパス	v1.13.7, v1.14.3
2026	CVE-2026-24514	ドス	v1.13.7, v1.14.3
2025	CVE-2025-1974	Admission Bypass	v1.12.x

8.2 Upgrade decision tree

1. Check Current Version:
   • もし < v1.13.7: Critical Urgency. Upgrade to v1.13.7 (Stable) immediately.
   • もし v1.14.0 – v1.14.2: Upgrade to v1.14.3.
2. Can you upgrade in 72 hours?
   • Yes: Schedule maintenance window. Verify image sha.
   • No:
     • Block admission webhook from internet.
     • Restrict create ingress RBAC to Admins only.
     • Monitor logs for rules.http.paths.path anomalies.

Further Reading

• Kubernetes Security Announcement: Ingress-NGINX CVE List
• GitHub Advisory Database: CVE-2026-24512 Details
• NVD Entry: CVE-2026-24513
• Kubernetes Blog: CVE-2025-1974 Mitigation
• Wiz Research: IngressNightmare Analysis
• Rapid7: Ingress-NGINX Vulnerability Context
• Penligent: Cloud-Native Security Practices Explained
• Penligent: RBAC + Kubernetes & Cloud IAM in 2025