Linux Kernel Flaw 'OVSwrap' Hands Local Users Root on Around 800 Builds
A memory corruption bug in Open vSwitch, tracked as CVE-2026-64531, lets ordinary users on default Linux systems become administrator, and a working exploit is already public.

Key points
- A newly disclosed Linux kernel flaw called OVSwrap, tracked as CVE-2026-64531, lets a normal user on a Linux machine gain full administrator control.
- The bug sits in Open vSwitch, a networking component switched on by default in many Linux distributions.
- A public exploit released with the disclosure ships with ready-made settings for roughly 800 different kernel builds.
- The flaw carries a CVSS severity score of 7.8 out of 10, in the "high" band.
- The researcher known as Asim published the finding and gave the bug its OVSwrap nickname.
A freshly disclosed bug in the Linux kernel, the core software that runs most of the world's servers and a large share of cloud services, lets a person who already has an ordinary account on a Linux machine take full control of it.
The flaw sits inside Open vSwitch, a virtual networking component that ships switched on by default in many popular Linux distributions. It is tracked as CVE-2026-64531 and carries a CVSS severity score of 7.8 out of 10.
A security researcher who goes by Asim disclosed the issue and named it OVSwrap. The disclosure, first reported by The Hacker News, came with a working exploit.
That exploit is not a proof-of-concept scribble. It ships with pre-built settings for around 800 separate kernel builds, meaning an attacker does not need to hand-tune it for each target.
What is actually broken here?
The bug is a memory corruption flaw in the Open vSwitch datapath, the part of the kernel that moves network packets around inside a Linux system. When that memory gets scrambled in a controlled way, an attacker can trick the kernel into running their code with the highest possible privileges.
In plain terms: a user who is only supposed to read their own files can end up owning the whole machine. That includes reading every other user's data, installing hidden software, and switching off security tools.
Who is at risk?
Any Linux system where Open vSwitch is loaded and a stranger can already log in as a normal user. That covers a lot of ground.
Shared servers at universities, cloud hosts that give customers low-privilege shells, and container platforms that rely on Open vSwitch for networking are all in scope. Home desktops running mainstream distributions may also be exposed if the module is present.
The flaw does not, on its own, let someone break in from the internet. An attacker needs a foothold first. The concern is that footholds are cheap: a stolen password, a booby-trapped app, or a compromised web service running on the box is enough.
| Detail | Value |
|---|---|
| CVE ID | CVE-2026-64531 |
| Nickname | OVSwrap |
| CVSS score | 7.8 (High) |
| Affected component | Linux kernel Open vSwitch datapath |
| Kernel builds in public exploit | ~800 |
| Access required | Local user account |
| Result of exploitation | Root (full administrator) |
What should administrators do now?
Check whether the openvswitch kernel module is loaded, and unload or blacklist it on machines that do not need it. On systems that do use it, watch your distribution's security channel closely and apply the kernel update as soon as it lands.
Ordinary home users do not need to panic. Keep automatic updates switched on and install kernel patches when your distribution offers them. If you share a Linux server with others, assume any account on that server is now a stepping stone to full control until the patch is applied.
The public exploit's coverage of roughly 800 kernel builds is the part that changes the risk picture. It removes most of the skill barrier. Anyone who can copy and paste a command can try it.
Common questions
Can this be exploited over the internet without a login?
No. The attacker needs an existing account or some other form of local code execution on the machine first. It is a privilege escalation bug, not a remote break-in.
Is a fix available yet?
At the time of writing, distributions are rolling out patched kernels on their usual schedules. Check your vendor's security advisory page and apply updates as soon as they appear.



