CVE-2026-64531: A 13-Year-Old Linux Kernel Flaw Lets Local Users Gain Root via Open vSwitch (OVSwrap)

OVSwrap is a local privilege escalation vulnerability caused by an integer wraparound in how the Linux kernel's Open vSwitch datapath generates internal Netlink action attributes. An unprivileged local user, with no existing OVS bridge, no running ovs-vswitchd daemon, and no host-level CAP_NET_ADMIN, can trigger a deterministic memory corruption path and escalate to root. A public, destructive proof-of-concept is available, shipping with pre-built exploitation records for roughly 800 distinct x86-64 kernel builds and confirmed default-configuration exploitation across a wide range of major Linux distributions.

Overview

Exploit Maturity Assessment

A fully functional, publicly released proof-of-concept exists and has been demonstrated by the researcher against default configurations of numerous mainstream distributions. The researcher has described the underlying bug as having logic-bug-grade reliability rather than the unpredictable behavior typical of heap-based exploits, since the corruption lands at a deterministic point inside a contiguous, attacker-controlled buffer with no heap grooming required. No confirmed in-the-wild exploitation or threat actor activity has been reported as of this writing, but the combination of public exploit code and broad default-configuration applicability makes this a high-priority patch target.

Factor	Assessment
Exploit Status	Functional, publicly released proof-of-concept; no confirmed in-the-wild exploitation reported
Exploit Availability	Public
Source of Exploit	Researcher-published code repository, accompanied by a technical write-up on the researcher's own site
Exploit Reliability	High. The researcher describes the memory corruption as deterministic rather than dependent on heap grooming or timing.

Proof of Concept

The researcher has published the proof-of-concept exploit code along with a detailed technical write-up explaining the vulnerability and the exploitation chain. It requires OVS conntrack support, the FTP conntrack helper, and sudo to be present on the target system. On success, it corrupts a live kernel credential structure, modifies /etc/sudoers.d or /etc/sudoers, and opens a root shell. The released code is explicitly destructive and intentionally leaves processes and OVS state behind afterward to avoid an unsafe teardown sequence, so it should never be run against a production system.

The published code includes exploitation records for approximately 800 exact x86-64 kernel builds, and attempts dynamic derivation from kernel symbols or BTF data for builds it does not already have on file, meaning its practical reach extends well beyond the 800 pre-verified builds.

Reproducibility

The exploit can be built and run using the information the researcher has published, since the full proof-of-concept source, the kernel build database, and a detailed technical write-up are all public. Required prerequisites include a vulnerable, unpatched kernel with the Open vSwitch module available, OVS conntrack support with the FTP helper enabled, sudo installed, and unprivileged user namespaces permitted on the target system. At a high level, the exploit creates a private user and network namespace using unshare -Urn, gains CAP_NET_ADMIN inside that namespace, submits a crafted CLONE action packed with hundreds of conntrack sub-actions to overflow the 16-bit Netlink length field, and then uses the resulting wraparound to chain a kernel pointer leak, an arbitrary kernel read, and a targeted memory decrement that zeroes out the calling process's fsuid and fsgid on modern kernels.

Time-to-Exploit Analysis

Metric	Assessment
Time from Disclosure → PoC Release	0 days. The proof-of-concept was released alongside public disclosure on July 28, 2026.
Time from Disclosure → Active Exploitation	Not observed as of this writing.
Time from Patch → Exploit in Wild	The upstream patch (July 24, 2026) preceded public disclosure and PoC release by 4 days. No in-the-wild exploitation has been observed since.
Risk Interpretation	Immediate (0–2 days). A fully weaponized, publicly available exploit exists with confirmed default-configuration exploitation across a wide range of distributions, so unpatched systems exposing the OVS kernel module to local users should be treated as an immediate risk rather than a theoretical one.

Active Exploitation & Threat Actors

Exploitation Observed in the Wild: No.

Associated Threat Actors: None identified. No APT groups, ransomware operators, or initial access brokers have been publicly linked to CVE-2026-64531, and it has not been added to CISA's Known Exploited Vulnerabilities catalog.

Campaign Details: N/A — no campaign activity has been reported.

Attack Techniques Observed: N/A — no in-the-wild attack techniques have been documented.

The primary concern flagged by CloudLinux's advisory on this vulnerability is architectural rather than campaign-specific: in multi-tenant or shared hosting environments, a local user account does not need to belong to a trusted party. It can just as easily be an attacker who already gained a foothold on the system through an unrelated vulnerability, and OVSwrap is what converts that single-account compromise into control of the entire server.

Vulnerability Timeline

