Three unpatched high-severity security vulnerabilities have been disclosed in the NGINX Ingress controller for Kubernetes. These vulnerabilities could potentially be exploited by threat actors to steal secret credentials from the cluster.
The vulnerabilities are as follows:
- CVE-2022-4886 (CVSS score: 8.8): Ingress-nginx path sanitization can be bypassed to obtain credentials of the Ingress-nginx controller.
- CVE-2023-5043 (CVSS score: 7.6): Ingress-nginx annotation injection allows for arbitrary command execution.
- CVE-2023-5044 (CVSS score: 7.6): Code injection is possible via the nginx.ingress.kubernetes.io/permanent-redirect annotation.
Ben Hirschberg, CTO and co-founder of Kubernetes security platform ARMO, noted that these vulnerabilities could allow an attacker who can control the configuration of the Ingress object to steal secret credentials from the cluster. Successful exploitation of these flaws could lead to arbitrary code injection into the ingress controller process and unauthorized access to sensitive data.
CVE-2022-4886 is a result of a lack of validation in the “spec.rules[].http.paths[].path” field, enabling an attacker with access to the Ingress object to extract Kubernetes API credentials from the ingress controller. The vulnerable application does not properly validate the inner path, potentially pointing to the internal file containing the service account token, which serves as the client credential for authentication against the API server.
Although patches for these vulnerabilities are not available at the moment, the software maintainers have released mitigations. These measures include enabling the “strict-validate-path-type” option and setting the “–enable-annotation-validation” flag to prevent the creation of Ingress objects with invalid characters and impose additional restrictions.
ARMO recommends updating NGINX to version 1.19 while adding the “–enable-annotation-validation” command-line configuration to address CVE-2023-5043 and CVE-2023-5044.
Hirschberg stressed that these vulnerabilities all point to the same underlying problem, emphasizing the high privilege scope of ingress controllers. As these controllers often handle TLS secrets and have access to the Kubernetes API by design, they are considered workloads with high privilege levels. Additionally, since they are frequently public-facing components on the internet, they are vulnerable to external traffic that enters the cluster through them.
