The Trio of Unpatched Flaws in NGINX Ingress Controller for Kubernetes
Cybersecurity experts have identified three critical, unpatched vulnerabilities in the NGINX Ingress traffic controller. These flaws could potentially lead to the leakage of credentials and other confidential data from Kubernetes clusters.
Unveiled on October 27th, the vulnerabilities were labeled CVE-2023-5043, CVE-2023-5044, and CVE-2022-4886. It remains uncertain whether they have been exploited in real-world attacks or when a remedy will be released.
All three vulnerabilities affect the NGINX Ingress Controller, which serves as a reverse proxy and load balancer in Kubernetes, up to version 1.9.0.
The first two breaches, CVE-2023-5043 and CVE-2023-5044, stem from insufficient input validation and could lead to arbitrary code execution, privileged credential access, and the theft of all cluster secrets. Both issues have been rated at 7.6 out of 10 on the CVSS scale.
To mitigate the problem two actions need to be taken:
- Update NGINX to version 1.9.0
- Add the “–enable-annotation-validation” command line configuration
There is no “fixed version” for these vulnerabilities if updating to version 1.9.0 and adding the command line “–enable-annotation-validation” mitigates the problem.
The third vulnerability, CVE-2022-4886, holds a higher rating of 8.8 on the CVSS scale. This flaw can be exploited during the creation or updating of Ingress objects, allowing malefactors to access Kubernetes API credentials from the Ingress controller, thereby stealing all cluster secrets. It impacts versions up to 1.8.0.
Mitigating this vulnerability depends on the “pathType” configuration, dictating proxy behavior. In case the rule has “pathType” “Exact” or “Prefix”, the “strict-validate-path-type” option should be enabled from nginx-ingress-controller version 1.8.0. In case that “pathType” “ImplementationSpecific” is used, then the mitigation involves admission controller policy.
The security of Ingress controllers is particularly concerning as they inherently have access to TLS secrets and the Kubernetes API, marking them as privileged workloads. Given their prominence as internet-facing components, the risk of external attacks escalates considerably.
