OVSwrap (CVE-2026-64531) local root exploit: mitigation for CloudLinux 9, 10, and CloudLinux for Ubuntu

📋 TL;DR — last updated September 14, 2026

OVSwrap (CVE-2026-64531) is a vulnerability in the Linux kernel’s Open vSwitch action validation that lets any local unprivileged user become root. It is an upstream kernel bug, so it reaches the whole EL9 and EL10 family and several Debian and Ubuntu releases, not CloudLinux alone. A working public exploit exists. NVD has not yet published a CVSS score; Ubuntu assesses it at CVSS 7.8 (High).

• Affected (CloudLinux): CloudLinux 9 on el9_7 and later, CloudLinux 10 on el10_1 and later, and CloudLinux for Ubuntu 22.04. Earlier el9_6 and el10_0 kernels are not affected. → Affected CloudLinux versions
• Am I exposed: only if the kernel is el9_7+ (CloudLinux 9) or el10_1+ (CloudLinux 10) and openvswitch.ko is present on disk. Both checks → 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: available since 13 August. Update and reboot. → Stream 1
• — Kernel patch, CloudLinux for Ubuntu 22.04: released by Canonical (USN-8643-1, 5.15.0-190.200). → Stream 2
• — KernelCare livepatch: in the main feed for CloudLinux 9, 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
• Why it matters: one compromised website on a shared server becomes root on the whole server. → Why this matters on a shared host
• 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

Rollout status is also tracked on the CloudLinux status page. Subscribe there for updates.

Asim Manizada disclosed OVSwrap (CVE-2026-64531) on the oss-security mailing list on July 28, together with a full write-up and a working exploit. It is a local privilege escalation in the Linux kernel’s Open vSwitch module. An unprivileged user on an affected server can become root: no sudo, no capabilities, and nothing an administrator has to do first.

The bug is in the Linux kernel itself, not in anything CloudLinux ships. It reaches the EL9 and EL10 families, which puts RHEL, AlmaLinux, Rocky and CloudLinux in the same position, along with several Debian and Ubuntu releases. This advisory covers the CloudLinux side of it. If you run other distributions next to your CloudLinux fleet, treat them as in scope and follow those vendors’ advisories.

On CloudLinux 9 and CloudLinux 10 a patched kernel is available. Both track AlmaLinux kernels directly, and AlmaLinux shipped the fix on 13 August 2026: kernel 5.14.0-687.38.1.el9_8 for AlmaLinux 9 and 6.12.0-211.46.1.el10_2 for AlmaLinux 10. Update and reboot. The mitigation below remains useful only where you cannot reboot yet.

“Local” here does not mean an employee or a customer you trust. On a shared server, the local user is whoever just got into one of the sites you host through an outdated plugin. OVSwrap is what turns that single-site problem into a whole-server problem.

A patched kernel is now available on every affected CloudLinux platform, and so is a KernelCare livepatch, in the main feed on all three. On a server running KernelCare this is already closed, with no reboot and no downtime for the sites it hosts. Everywhere else, update the kernel and reboot.

Affected CloudLinux versions

† CloudLinux 8 runs its own kernel line, separate from AlmaLinux 8. Our kernel team has finished the source review and confirmed the vulnerable code path is not present, which matches the earlier empirical result that the public exploit does not run against that kernel. This advisory previously listed CloudLinux 8 as under investigation and recommended the mitigation as a precaution. If you applied it there, you can remove it.

A KernelCare livepatch closes the vulnerability without a reboot on every affected version. See Stream 3 for current feed availability.

Am I exposed?

Two things have to be true for a server to be exposed: the kernel is in the affected range, and the openvswitch module is loadable on it. Check both.

1. Check the kernel version

uname -r

The elX_Y suffix is the part that matters:

• CloudLinux 9 is affected from el9_7 onward. el9_6 and earlier are not affected, and need no action.
• CloudLinux 10 is affected from el10_1 onward. el10_0 is not affected.

So a kernel ending .el9_7.x86_64 is in range, and one ending .el9_6.x86_64 is not. On CloudLinux for Ubuntu 22.04 the kernel comes from Canonical and carries no el suffix, so treat it as in range and go to the next check.

2. Check for the module

ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null

If it prints a path, openvswitch.ko is loadable on that server and an unprivileged user can make the kernel load it on demand. Apply the mitigation below.

If it prints nothing, the module is not present for your running kernel. A later kernel update can bring it back, so run the check again after you update.

Open vSwitch does not need to be configured, running, or in use for any of this. The exploit causes the module to load by itself.

