Ingress-nginx CVE-2025-1974 and related vulnerabilities remediation

As reported in the Kubernetes.io blog, the Ingress-NGINX maintainers have released patches for a set of critical vulnerabilities:

These issues affect releases of Charmed Kubernetes, but do not affect Canonical Kubernetes, as it does not use the nginx-ingress component. MicroK8s deployments are only affected if the ingress-nginx add-on is manually enabled; default MicroK8s configurations are unaffected.

The most serious of these, CVE-2025-1974, has a CVSS score of 9.8 and allows any workload on the Pod network to exploit configuration injection vulnerabilities.

When combined with the other vulnerabilities disclosed, CVE-2025-1974 could allow an attacker with access to the internal Pod network to take control of a Kubernetes cluster. Our recommendation is that you follow the update steps below as soon as possible.

Affected upstream versions

The ingress-nginx component of Kubernetes is affected in all versions prior to the v1.11.5 and v1.12.1 upstream releases:

Package name Release Affected Versions
ingress-nginx < 1.11 no patch available, all versions affected
ingress-nginx 1.11 < 1.11.5
ingress-nginx 1.12 < 1.12.1

Affected Canonical releases

The ingress-nginx component of Kubernetes is included in the Charmed Kubernetes Worker charm. The MicroK8s snap includes the affected ingress-nginx component, but it is not enabled by default. The following table lists the available product versions, as well as those affected. Revisions with patches will be updated as they are released.

Product Channel Affected Revisions
Canonical Kubernetes 1.32 LTS Not affected
Charmed Kubernetes kubernetes-worker 1.32/stable Revision < 286 (released)
Charmed Kubernetes kubernetes-worker 1.31/stable Revision < 304 (released)
Charmed Kubernetes kubernetes-worker 1.30/stable Revision < 307 (released)
Charmed Kubernetes kubernetes-worker 1.29/stable Revision < 310 (released)
Charmed Kubernetes kubernetes-worker 1.28/stable Revision < 313 (released)
Charmed Kubernetes <= 1.27/stable Not maintained, all versions affected.
MicroK8s snap 1.32/stable Revisions < 7964 (released)
MicroK8s snap 1.31/stable Revisions < 7963 (released)
MicroK8s snap 1.30/stable Revisions < 7966 (released)
MicroK8s snap 1.29/stable Revisions < 7969 (released)
MicroK8s snap 1.28/stable Revisions < 7971 (released)
MicroK8s snap <= 1.27/stable Not maintained, all versions affected.

How to check if you are impacted

MicroK8s

You can verify the version of the MicroK8s snap using the following instructions:

snap list microk8s

If the snap version is affected, you can also check the version of the ingress-nginx image:

microk8s kubectl -n ingress get pod -o yaml -l name=nginx-ingress-microk8s | grep image: | uniq

If the ingress-nginx addon was not enabled, the output will be empty and the deployment is unaffected. Otherwise, the output should show the version and you can confirm if the version is impacted according to the table above listing affected upstream versions:

      image: registry.k8s.io/ingress-nginx/controller:v1.11.2

Charmed Kubernetes

You can verify the version of the deployed Charmed Kubernetes instance using the following instructions:

juju status

The output will contain the following table (possibly with different versions):

kubernetes-control-plane  1.32.3   active      1  kubernetes-control-plane  1.32/stable  567  yes      Ready
kubernetes-worker         1.32.3   active      1  kubernetes-worker         1.32/stable  274  yes      Ready	 

If the charm revision is affected, you can also check the ingress-nginx version:

kubectl get pods --all-namespaces -o jsonpath="{range .items[*]}{.spec.containers[*].image}{'\n'}{end}" | grep ingress-nginx | sort -u

The output should show the version and you can confirm if the version is impacted according to the table above listing affected upstream versions:

rocks.canonical.com:443/cdk/ingress-nginx/controller:v1.11.2

Canonical Kubernetes

No versions of Canonical Kubernetes are affected by this set of vulnerabilities, as Cilium is used instead of the nginx-ingress component.

How to address

Microk8s

The below commands will apply the MicroK8s updates.

# Obtain existing channel version
snap list microk8s

# Refresh the snap from the channel obtained in the previous step
# The first command is only necessary if snap auto-refresh has been disabled, but it’s okay to run either way.
sudo snap refresh microk8s --channel=<existing channel>
microk8s addons repo update core

# Force the new image to be used by the addon, by rolling out new pods and terminating the old ones
sudo microk8s kubectl set image --namespace ingress daemonset/nginx-ingress-microk8s-controller nginx-ingress-microk8s=registry.k8s.io/ingress-nginx/controller:$(sudo grep TAG= /var/snap/microk8s/common/addons/core/addons/ingress/enable | cut -d '"' -f2)

Charmed Kubernetes

You can update the Charmed Kubernetes installation by using the following commands:

# Obtain existing channel version
juju status

# Refresh the kubernetes-worker charm from the channel obtained in the previous step
juju refresh kubernetes-worker --channel=<existing channel>

References

1 Like

The following command seems to be required until the update reaches stable channels

sudo snap refresh microk8s --channel=1.xx/candidate

This doesn’t seem to be enough to get the update as this would only refresh available addons but not the installed ones. Checking the image version

kubectl -n ingress get pods -o json | jq -r '.items[].spec.containers[].image'

shows

registry.k8s.io/ingress-nginx/controller:v1.8.0

Hi @giner,

Please note that our recommendation is to only use the stable channels, especially for production use, while this command will change an installation to the candidate track.

Thank you for raising this issue, you are correct. The following command is necessary to roll out new pods with the updated image and terminate the old ones. I have updated the original post to reflect this.

microk8s kubectl set image --namespace ingress daemonset/nginx-ingress-microk8s-controller nginx-ingress-microk8s=registry.k8s.io/ingress-nginx/controller:$(grep TAG= /var/snap/microk8s/common/addons/core/addons/ingress/enable | cut -d '"' -f2)

Probably follow the set image with this to track the rollout?

microk8s kubectl rollout status -n ingress daemonset.apps/nginx-ingress-microk8s-controller

Hello @johnatswoop,

Yes you can use kubectl rollout status to track the rollout, a successful rollout will show:

sudo microk8s kubectl rollout status -n ingress daemonset.apps/nginx-ingress-microk8s-controller
Waiting for daemon set "nginx-ingress-microk8s-controller" rollout to finish: 0 of 1 updated pods are available...
daemon set "nginx-ingress-microk8s-controller" successfully rolled out

Best regards,
Louise