Mitigating the Latest Kubernetes NGINX Ingress Controller CVEs

CVE-2023-5043, CVE-2023-5044 and CVE-2022-4886 are High-severity ingress-nginx flaws that let a user who can create or update Ingress objects obtain the controller’s credentials, which by default can read every secret in the cluster. Upgrade to v1.9.0 and enable the validation options, and use the Kyverno policies below to block the abused annotations and restrict pathType values.

The three ingress-nginx CVEs at a glance

CVE	What is abused	Severity (CVSS 3.1)	Affected	Mitigation available in	Upstream mitigation
CVE-2023-5043	`configuration-snippet` annotation	High, 7.6 (NVD: 8.8)	Earlier than v1.9.0	v1.9.0	`--enable-annotation-validation` flag
CVE-2023-5044	`permanent-redirect` annotation	High, 7.6 (NVD: 8.8)	Earlier than v1.9.0	v1.9.0	`--enable-annotation-validation` flag
CVE-2022-4886	`spec.rules[].http.paths[].path` sanitization bypass	High, 8.8 (NVD: 6.5)	Earlier than v1.8.0	v1.8.0	`strict-validate-path-type` ConfigMap option

Severity scores are from the Kubernetes Security Response Committee advisories, with NVD’s own scores in parentheses (CVE-2023-5043, CVE-2023-5044, CVE-2022-4886). All three are listed in the Kubernetes official CVE feed. Multi-tenant clusters where non-admin users can create Ingress objects are the most exposed. Kubernetes SIG Network and the Security Response Committee have since announced the retirement of Ingress NGINX, with best-effort maintenance ending in March 2026 and no security fixes after that.

What are CVE-2023-5043, CVE-2023-5044 and CVE-2022-4886?

Recently, a few new vulnerabilities for Kubernetes Nginx Ingress controllers have made their way across industry channels, showcasing how much of a challenge securely configuring Kubernetes can be.

The vulnerabilities, tracked as CVE-2023-5043, CVE-2023-5044 and CVE-2022-4886, were disclosed on October 27, and are listed as currently awaiting triage. It’s unclear if any of the flaws have been exploited.

The vulnerabilities themselves abuse improper input validations, thus granting the ability to inject arbitrary code into the stream. Worse, an attacker can actually steal all secrets stored on a cluster without any proper security compliance or governance mechanisms in place.

This is the same pattern as CVE-2021-25742, where snippet annotations exposed cluster secrets, and it came up again with CVE-2024-7646.

How does Kyverno block CVE-2023-5043 and CVE-2023-5044?

This is where the power of Kyverno, created here at Nirmata and donated to the CNCF, begins to shine. With a simple, easy-to-read, and understandable policy, we can completely mitigate the effect of these CVEs without leaving our “everything-as-code” cloud-native loop.

By creating a simple policy declaration and applying it to a cluster running Kyverno as an admission controller, we can effectively mitigate and remediate any resources that could be affected by preventing the offending annotations from being used:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-annotations
  annotations:
    policies.kyverno.io/title: Restrict Nginx Annotations
    policies.kyverno.io/description: >-
      Prevent the nginx-related CVE-2023-5043 and CVE-2023-5044 by blocking configuration-snippet and permanent-redirect
    pod-policies.kyverno.io/autogen-controllers: none
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: block-nginx-annotations
    match:
      any:
      - resources:
          kinds:
          - Ingress
    validate:
      message: Cannot use nginx.ingress.kubernetes.io annotations for configuration-snippet or permanent-redirect, remediating CVE-2023-5043 and CVE-2023-5044
      pattern:
        metadata:
          =(annotations):
            X(nginx.ingress.kubernetes.io/configuration-snippet): "*" # CVE-2023-5043
            X(nginx.ingress.kubernetes.io/permanent-redirect): "*" # CVE-2023-5044

How do you mitigate CVE-2022-4886?

The upstream mitigation, available from v1.8.0, is the strict-validate-path-type ConfigMap option. With it on, the admission webhook rejects Exact and Prefix paths unless they start with “/” and contain only alphanumeric characters, “-”, “_” and “/”. Paths with pathType: ImplementationSpecific skip that check, so the advisory recommends limiting that path type to trusted users.

In order to mitigate CVE-2022-4886, we would have to look at the problem more strategically and evaluate the pathTypes we are currently using and instead create a whitelist. A sample way of achieving this is below:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-ingress-path-type
spec:
  validationFailureAction: Enforce
  rules:
    - name: block-specific-path-types
      match:
        resources:
          kinds:
            - Ingress
      validate:
        message: "pathType '/{{request.object.spec.rules[].http.paths[].pathType}}' is not allowed in this namespace"
        deny:
          conditions:
            all:
              - key: "{{request.object.spec.rules[].http.paths[].pathType | [] }}"
                operator: AnyNotIn
                value: [ImplementationSpecific]

What should you do next?

Ultimately, any and all institutions should assume zero trust and work towards having the correct tools to allow them to rapidly mitigate emerging threats. They should also have the tools to build the hand-in-hand Security and governance that operating Kubernetes at scale demands.

Kyverno offers many other features to help automate security and compliance concerns. You can learn more about Kyverno at: https://kyverno.io.

For faster results, take a look at the Nirmata Control Hub trial which will allow you to simply drag and drop a policy such as the above and mitigate and bring into compliance all of your infrastructure from a single pane of glass.

For background on writing policies like these, see policy as code, Kyverno OSS and our Kyverno security advisories hub.

Frequently asked questions

How do I check whether my cluster runs ingress-nginx?

The Kubernetes advisories suggest running kubectl get po -n ingress-nginx. If no ingress-nginx pods come back and you haven't installed the controller in another namespace, these three CVEs don't apply to you. In a cluster that does run it, the most exposed setups are multi-tenant ones where non-admin users have permission to create Ingress objects.

Is upgrading to ingress-nginx v1.9.0 enough on its own?

No. The advisories list v1.9.0 as the version that allows mitigation for CVE-2023-5043 and CVE-2023-5044, and the mitigation is to start the controller with the --enable-annotation-validation flag, which enforces restrictions on what annotation fields may contain. For CVE-2022-4886, v1.8.0 adds the strict-validate-path-type ConfigMap option, which administrators should turn on.

Does the chrooted ingress-nginx controller change the risk?

Yes, partly. According to the advisories, if you run the chrooted controller image introduced in v1.2.0, an attacker can still execute commands but cannot extract the controller's credentials, so the High severity rating does not apply. The upstream mitigations are still worth applying, because command execution inside the controller remains possible.

Why do NVD and Kubernetes list different scores for these CVEs?

Kubernetes scored CVE-2023-5043 and CVE-2023-5044 at 7.6 and CVE-2022-4886 at 8.8. NVD's own analysis scored the first two at 8.8 and CVE-2022-4886 at 6.5. NVD shows both the reporting organization's score and its own, and analysts can weigh impact differently. All three are rated High by Kubernetes.