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

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

Note: 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	Impact	Preconditions	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	Auth Bypass	Custom Error Pages + AuthURL	v1.13.7 / v1.14.3	nginx.ingress.kubernetes.io/auth-url usage
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 Wiz 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.

Bash

`# 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.

Bash

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 or 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:

Bash

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

Why this matters: 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.

Bash

# 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 get or list 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 or 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.

Bash

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. Version: 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	Type	Fixed Versions
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	Auth Bypass	v1.13.7, v1.14.3
2026	CVE-2026-24514	DoS	v1.13.7, v1.14.3
2025	CVE-2025-1974	Admission Bypass	v1.12.x

8.2 Upgrade decision tree

1. Check Current Version:
   • If < v1.13.7: Critical Urgency. Upgrade to v1.13.7 (Stable) immediately.
   • If 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