TL;DR

In Kubernetes, the Ingress object defines HTTP/HTTPS rules for routing external traffic to internal cluster services. For these rules to take effect, a running Ingress Controller is required [1]. The ingress-nginx is one such controller, based on NGINX, and its official documentation describes that it is built around the Ingress resource, using ConfigMap for controller configuration [2].

CVE-2026-24512 describes a configuration injection vulnerability in ingress-nginx: the rules.http.paths.path field can be used to inject content into the nginx.conf. The officially reported impact includes code execution in the context of the controller and disclosure of secrets accessible by it [3][4].

The severity published by the CNA (Kubernetes) is CVSS v3.1 8.8 (High) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H [3][4].

The discovery was officially attributed to Maxime Escourbiac and Yassine Bengana (Michelin CERT) [3] [8].

→ Fix for CVE-2026-24512 on Quor.
Enjoy 14 free days of our image: app.quor.dev

How the vulnerability happens

1. An attacker with permission to create/edit Ingress sends a malicious path in     rules.http.paths.path.

2. The controller processes this value when rendering the NGINX template.

3. Without proper escaping/quoting, the value can “break” the expected directive and inject additional configuration.

4. NGINX reloads the resulting configuration.

* In summary: the core issue is insecure handling of untrusted input during nginx.conf generation [3][6][9].

Am I affected?

If you do not use ingress-nginx, this CVE does not apply [3].

  1. Check for ingress-nginx in the cluster

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

  2. Check the images/versions in use

 kubectl get deploy -A -l app.kubernetes.io/name=ingress-nginx \
    -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}
  {range .spec.template.spec.containers[*]}{.name}={.image}{" "}{end}{"\n"}{end}'

  3. Compare with affected ranges

•   ingress-nginx < v1.13.7

•   ingress-nginx < v1.14.3

    (in operational practice: update to v1.13.7, v1.14.3 or higher) [3][5].

Example manifest with valid test payload (non-exploitative)

This payload is useful for validating quote and backslash sanitization (same pattern used in the patch tests):

 apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: cve-2026-24512-sanitization-test
  spec:
    ingressClassName: nginx
    rules:
    - host: escape.test
      http:
        paths:
        - path: '/"\\'
          pathType: ImplementationSpecific
          backend:
            service:
              name: test
              port:
                number: 80

With the fix applied, the expected rendering keeps the value within quotes and escaped in the nginx.conf, in the format equivalent to:

location "/\"\\\\" {
      ...
  }

Impact

This includes the potential for code execution inside the ingress-nginx pod, which would give the attacker control over the controller process. In addition, there is a risk of exposing Secrets accessible by this controller; in default configurations, this can cover cluster-wide Secrets, significantly scope-broadening the reach of the compromise. [3]

Subscribe to Quor's newsletter: supply chain security updates

Fix and why the vulnerability occurred

Patch diff: https://github.com/kubernetes/ingress-nginx/pull/14501/files [9]

The patch addresses the vulnerability by escaping and quoting what came from the Ingress before rendering in the nginx.conf, preventing path or server_name values from escaping out of the directive and injecting configuration.

1. buildLocation now always quotes the path and escapes \ and " using the new function sanitizeQuotedRegex.

• Before: the path was inserted raw, including in PathTypeExact (= %s) and default (%s).

• Now: PathTypeExact uses = "%s" and the default uses "%s", always escaping \ and ".

2. server_name and aliases also became quoted/escaped in the NGINX template.

• server_name uses | quote and aliases pass through sanitizeQuotedRegex.

In short, by placing these values inside quotes and escaping special characters, this addresses the configuration injection risk, preventing malicious inputs from “closing” the directive and injecting new instructions in the nginx.conf

Recommendation

1. Primary action: upgrade to v1.13.7, v1.14.3 or higher [3][5][10].

2. Temporary mitigation: use admission validation to reject Ingress with pathType=ImplementationSpecific until upgrading [3].

3. Monitoring: treat suspicious values in rules.http.paths.path as indicators of exploitation attempts [3].

Conclusion

CVE-2026-24512 is critical for environments using ingress-nginx because it combines an injection vector in proxy configuration with a high potential impact (RCE + disclosure of secrets). Mitigation by admission policy reduces immediate risk but does not replace upgrading to fixed versions.

References

[1] https://kubernetes.io/docs/concepts/services-networking/ingress/
[2] https://kubernetes.github.io/ingress-nginx/
[3] https://github.com/kubernetes/kubernetes/issues/136678
[4] https://nvd.nist.gov/vuln/detail/CVE-2026-24512
[5] https://www.runzero.com/blog/k8s-ingress-nginx-controller/
[6] https://owasp.org/www-community/attacks/Code_Injection
[7] https://app.quor.dev/images/76/default/ingress-nginx-controller/details
[8] https://cert.michelin.com/
[9] https://github.com/kubernetes/ingress-nginx/pull/14501
[10] https://kubernetes.github.io/ingress-nginx/deploy/upgrade/