[Security Advisory] CVE-2021-25748: Ingress-nginx `path` sanitization can be bypassed with newline character

Skip to first unread message

CJ Cullen

Jun 10, 2022, 12:09:49 PM6/10/22
to kubernete...@googlegroups.com, d...@kubernetes.io, kubernetes-sec...@googlegroups.com, kubernetes-se...@googlegroups.com, distributo...@kubernetes.io, kubernetes+a...@discoursemail.com

Issue Details

A security issue was discovered in ingress-nginx where a user that can create or update ingress objects can use a newline character to bypass the sanitization of the `spec.rules[].http.paths[].path` field of an Ingress object (in the `networking.k8s.io` or `extensions` API group) to obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.

This issue has been rated High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L), and assigned CVE-2021-25748.

Affected Components and Configurations

This bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -n ingress-nginx`.

If you are running the “chrooted” ingress-nginx controller introduced in v1.2.0 (gcr.io/k8s-staging-ingress-nginx/controller-chroot), you are not affected.

Multitenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.

Affected Versions

  • <v1.2.1

Fixed Versions

  • v1.2.1


If you are unable to roll out the fix, this vulnerability can be mitigated by implementing an admission policy that restricts the `spec.rules[].http.paths[].path` field on the networking.k8s.io/Ingress resource to known safe characters (see the newly added rules, or the suggested value for annotation-value-word-blocklist).


If you find evidence that this vulnerability has been exploited, please contact secu...@kubernetes.io

Additional Details

See ingress-nginx Issue #8686 for more details.


This vulnerability was reported by Gafnit Amiga.

Thank You,

CJ Cullen on behalf of the Kubernetes Security Response Committee

Reply all
Reply to author
0 new messages