Event	Date
Vulnerability Discovered	Reported June 19, 2026 (earlier internal discovery date not disclosed)
Vendor Notified	June 19, 2026 (security@kernel.org and Open vSwitch maintainers)
Public Disclosure	July 28, 2026
PoC Released	July 28, 2026 (alongside public disclosure)
Exploitation in Wild Began	Not observed as of publication
Patch Released	July 24, 2026 (upstream stable trees)

Note: the underlying 16-bit length-field bug has existed upstream for roughly 13 years, and became exploitable only after a March 2025 change removed a 32 KiB cap on generated action streams. See Root Cause Analysis below for detail on that history.

Root Cause Analysis

Open vSwitch stores the flow actions it generates internally as Netlink attributes, and each nested attribute carries a length field, nla_len, that is only 16 bits wide, capping any single nested attribute at 65,535 bytes. That constraint on individual nested attributes had technically been unsafe for around 13 years, but a separate 32 KiB cap on the total size of the generated action stream had always kept any single nested attribute well below the point where it could wrap.

In March 2025, an upstream change removed that overall 32 KiB cap because it was producing unpredictable failures, including in large OpenStack deployments. That change allowed the total generated action stream to legitimately exceed 64 KiB, but in doing so it also removed the safety margin that had been masking the older, narrower bug in the 16-bit length field. The discussion around that change focused on reliability and user-facing failures and did not identify the security consequence of removing the guard.

With the cap gone, an attacker can submit a CLONE action packed with hundreds of conntrack sub-actions. On x86-64 systems, the kernel expands each sub-action to 164 bytes, so a sufficiently large number of them pushes the resulting nested action past the 65,535-byte limit. When OVS writes that oversized length into the 16-bit field, the value wraps around to a small number. Later code trusts that wrapped length and resumes parsing from a point inside what is actually attacker-controlled conntrack data, where forged OVS actions are already positioned and waiting to be interpreted as legitimate kernel structures.

How CVE-2026-64531 Can Be Exploited

Exploitation does not require any pre-existing Open vSwitch configuration. An attacker needs no OVS bridge, no running ovs-vswitchd daemon, and no host-level CAP_NET_ADMIN to begin with. On a system where the OVS kernel datapath is available and unprivileged user namespaces are enabled, which is the default on many distributions, an ordinary local user can create a private user and network namespace with unshare -Urn and obtain CAP_NET_ADMIN inside that namespace, which is sufficient to reach the vulnerable flow-installation code path.

Notably, if the openvswitch kernel module is present on disk but not currently loaded, simply resolving its Generic Netlink family name is enough to trigger the kernel to auto-load it. This means an administrator checking lsmod and finding no OVS module loaded cannot conclude the system is safe, since the module can be pulled into memory on demand by the same low-privileged user attempting exploitation.

Once inside the crafted namespace, the attacker submits the oversized CLONE action described above to trigger the length-field wraparound, then chains three primitives to reach root: a kernel pointer leak through a fake OUTPUT action, an arbitrary kernel read through a forged tunnel SET action, and a targeted memory decrement through the teardown of a forged tun_dst pointer. These are used together to locate the calling process's kernel credential structure and, on modern kernels, decrement its fsuid and fsgid fields to zero, granting root privileges.

Affected Versions

The vulnerability affects Linux kernel builds containing the Open vSwitch datapath code prior to the fix, across the actively maintained stable series. Fixed upstream releases are 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5. The 6.13 through 6.17, 6.19, and 7.0 kernel series have reached end of life and will not receive an upstream stable backport, so systems still running those series should be prioritized for a full kernel upgrade rather than a point patch.

Upstream version numbers alone are not sufficient to determine exposure, since distribution kernels carry their own backports and downstream modifications. Distributions including Debian maintain independent security trackers for this CVE, and administrators should confirm patch status against their specific vendor's advisory rather than assuming a match based on upstream version numbers. As one example, CloudLinux has reported that CloudLinux OS 9 (el9_7 and later) and CloudLinux OS 10 (el10_1 and later), along with AlmaLinux 9 and 10 and other Enterprise Linux 9 and 10 systems on the same kernel code, are affected, while CloudLinux OS 7, 7h, and 8 are not affected because their kernels fall outside the vulnerable range. CloudLinux's kernel team has completed its source review and confirmed that CloudLinux OS 8 is not affected, matching the earlier empirical proof-of-concept result. As of CloudLinux's most recent published update, no patched AlmaLinux-derived kernel was yet available for CloudLinux 9 or 10; the fix is expected in the AlmaLinux 9.9 and 10.3 kernel streams, following Red Hat's own release schedule. In the meantime, CloudLinux has shipped KernelCare live patches as a no-reboot interim fix, now available in the main feed for all three affected CloudLinux platforms: CloudLinux 9, CloudLinux 10, and CloudLinux for Ubuntu 22.04.