Checking the package is not enough. openvswitch.ko is not always delivered by kernel-modules-extra, so rpm -q kernel-modules-extra can come back empty on a server that is fully exposed. On CloudLinux 10 that package is installed by default. On CloudLinux 9 it often is not, but the module still ships inside the main kernel-modules package. Check for the file, not the package.

Is there a mitigation?

Yes, and it is the recommended action right now on every affected server.

Block the module from loading

echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf

This takes effect immediately, needs no reboot, and touches nothing else on the server.

Use install openvswitch /bin/false rather than blacklist openvswitch. A blacklist only prevents autoloading through /etc/modules-load.d/, udev, and hotplug. It does not block the kernel-side request_module() call that an unprivileged netlink probe triggers, which is exactly the path this exploit uses. The install line replaces the modprobe command for this module with /bin/false, so every load attempt fails, whether it comes from root, from an unprivileged trigger, or from the kernel itself.

If the module is already loaded on a server that does not use it, unload it as well:

lsmod | grep -E '^openvswitch'
modprobe -r openvswitch

Confirm the block is working:

modprobe openvswitch      # should fail
lsmod | grep openvswitch  # should print nothing

Compatibility. Do not apply this on a server that genuinely runs Open vSwitch: OVN and OpenStack Neutron compute or network nodes, some Kubernetes network plugins such as ovn-kubernetes and Antrea, and libvirt or oVirt setups with OVS-backed bridges. On those servers, use the second layer below or wait for the livepatch. On most hosting servers this is safe.

Once a fixed kernel or the livepatch is in place, revert with:

rm /etc/modprobe.d/ovswrap.conf

Second layer: disable unprivileged user namespaces

The exploit reaches CAP_NET_ADMIN by entering a private user and network namespace. Denying unprivileged user namespaces breaks that step regardless of module state. The setting differs by platform.

On CloudLinux 9 and 10:

sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/ovswrap.conf

On CloudLinux for Ubuntu 22.04:

sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' > /etc/sysctl.d/ovswrap.conf

On Ubuntu, note that apparmor_restrict_unprivileged_userns does not mitigate this. We tested it. Use the sysctl above, which removes the namespace outright.

Compatibility. This one is broader than the module block and it breaks things: rootless Docker and Podman, Kubernetes rootless mode, Snap and Flatpak sandboxing, and the Chromium and Firefox sandboxes all need unprivileged user namespaces. Typical hosting workloads do not. cPanel, Plesk and DirectAdmin stacks, the PHP, Node.js, Python and Ruby selectors, and ordinary customer sites are unaffected by this change.

The module block is sufficient on its own. Add this second layer only if you want the extra depth, or if you run Open vSwitch legitimately and cannot block the module.

Update instructions

Stream 1: AlmaLinux kernel (CloudLinux 9 and CloudLinux 10)

Update: September 14, 2026.

Patched AlmaLinux kernels are available. AlmaLinux 9 carries the fix in kernel 5.14.0-687.38.1.el9_8 (ALSA-2026:53329) and AlmaLinux 10 in kernel 6.12.0-211.46.1.el10_2 (ALSA-2026:53330), both rebuilt from Red Hat’s errata of 11 August. So the fix actually landed in the 9.8 and 10.2 streams.

Status: July 30, 2026, 15:00 UTC.

No patched AlmaLinux kernel is available. CloudLinux 9 and CloudLinux 10 track AlmaLinux kernels directly, and the fix is expected in the AlmaLinux 9.9 and 10.3 kernel streams or later, on Red Hat’s release schedule. We do not have a target date.

The fixed kernels are in the production repositories. The standard update path applies:

dnf update 'kernel*'
reboot

Where you cannot reboot yet, the mitigation and the KernelCare livepatch both hold the server until you can.

Stream 2: Ubuntu kernel (CloudLinux for Ubuntu 22.04)

Update: September 2, 2026, 14:00 UTC.

Canonical has released the fixed kernel for Ubuntu 22.04: linux 5.15.0-190.200 or newer, published August 18, 2026 as USN-8643-1. The standard update path below installs it.

Status: July 30, 2026, 15:00 UTC.

CloudLinux for Ubuntu 22.04 runs the stock Ubuntu kernel, so this fix comes from Canonical rather than from CloudLinux.

Apply Canonical’s kernel updates:

apt update
apt upgrade
reboot

Until then, apply the mitigation or the KernelCare livepatch.

Stream 3: KernelCare livepatch

Update: August 4, 2026, 15:31 UTC.

KernelCare livepatches are now in the main feed for every affected CloudLinux platform: CloudLinux 9, CloudLinux 10, and CloudLinux for Ubuntu 22.04. Subscribed servers pick the patch up automatically on their next update cycle.

