Who is actually affected. Two things have to be true at once. 1) The kernel: el9_7 or newer on CloudLinux 9, el10_1 or newer on CloudLinux 10. Older kernels are not affected, so el9_6 and below and el10_0 are clear. 2) The module has to be on disk. Check the kernel: uname -r Then check the module: ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null If either check comes back clear, you have nothing to do.
Not affected, nothing to do. CloudLinux 7, CloudLinux 7 Hybrid, CloudLinux 8 LTS, CloudLinux 9 LTS.
CloudLinux 8 is still under investigation. Its kernel is a separate line from AlmaLinux 8 and the public exploit does not work against it. Apply the mitigation there anyway, as a precaution.
Extra layer, optional. The exploit needs a private user namespace to get CAP_NET_ADMIN. Take that away and it fails even if the module loads.
On CloudLinux 8, 9 and 10: sysctl -w user.max_user_namespaces=0 On CloudLinux for Ubuntu 22.04: sysctl -w kernel.unprivileged_userns_clone=0 To keep it after a reboot, write the same setting into /etc/sysctl.d/ovswrap.conf.
On Ubuntu, apparmor_restrict_unprivileged_userns does not help here. We tested it.
This layer does break things: rootless Docker and Podman, Snap and Flatpak sandboxes. Normal hosting is fine, so cPanel, Plesk, DirectAdmin and the language selectors are not affected. Skip this step unless you run Open vSwitch on purpose and cannot block the module.
Fix status. There is no patched AlmaLinux kernel for CloudLinux 9 or CloudLinux 10 yet. The fix should land in the AlmaLinux 9.9 and 10.3 kernels, and those follow Red Hat's schedule, so we cannot give you a date. CloudLinux for Ubuntu 22.04 gets its kernel from Canonical.
KernelCare patches for EL9 are out: - CloudLinux 9 and AlmaLinux 9: K20260730_03 - RHEL 9: K20260730_01 - Rocky Linux 9: K20260730_08 - Oracle Linux 9: K20260730_06 The CloudLinux 9 patch sits in the testing feed. Take it now: kcarectl --update --prefix test EL10 patches are still being built, and CloudLinux for Ubuntu 22.04 is in preparation.
If you think a server was already hit. Patching now does not undo it. The public exploit ends by adding a sudoers rule and opening a root shell, so whoever got in keeps a way back. Check /etc/sudoers and every file in /etc/sudoers.d/ for entries your team did not add. Then look for accounts and SSH keys you do not recognize.
How to check you are covered. For the livepatch: kcarectl --patch-info | grep CVE-2026-64531 Use --patch-info, not --info. The --info form prints nothing about single CVEs even on a patched server. For the kernel, compare uname -r against the target version once one exists. Full detail in the blog post.
Posted Jul 31, 2026 - 12:47 UTC
Update
We published the mitigation command with the wrong kind of quote marks. If you copied it from this page, the line in your config file is broken, the kernel ignored it, and the module was never blocked. The command is fixed now, but your server stays exposed until you redo it.
Fix it in three steps.
1. Look at the file: cat -A /etc/modprobe.d/ovswrap.conf It must hold exactly one line, install openvswitch /bin/false$. The $ is just the end of the line, cat -A adds it. Anything else on that line and the module is not blocked.
3. Test it. This command must fail: modprobe openvswitch And this one must print nothing: lsmod | grep openvswitch
If step 3 prints a line, the module is already loaded. Unload it: modprobe -r openvswitch.
Posted Jul 31, 2026 - 12:29 UTC
Update
* KernelCare patchsets for EL9: K20260730_03: CL9 / AlmaLinux 9 K20260730_01: RHEL 9 K20260730_08: RockyLinux 9 K20260730_06: Oracle Linux 9
* KernelCare patchsets for EL10 are in progress.
Posted Jul 30, 2026 - 18:13 UTC
Identified
OVSwrap (CVE-2026-64531) is a vulnerability in the Linux kernel’s Open vSwitch action validation that lets any local unprivileged user become root. A working public exploit exists. No CVSS score has been published yet.
Affected: CloudLinux 9, CloudLinux 10, and CloudLinux for Ubuntu 22.04. CloudLinux 8 is under investigation. → Affected CloudLinux versions
Am I exposed: run ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null. If it prints a path, yes. → Am I exposed?
Mitigation: one line, no reboot: echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf → Is there a mitigation?
Fix status: Kernel patch, CloudLinux 9 and CloudLinux 10: no patched AlmaLinux kernel yet. → Stream 1 Kernel patch, CloudLinux for Ubuntu 22.04: arrives from Canonical. → Stream 2 KernelCare livepatch: available in the testing feed for CloudLinux 9. In preparation for CloudLinux 10 and CloudLinux for Ubuntu 22.04. → Stream 3
Verify:kcarectl --patch-info | grep CVE-2026-64531 for the livepatch, uname -r for the kernel. → How to verify you are patched
How the bug works: oversized nested actions wrap a 16-bit length field, so the kernel later parses attacker-controlled bytes as real instructions. → Technical details of the bug