The researcher's own non-exhaustive test matrix confirmed default-configuration exploitation on AlmaLinux 9 and 10, Alpine 3.22 through 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 and 10, Debian 12 and 13, Fedora 42 through 44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 and 10, and Ubuntu 22.04. On tested Ubuntu 24.04 systems, AppArmor blocked direct namespace creation by default, but the proof-of-concept's aa-exec -p trinity fallback restored the exploitation path. Stock Ubuntu 26.04 blocked the ordinary-user route entirely through its AppArmor user-namespace restriction, though disabling that restriction made tested systems exploitable again. Tested Amazon Linux 2, Debian 11, openSUSE Leap 16.0, Rocky Linux 8, Ubuntu 18.04, and Ubuntu 20.04 retained older code paths and were not exploitable through this particular route.

Impact

Successful exploitation grants an unprivileged local user full root access on the affected system, with no host-level networking privileges required beforehand.

1. 1. Complete privilege escalation from an unprivileged local account to root, using only default namespace and Open vSwitch configuration present on many distributions.
2. 2. Modification of /etc/sudoers or /etc/sudoers.d, as demonstrated by the public proof-of-concept, to establish a persistent path to elevated privileges.
3. 3. Full compromise of multi-tenant or shared-hosting systems, where any local account, including one obtained through an unrelated compromise, can be escalated to control of the entire host.
4. 4. Corruption of live kernel credential structures, which can leave systems in an unstable or difficult-to-forensically-analyze state, since the public proof-of-concept deliberately avoids a clean teardown.

Post-Exploitation Details

Successful exploitation directly results in privilege escalation to root, which is the core outcome of the vulnerability rather than a secondary consequence. Lateral movement is a realistic follow-on risk in shared or multi-tenant environments, since root access on a shared host can expose every other tenant or workload running on that system. The public proof-of-concept establishes a form of persistence by modifying /etc/sudoers or /etc/sudoers.d directly, giving the attacker a durable path back to elevated privileges beyond the initial exploitation session. No data exfiltration, command-and-control communication, or credential harvesting behavior has been documented in connection with this vulnerability, since it is a local privilege escalation bug rather than a network-facing or remote access flaw.

MITRE ATT&CK Mapping

Tactic	Technique	ID
Initial Access	N/A — this is a local privilege escalation flaw with no initial-access vector of its own; an attacker must already hold local account access before OVSwrap applies	—
Execution	N/A — no arbitrary code execution technique has been documented beyond the exploit's own kernel-level primitive chain	—
Privilege Escalation	Exploitation for Privilege Escalation, via the Open vSwitch kernel datapath memory corruption	T1068
Privilege Escalation	Abuse Elevation Control Mechanism: Sudo and Sudo Caching, reflecting the proof-of-concept's direct modification of sudoers configuration	T1548.003
Defense Evasion	Exploitation for Defense Evasion, since the AppArmor bypass technique used against Ubuntu 24.04 restores an otherwise blocked local attack path	T1211
Persistence	Account Manipulation, via modification of sudoers files to retain elevated access	T1098
Command & Control	N/A — no C2 communication has been documented; this is a local privilege escalation bug with no network callback component	—

Vulnerability Chaining Opportunities

OVSwrap is a local privilege escalation vulnerability, so it does not by itself provide initial access to a system. It is most dangerous when chained after any other vulnerability or misconfiguration that already grants an attacker an unprivileged local foothold, such as a web application vulnerability, a container escape, or a compromised application account. In those scenarios, OVSwrap converts what would otherwise be a limited, contained compromise into full root control of the host. No specific chained CVEs have been publicly documented alongside OVSwrap at this time.

Relevant misconfigurations that increase exposure include leaving unprivileged user namespaces enabled on systems that do not require them, having the Open vSwitch kernel module present even where OVS itself is not actively used, and running multi-tenant or shared-hosting environments where multiple local accounts, some potentially compromised, share a single kernel.

Detection and Monitoring