The livepatch applies the upstream fix to the running kernel, with no reboot and no maintenance window.

Subscribed servers receive it automatically on the next scheduled run. To pull it immediately:

kcarectl --update

Once the livepatch is in place, the module block is no longer needed on that server. See Is there a mitigation? for how to revert it.

How to verify you are patched

For the KernelCare livepatch:

kcarectl --patch-info | grep CVE-2026-64531

Use --patch-info for this. kcarectl --info does not list individual CVEs and will come back empty even on a patched server.

For a kernel update, compare uname -r against the target version in the relevant stream above.

For the mitigation:

modprobe openvswitch      # should fail
lsmod | grep openvswitch  # should print nothing

If you think a server was already exploited

Patching does not undo a compromise that already happened. The public exploit finishes by writing a rule into the sudoers configuration and opening a root shell, so an attacker who succeeded before you patched keeps a way back in.

On any server you have reason to suspect, audit /etc/sudoers and every file under /etc/sudoers.d/ for entries nobody on your team added, then check for unfamiliar accounts and SSH keys.

Why this matters on a shared host

The reason this one matters on a hosting server is that every step after the first is free.

1. A site gets compromised. An outdated plugin or CMS gives an attacker code execution as an unprivileged process, confined to one account.
2. The module loads itself. From that confined process, a single generic-netlink probe makes the kernel load openvswitch.ko. No sudo, no capabilities, no administrator involvement.
3. The attacker gets network admin rights in a private namespace. Entering a private user and network namespace grants CAP_NET_ADMIN inside it, which is enough to install Open vSwitch flows. The capability is never needed on the host itself.
4. The malformed flow escalates to root. The exploit installs a flow that trips the bug and walks the resulting memory access primitives up to a root shell.
5. Tenant boundaries stop applying. Root reaches every other account on that server: files, databases, credentials, and backups.

With the module blocked or the livepatch applied, step 2 fails and the chain stops there. A compromised website stays a compromised website. That is one account to clean up instead of a server to rebuild and a disclosure to write.

Technical details of the bug

Open vSwitch validates a flow’s action list before installing it. Nested actions, in particular the recursive OVS_ACTION_ATTR_CLONE wrapper, get expanded into an internal action stream that the kernel generates itself. Nothing checked that a single generated nested attribute still fits the 16-bit nla_len field, which tops out at 65,535 bytes.

Pack hundreds of small conntrack actions inside a CLONE wrapper and the generated stream runs past that limit. The oversized length is assigned into the 16-bit field and wraps to a small value. Validation passes.

The damage happens later. A subsequent dump or teardown walks a structurally different stream than the one that was validated: it trusts the wrapped length, resumes parsing partway into attacker-controlled bytes, and reads forged action headers planted there as though they were real actions.

From there the chain is short. Fake tunnel SET actions yield a kernel pointer leak and a kernel memory read. Tunnel-destination teardown yields a constrained write, specifically a targeted 32-bit reference-count decrement. The public exploit forks a helper process on the host before entering the namespace, uses that decrement to corrupt the helper’s credentials, writes a sudoers rule, and spawns a root shell.

No race condition is involved. The bug is a mismatch between what the kernel validated and what it parses afterwards.

Reaching it requires x86-64, an Open vSwitch datapath built with conntrack and FTP-helper support, and permission to create unprivileged namespaces.

Why kernel version numbers are a poor guide here

The unsafe assignment is roughly 13 years old. Older kernels carried a 32 KiB cap on the generated action stream that kept it out of reach, and that cap was removed in March 2025. Removing it is what turned a latent bug into an exploitable one.

Upstream, the affected window runs from 6.14 to 7.2-rc3, and the published stable ranges begin at 5.15.180. Distribution kernels carry backports, which scrambles that arithmetic completely: a CloudLinux 9 kernel numbered 5.14 is affected from el9_7 onward, while a CloudLinux 8 kernel numbered 4.18 is not affected at all. The affected list on this page comes from checking each kernel line individually, not from comparing version numbers against the upstream window. If you are assessing other systems, do the same.

References

• oss-security disclosure, Asim Manizada, July 28 2026: openwall.com
• Researcher write-up: heyitsas.im/posts/ovswrap
• Public proof-of-concept: manizada/OVSwrap
• Upstream fix: commit 3f1f75536668, “net: openvswitch: reject oversized nested action attrs”
• CVE record: CVE-2026-64531
• NVD entry: CVE-2026-64531
• CloudLinux status page: OVSwrap incident