This article provides information and mitigation steps for the following vulnerabilities in Harvester:
CVE-2026-53359
important
On July 6, 2026, researcher Hyunwoo Kim (@v4bel) publicly disclosed Januscape, a vulnerability in the Linux kernel’s KVM/x86 memory-management code, which allows a malicious virtual machine to break out of the guest and run code as root on the host it runs on. On hosts where the KVM device node /dev/kvm is world-accessible, an unprivileged local user can exploit the vulnerability to crash the host.
All supported versions of Harvester are affected, including 1.6.1 and earlier, 1.7.2 and earlier, and 1.8.1 and earlier.
Januscape is the latest in a series of Linux kernel privilege-escalation vulnerabilities that required a patch and a reboot of the affected hosts.
SUSE is working on fixing this issue. Meanwhile, apply the mitigation steps described in this article to protect your clusters.
The mitigation steps involves disabling the nested virtualization feature of the KVM kernel module on your Harvester hosts.
note
Nested virtualization is not supported on virtual machines running on Harvester. Disabling this feature will not affect the functionality of your Harvester cluster.
On your Harvester hosts, use the following commands to confirm that the KVM kernel module is loaded with nested virtualization enabled:
Once the configuration is applied, reboot your Harvester hosts for the changes to take effect.
warning
Do not disable the KVM kernel module on your Harvester hosts, as it is required for running virtual machines. Only disable the nested virtualization feature using the configuration provided above.
Once you have upgraded to a fixed version of Harvester, you can re-enable the nested virtualization feature by deleting the CloudInit configuration and rebooting your Harvester hosts:
These vulnerabilities affect RKE2 ingress-nginx controller v1.14.5 and earlier. All Harvester versions that use this controller (including 1.5.2 and earlier, 1.6.1 and earlier, 1.7.1 and earlier, and 1.8.0) are therefore affected.
2026-05-15: Until Harvester 1.7.2 and 1.8.1 are released with the fixes, apply the mitigation steps below to secure your clusters.
You can confirm the version of the RKE2 ingress-nginx pods by running this command on your Harvester cluster:
kubectl -n kube-system get po -l"app.kubernetes.io/name=rke2-ingress-nginx" -ojsonpath='{.items[].spec.containers[].image}'
If the command returns one of the affected versions, perform the following mitigation steps.
The primary resolution is to upgrade Harvester to one of these versions:
1.7.2 or newer
1.8.1 or newer
If upgrade is not possible, apply the following mitigation to protect your clusters.
All ingress resources with the nginx.ingress.kubernetes.io/rewrite-target annotation containing ? in the annotation value are at risk.
By default, Harvester does not include any ingress resources with this annotation. Run the following command on your clusters to identify affected custom ingress resources:
Any ingress resources reported by the above command are vulnerable. They should be updated to either remove the vulnerable annotation or change the annotation value to not contain a question mark ?.
The following validating admission policy can be applied to your cluster to reject ingress resources with the vulnerable configuration:
cat<<EOF | kubectl apply -f - apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: ingress-nginx-annotation-validation-20260514 spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["networking.k8s.io"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["ingresses"] validations: - expression: | !has(object.metadata.annotations) || !object.metadata.annotations.exists(k, k == 'nginx.ingress.kubernetes.io/rewrite-target') || !object.metadata.annotations['nginx.ingress.kubernetes.io/rewrite-target'].contains('?') message: "Ingress resources with 'nginx.ingress.kubernetes.io/rewrite-target' annotation containing '?' in the annotation value are not allowed, due to the following CVEs: CVE-2026-42945, CVE-2026-42946, CVE-2026-40701, CVE-2026-42934" --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: ingress-nginx-annotation-validation-20260514 spec: policyName: ingress-nginx-annotation-validation-20260514 validationActions: [Deny] EOF
info
This policy is a cluster-scoped resource that requires the proper administrator RBAC permissions to create.
important
This validating policy prevents the inclusion of the vulnerable annotation configuration in new and existing ingress resources. However, it cannot detect or block any vulnerable ingress resources that already exist in the cluster. Therefore, it is important to follow the instructions described above to also identify and update any existing vulnerable ingress resources.
The policy can be removed once you upgrade to Harvester 1.7.2, 1.8.1 or newer:
You have lost the admin password for the Harvester GUI
The admin password for the Harvester GUI can be reset if you can still login via ssh as the rancher user, or if you have the Harvester cluster's kubeconfig file saved locally. For details, see How can I reset the administrator password? in the documentation.
You have lost the rancher user's ssh/console login password
But you still have the Harvester cluster's kubeconfig
The rancher user's ssh/console login password can be reset by creating a CloudInit CRD to update the password. For details, see Password of user rancher in the documentation. Alternately you can create additional users with ssh access as described in How to create an SSH user for Harvester nodes.
You don't have a kubeconfig, but do have physical or remote console access
In this case, the rancher user's ssh/console login password can be changed by editing /oem/90_custom.yaml on each host.
Boot the Harvester installer, but don't proceed with the regular installation process. Instead, once the installer comes up, press CTRL-ALT-F2 to switch to VT2 and login as the rancher user with password rancher. Then proceed with the following steps:
Run sudo -i to become root
Mount the COS_OEM partition from the host:
# mkdir /tmp/oem # mount -L COS_OEM /tmp/oem
Run vim /tmp/oem/90_custom.yaml to edit 90_custom.yaml and change the password for the rancher user. You can specify either a plaintext password (not recommended) or a password hash generated with e.g. openssl passwd -6. Following is the section that you need to edit:
users: rancher: passwd: <PASSWORD_GOES_HERE>
Reboot the host. You should now be able to log in as the rancher user with the new password.
You can't boot the Harvester installer ISO, but can still reboot the host and access the boot menu
If you have no other option, then during system boot, edit the grub config and add rd.break at the end of the kernel command line (the one that starts with linux). This will drop you into the dracut emergency shell, with the root partition mounted under /sysroot. Unfortunately, this shell does not contain any text editor programs. Trying to edit /oem/90_custom.yaml under the circumstances would be unwise. Instead though, you can run this command:
# sed -i 's%rancher.*%rancher:$6$j0.h3TQv8RZPHJkB$3SbV978JLT2Qeq4KSCBZitErNlZZGfrDxnGW5HS0wHzWexGyPzeQBoQmQJetUhLFfquv/X5VWL6odxtlEec1u/:20468::::::%' /sysroot/etc/shadow
Then, hit CTRL-D to continue, and once the system finishes booting, the rancher user's password will be set back to rancherfor this boot only. You can then login on the console and use vim to update /oem/90_custom.yaml and permanently set the password to something more secure as described in the previous section.
These vulnerabilities affect specific versions of the RKE2 ingress-nginx controller (v1.13.7 and earlier, v1.14.3 and earlier). All Harvester versions that use this controller (including 1.5.2 and earlier, 1.6.1 and earlier, and 1.7.0) are therefore affected.
These CVEs are fixed in Harvester 1.7.1 and newer.
important
Harvester does not utilize the ingress-nginx controller custom error backend. Therefore, it is not affected by CVE-2026-24513.
important
Currently, no mitigation is available for CVE-2026-24514. An upgrade to Harvester 1.7.1 is required.
You can confirm the version of the RKE2 ingress-nginx pods by running this command on your Harvester cluster:
kubectl -n kube-system get po -l"app.kubernetes.io/name=rke2-ingress-nginx" -ojsonpath='{.items[].spec.containers[].image}'
If the command returns one of the affected versions, perform one of the following mitigation steps.
The primary resolution is to upgrade to Harvester 1.7.1 or newer, which includes the fixed RKE2 ingress-nginx controller.
If upgrade is not possible, deploy the following validating admission policy to your cluster to reject ingress resources with the vulnerable configuration:
cat<<EOF | kubectl apply -f - apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: ingress-nginx-annotation-validation spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["networking.k8s.io"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["ingresses"] validations: - expression: | !('nginx.ingress.kubernetes.io/auth-proxy-set-headers' in object.metadata.annotations) && !('nginx.ingress.kubernetes.io/auth-method' in object.metadata.annotations) && (object.spec.rules.all(rule, rule.http.paths.all(path, path.pathType != 'ImplementationSpecific'))) message: "Ingress resources with the vulnerable annotations are not allowed. Please remove the 'nginx.ingress.kubernetes.io/auth-proxy-set-headers' and 'nginx.ingress.kubernetes.io/auth-method' annotations, and avoid using the 'ImplementationSpecific' path type." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: ingress-nginx-annotation-validation spec: policyName: ingress-nginx-annotation-validation validationActions: [Deny] EOF
info
This policy is a cluster-scoped resource that requires the proper administrator RBAC permissions to create.
This validating policy rejects any ingress resources that contain the:
Users wishing to prevent privilege escalation and other security issues can leverage Kubernetes' Pod Security Standards (PSS) on Harvester. PSS are a set of security policies that can be applied to clusters and namespaces to control and restrict how workloads are executed.
Pod Security Standards in Harvester can be used when provisioning VM workloads and also with the new experimental support for running baremetal container workloads.
The baseline policy is aimed at ease of adoption for common containerized workloads while preventing known privilege escalations. This policy is targeted at application operators and developers of non-critical applications.
warning
VMs with device passthrough, such as pcidevices, usbdevices and vgpudevices, will fail to start with baseline policy, as they need SYS_RESOURCE capability. This is being tracked on issue #8218. A fix should be available for this shortly.
Do not apply PSS to the system's namespaces, as they need privileged permissions to manage cluster resources. Only trusted users must have access to system's namespaces.
Cluster wide PSS can be enabled by passing an Admission Control configuration via kube-apiserver arguments. This can be done via Harvester's CloudInit using the following configuration which can be saved to cloudinit-pss.yaml file:
The cluster admin can apply this against the Harvester cluster using kubectl apply -f cloudinit-pss.yaml. The change requires a restart of the control plane nodes to ensure that the Elemental cloud-init directives are applied on boot. Once control plane nodes are rebooted, a default baseline pod security standard will be enforced against all current and subsequently created namespaces. The namespaces listed under exemptions will be skipped. Users are free to tweak the list, to better suit their use cases.
For future integration of Pod Security Admission (PSA) configuration natively in Harvester, please verify the progress of issue #8196.
Post application of a default PSS, end users, with permissions to create and edit namespaces, may still be able to override the respective policy by labeling their namespaces to support privileged workloads, for example, as follows:
To avoid this, we recommend users to create custom RBACs restricting who can create/update namespaces or to also deploy a Validating Admission Policy. The following policy will block namespace create/update requests containing a label pod-security.kubernetes.io/enforce, there by preventing namespace admins from changing the settings for their namespace.
In case more tailored policies are needed, users can rely on security policy engines like Kubewarden's policy PSA Label Enforcer, or similar solution, to ensure that namespaces have the required PSS configuration for deployment in the cluster.
CVE-2025-1974 (vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) has a score of 9.8 (Critical).
The vulnerability affects specific versions of the RKE2 ingress-nginx controller (v.1.11.4 and earlier, and v1.12.0). All Harvester versions that use this controller (including v1.4.2 and earlier) are therefore affected.
This CVE is fixed in Harvester 1.5.0, 1.4.3 and newer.
A security issue was discovered in Kubernetes where under certain conditions, an unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of secrets accessible to the controller. (Note that in the default installation, the controller can access all secrets cluster-wide.)
You can confirm the version of the RKE2 ingress-nginx pods by running this command on your Harvester cluster:
kubectl -n kube-system get po -l"app.kubernetes.io/name=rke2-ingress-nginx" -ojsonpath='{.items[].spec.containers[].image}'
If the command returns one of the affected versions, disable the rke2-ingress-nginx-admission validating webhook configuration by performing the following steps:
On one of your control plane nodes, use kubectl to confirm the existence of the HelmChartConfig resource named rke2-ingress-nginx:
$ kubectl -n kube-system get helmchartconfig rke2-ingress-nginx NAME AGE rke2-ingress-nginx 14d1h
Use kubectl -n kube-system edit helmchartconfig rke2-ingress-nginx to add the following configurations to the resource:
The following is an example of what the updated .spec.valuesContent configuration along with the default Harvester ingress-nginx configuration should look like:
Exit the kubectl edit command execution to save the configuration.
Harvester automatically applies the change once the content is saved.
important
The configuration disables the RKE2 ingress-nginx admission webhooks while preserving Harvester's default ingress-nginx configuration.
If the HelmChartConfig resource contains other custom ingress-nginx configuration, you must retain them when editing the resource.
Verify that RKE2 deleted the rke2-ingress-nginx-admission validating webhook configuration.
$ kubectl get validatingwebhookconfiguration rke2-ingress-nginx-admission Error from server (NotFound): validatingwebhookconfigurations.admissionregistration.k8s.io "rke2-ingress-nginx-admission" not found
Verify that the ingress-nginx pods are restarted successfully.
$ kubectl -n kube-system get po -lapp.kubernetes.io/instance=rke2-ingress-nginx NAME READY STATUS RESTARTS AGE rke2-ingress-nginx-controller-g8l49 1/1 Running 0 5s
Once your Harvester cluster receives the RKE2 ingress-nginx patch, you can re-install the rke2-ingress-nginx-admission validating webhook configuration by removing the HelmChartConfig patch.
important
These steps only cover the RKE2 ingress-nginx controller that is managed by Harvester. You must also update other running ingress-nginx controllers. See the References section for more information.
Harvester does not allow you to change the cluster token even if RKE2 is a core component of Harvester.
The RKE2 documentation states that the November 2023 releases of RKE2 (v1.28.3+rke2r2, v1.27.7+rke2r2, v1.26.10+rke2r2, and v1.25.15+rke2r2) allow you to rotate the cluster token using the command rke2 token rotate --token original --new-token new.
During testing, the command was run on the first node of a cluster running Harvester v1.3.0 with RKE2 v1.27.10+rke2r1.
Rotate the token on initial node.
/opt/rke2/bin $ ./rke2 token rotate --token rancher --new-token rancher1 WARNING: Recommended to keep a record of the old token. If restoring from a snapshot, you must use the token associated with that snapshot. WARN[0000] Cluster CA certificate is not trusted by the host CA bundle, but the token does not include a CA hash. Use the full token from the server's node-token file to enable Cluster CA validation. Token rotated, restart rke2 nodes with new token
When the first cluster node was rebooted, RKE2 service was unable to start.
RKE2 log: ... May 29 15:45:11 harv41 rke2[3293]: time="2024-05-29T15:45:11Z" level=info msg="etcd temporary data store connection OK" May 29 15:45:11 harv41 rke2[3293]: time="2024-05-29T15:45:11Z" level=info msg="Reconciling bootstrap data between datastore and disk" May 29 15:45:11 harv41 rke2[3293]: time="2024-05-29T15:45:11Z" level=fatal msg="Failed to reconcile with temporary etcd: bootstrap data already found and encrypted with different token" May 29 15:45:11 harv41 systemd[1]: rke2-server.service: Main process exited, code=exited, status=1/FAILURE ...
Do not attempt to rotate the RKE2 token on your cluster before Harvester announces official support for this feature (even if the embedded RKE2 binary has the token rotate option).
Harvester has a webhook that checks this setting to ensure it meets all conditions, e.g. the internal IPs and CIDRs are specified in the noProxy field.
note
Avoid changing the HTTP proxy from files in the host /oem path for the following reasons:
You must manually change the HTTP proxy on each node.
Contents of local files are not automatically populated to new nodes.
Without help from the webhook, some erroneous configurations may not be promptly detected (see Node IP should be in noProxy).
Harvester may change the file naming or content structure in the future.
Harvester is built on top of Kubernetes, RKE2, and Rancher. RKE2 generates a list of *.crt and *.key files that allow Kubernetes components to function. The *.crt file expires after one year by default.
$ ls /var/lib/rancher/rke2/server/tls/ -alth ... -rw-r--r-- 1 root root 570 May 27 08:45 server-ca.nochain.crt -rw------- 1 root root 1.7K May 27 08:45 service.current.key -rw-r--r-- 1 root root 574 May 27 08:45 client-ca.nochain.crt drwxr-xr-x 2 root root 4.0K May 13 20:45 kube-controller-manager drwxr-xr-x 2 root root 4.0K May 13 20:45 kube-scheduler drwx------ 6 root root 4.0K May 13 20:45 . drwx------ 8 root root 4.0K May 13 20:45 .. -rw-r--r-- 1 root root 3.9K May 13 20:40 dynamic-cert.json drwx------ 2 root root 4.0K May 13 20:39 temporary-certs -rw------- 1 root root 1.7K May 13 20:39 service.key -rw-r--r-- 1 root root 1.2K May 13 20:39 client-auth-proxy.crt -rw------- 1 root root 227 May 13 20:39 client-auth-proxy.key -rw-r--r-- 1 root root 1.2K May 13 20:39 client-rke2-cloud-controller.crt ... -rw-r--r-- 1 root root 1.2K May 13 20:39 client-admin.crt -rw------- 1 root root 227 May 13 20:39 client-admin.key ... $ openssl x509 -enddate -noout -in /var/lib/rancher/rke2/server/tls/client-admin.crt notAfter=May 13 20:39:42 2025 GMT
When a cluster has been running for over one year, Kubernetes components may fail to start after upgrades or node rebooting. The workaround is to delete the related files and restart the pod.
Harvester v1.3.0 added the setting auto-rotate-rke2-certs, which allows you to set the Harvester cluster to automatically rotate certificates for RKE2 services. When you enable the setting and specify a certificate validity period, Harvester automatically replaces the certificate before the specified period ends.
note
Enabling this setting on your cluster is highly recommended.