Because the attack executes largely in kernel space, conventional endpoint telemetry may not surface obvious indicators, so detection should focus on a combination of audit logging and behavioral signals. Security teams should watch auditd logs for unexpected privilege escalation events, including setuid and setgid calls originating from non-privileged processes, and for processes that unexpectedly begin running as UID 0 without originating from a known privileged session. Anomalous access to /dev/openvswitch or unusual ioctl calls against the OVS datapath device are also worth monitoring for. Unexpected creation of user and network namespaces by ordinary local accounts, particularly in combination with subsequent Open vSwitch activity, is a strong behavioral indicator given how the public proof-of-concept operates. File integrity monitoring on /etc/sudoers and /etc/sudoers.d can also help detect the specific persistence mechanism the released exploit uses.

Risk Assessment

Factor	Assessment
Impact	Critical. Successful exploitation grants full root access from an unprivileged local account, with especially severe consequences in multi-tenant and shared-hosting environments.
Likelihood	High on unpatched systems where the Open vSwitch module is present and unprivileged user namespaces are enabled, which is the default configuration on a large number of mainstream distributions, as confirmed by the researcher's own test matrix.
Exploit Maturity Influence	Significantly elevated by the availability of a public, functional, destructive proof-of-concept with pre-built support for roughly 800 kernel builds and dynamic derivation for others.
Overall Risk Level	High. The breadth of affected distributions in default configuration, combined with a working public exploit, makes this an urgent patch priority for any multi-user Linux system, and especially for shared hosting and multi-tenant infrastructure.

Patch and Mitigation

A patch is available upstream. The fix rejects oversized generated nested Open vSwitch action attributes and correctly propagates the resulting errors through the calling code, rather than allowing the length field to silently wrap. Fixed versions are available in the 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5 stable kernel releases. Systems running the end-of-life 6.13 through 6.17, 6.19, or 7.0 series will not receive an upstream backport and should be upgraded to a supported kernel series entirely.

Because distribution kernels carry independent backports, administrators should verify patch status against their specific vendor's security tracker rather than relying on upstream version numbers alone. As of the most recent reporting, CloudLinux's OS 9 and 10 lines did not yet have a patched kernel available and were instead tracking AlmaLinux's own upcoming 9.9 and 10.3 kernel streams on Red Hat's release schedule, though CloudLinux has made KernelCare live patches available as an interim, no-reboot fix ahead of that kernel release.

Where a patched vendor kernel is not yet available and Open vSwitch is not required, the fastest interim mitigation is blocking future module loads with:

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

This prevents the module from being loaded going forward, but it does not remove a module that is already resident in memory. If the module is already loaded, it must be unloaded manually or the system rebooted to fully clear the exposure. Disabling unprivileged user namespaces closes the ordinary local-user exploitation route demonstrated in the public proof-of-concept, but it does not block a process or container that already holds CAP_NET_ADMIN over an attacker-controlled network namespace. The researcher has described that container-based route as theoretically reachable, though it was not demonstrated in the released proof-of-concept. For environments that must keep both Open vSwitch and user namespaces active, the researcher's published code also includes an emergency BPF-based guard that can serve as a stopgap ahead of a full kernel upgrade.

Remediation Recommendations

Immediate actions should include identifying every system with the Open vSwitch kernel module present, whether or not it is currently loaded, since the module can be auto-loaded on demand by an unprivileged user. Patched vendor kernels should be applied wherever available, verified by checking the specific distribution's security tracker rather than comparing kernel version strings. Where a patch is not yet available and OVS is not required, the module-blocking mitigation above should be applied immediately, followed by unloading any already-resident module or scheduling a reboot.

Long-term fixes should include planning full kernel upgrades for any system still running the end-of-life 6.13 through 6.17, 6.19, or 7.0 series, since those branches will not receive an upstream backport for this issue at all. Organizations operating multi-tenant or shared-hosting infrastructure should treat this vulnerability as a reminder to review which kernel modules are present by default on their images, rather than assuming an unused module poses no risk simply because it has not been manually loaded.

Security best practices going forward should include disabling unprivileged user namespaces on systems that do not have a specific operational need for them, removing or blocking kernel modules that are not required for a given workload, and maintaining audit logging sufficient to detect unexpected namespace creation and privilege escalation events, since local privilege escalation bugs of this kind are difficult to catch through network-facing monitoring alone.

Instantly Fix Risks with Saner Patch Management

Saner Patch Management is a continuous, automated, and integrated patch management solution that helps organizations rapidly remediate vulnerabilities actively exploited in the wild. It supports Windows, Linux, macOS, and more than 550 third-party applications, enabling timely deployment of security updates across enterprise environments.

The platform also provides safe patch testing environments, automated deployment workflows, compliance reporting, and patch rollback capabilities to minimize operational risk while ensuring critical vulnerabilities are addressed without delay.

Experience the fastest and most accurate patching software here.