Linux pedit COW Exploit Lets Local Attackers Gain Root Access

A newly disclosed Linux kernel vulnerability known as pedit COW can let a local unprivileged user escalate privileges to root on vulnerable systems.

The flaw is tracked as CVE-2026-46331 and affects the Linux kernel’s traffic-control subsystem, specifically the act_pedit packet-editing action. The NVD entry describes it as a partial copy-on-write issue that can corrupt page-cache memory.

A public proof-of-concept called packet_edit_meme has shown that the bug can be turned into a practical local root exploit on several Linux distributions. Administrators should treat the issue as urgent where unprivileged user namespaces remain enabled.

What Is the Linux pedit COW Vulnerability?

pedit COW is a kernel privilege escalation flaw in the net/sched act_pedit component. The pedit action belongs to Linux traffic control, a framework used to classify, shape, and modify network packets.

The tc-pedit manual explains that pedit can change arbitrary packet data, including packet-header fields. That packet-editing power is useful for legitimate networking tasks, but the kernel bug causes part of a write region to remain outside the expected private copy.

In practical terms, the kernel prepares one memory range for safe modification, but the actual packet edit can reach beyond that range. That creates a path to corrupt shared page-cache memory, which can affect files cached by the kernel.

Item	Details
CVE	CVE-2026-46331
Common name	pedit COW
Affected component	Linux kernel net/sched act_pedit
Bug class	Partial copy-on-write failure and page-cache corruption
Attack type	Local privilege escalation
Main risk	A local user may gain root access on vulnerable systems

How the Bug Reaches Root Access

The exploit path starts with local code execution. This is not a direct remote attack against Linux servers over the internet, but any attacker who already has a low-privileged account may be able to use it.

The public packet_edit_meme proof-of-concept uses a child process inside a user namespace to obtain namespace-local CAP_NET_ADMIN. That capability is enough to configure traffic-control actions inside the namespace on systems that allow unprivileged user namespaces.

The exploit then abuses the act_pedit flaw to poison cached file contents in memory. Instead of permanently modifying a file on disk, the attack targets what the kernel has already cached, which makes detection and response more difficult.

Why Page-Cache Corruption Is Serious

Linux uses the page cache to keep frequently accessed file data in memory. This improves performance because the system can read cached file contents without repeatedly going back to disk.

When a kernel write reaches shared page-cache memory by mistake, the impact can extend beyond a normal packet-editing error. A local attacker may influence how a privileged file is served from memory.

That is why pedit COW matters. It turns a networking subsystem bug into a privilege-escalation path, because the corrupted cached content can be used when a setuid-root binary runs.

• The attacker needs local code execution or a low-privileged account.
• The attack depends heavily on unprivileged user namespace availability.
• The flaw sits in the Linux traffic-control act_pedit action.
• The impact comes from page-cache corruption, not normal file replacement.
• Systems should be patched or mitigated quickly.

Where the Vulnerability Was Confirmed

The public exploit repository says testing in June 2026 produced root access on RHEL 10.0, Debian 13 Trixie, and Ubuntu 24.04.4 under specific conditions.

The same GitHub repository says the exploit failed on Ubuntu 26.04 with the tested configuration, because newer AppArmor restrictions blocked the bypass route used against Ubuntu 24.04.4.

This does not mean every Ubuntu 26.04 system is safe from the vulnerability itself. It means that one public exploit path failed under the tested conditions. Administrators still need to follow vendor patch status for their distribution and kernel package.

Distribution	Kernel Tested	Reported Result
RHEL 10.0	6.12.0-228.el10	Root access achieved
Debian 13 Trixie	6.12.90+deb13.1	Root access achieved
Ubuntu 24.04.4	6.17.0-22	Root access achieved with Ubuntu-specific path
Ubuntu 26.04	7.0.0-14-generic	Public exploit path failed in the test

Ubuntu Lists Multiple Releases as Vulnerable

Canonical’s security tracker lists CVE-2026-46331 as a high-priority issue. The Ubuntu CVE page describes the same pedit partial-COW bug and explains that the fix moves the writable-range check inside the per-key loop.

The tracker currently lists several Ubuntu releases as vulnerable, including 20.04 LTS, 22.04 LTS, 24.04 LTS, 25.10, and 26.04 LTS. Older 14.04 LTS and 16.04 LTS entries are marked not affected.

Ubuntu’s AppArmor restrictions may reduce exposure to some exploit paths, but they should not replace patching. Kernel updates remain the main fix for systems that run affected packages.

Debian Shows Fixed and Vulnerable Kernel Packages

Debian’s tracker also lists CVE-2026-46331 as a Linux kernel issue. The Debian security tracker shows the same root-cause description and separates package status by release.

At the time of the tracker update, Debian listed Trixie security package 6.12.94-1 as fixed and Forky/Sid package 7.0.13-1 as fixed. Bullseye and Bookworm entries remained listed as vulnerable in the visible tracker table.

Administrators should not rely only on the distribution name. They should check the installed kernel package version, update from official repositories, and reboot into the patched kernel.

Red Hat Rates the Issue as Important

Red Hat published a dedicated bulletin for the traffic-control privilege escalation issue. The Red Hat security bulletin rates CVE-2026-46331 as Important and says a user with a local account could exploit it to gain administrator access.

Red Hat lists Red Hat Enterprise Linux 8, 9, and 10 among directly affected products. It also notes that Red Hat OpenShift Container Platform has lower severity because the vulnerable module is not loaded by default.

The bulletin recommends blocking the act_pedit module as a mitigation where suitable. However, Red Hat warns that this may not work for systems that actively use tc pedit rules for traffic shaping or packet header rewriting.

Vendor	Status Summary	Administrator Action
Red Hat	Important impact, fixes available for many products	Apply kernel updates or evaluate act_pedit module blocking
Ubuntu	High priority, multiple active releases listed as vulnerable	Track Canonical kernel updates and reboot after patching
Debian	Some releases fixed, others still listed as vulnerable	Check installed kernel package against Debian tracker
CloudLinux	Kernel updates released for some streams, others rolling out	Apply vendor kernel updates or livepatch where available

CloudLinux Says Patching Requires a Kernel Update

CloudLinux said pedit COW is separate from earlier Linux page-cache bugs such as Dirty Frag and Fragnesia. That distinction matters because mitigations for those older vulnerabilities do not block act_pedit.

The CloudLinux advisory says pedit COW requires patching and rebooting affected hosts unless a livepatch is available through KernelCare. It also says patched kernels have been released for CloudLinux 9 and 10, with other streams moving through rollout.

Organizations running shared hosting, container hosts, or multi-user Linux systems should move quickly. A local privilege escalation bug can become critical when attackers already have shell access, compromised application accounts, or limited container footholds.

Why User Namespaces Increase the Risk

Unprivileged user namespaces let ordinary users create isolated environments where they can hold capabilities that they would not have on the host. This design supports containers and sandboxing, but it can also expose kernel attack surfaces.

In this case, namespace-local CAP_NET_ADMIN can give the exploit access to traffic-control operations needed to reach act_pedit. That makes user namespace policy an important temporary risk-reduction control.

Some distributions enable unprivileged user namespaces by default because applications and container tools depend on them. Others restrict them or add security layers that make exploitation harder.

• Disable unprivileged user namespaces where business needs allow.
• Review systems that provide shell access to many users.
• Audit container hosts and developer workstations first.
• Check whether act_pedit is loaded or used by traffic-control rules.
• Prioritize internet-facing servers where attackers may already gain low-level access through other bugs.

What Administrators Should Patch First

The highest-risk systems are multi-user servers, shared hosting platforms, CI/CD runners, container hosts, developer workstations, and servers that run exposed applications under restricted service accounts.

The CVE-2026-46331 record says the upstream fix moves skb_ensure_writable into the per-key loop where the real write offset is known. It also adds overflow checking and handles negative offsets more safely.

Because this is a kernel issue, applying the package update is not enough if the old kernel remains running. Administrators need to reboot or use an approved livepatching path, then confirm the active kernel version.

Mitigation Options Before Full Patching

The best fix is to install a patched kernel from the operating system vendor. Temporary mitigations can reduce risk, but they may affect applications that rely on traffic control, containers, or sandboxing.

The Red Hat mitigation guidance recommends blacklisting the act_pedit module to prevent it from loading automatically. Administrators should first verify whether the module is already in use, because blocking it can break legitimate tc pedit configurations.

Restricting unprivileged user namespace creation can also reduce exploitability on many systems. This change should be tested carefully because browsers, container tools, build systems, and sandboxed applications may depend on user namespaces.

Mitigation	Benefit	Possible Impact
Install patched kernel	Removes the vulnerability	Requires reboot unless livepatching is available
Blacklist act_pedit	Blocks the vulnerable module from loading	May break traffic-control rules that use pedit
Restrict unprivileged user namespaces	Reduces access to the exploit path	May affect containers, sandboxing, and developer tools
Monitor namespace and tc activity	Improves detection of exploitation attempts	Requires logging and tuned alerts

Detection Signals to Watch

Security teams should monitor sudden use of tc commands, loading of act_pedit, unexpected user namespace creation, and privilege changes from low-privileged accounts.

They should also review suspicious activity around setuid-root programs, although this exploit path targets cached memory rather than replacing binaries on disk. That means file integrity monitoring alone may not catch an attempted attack.

The pedit documentation can help defenders understand what legitimate pedit use looks like in their environment. Any pedit activity on servers that do not normally use traffic-control packet editing should be treated as suspicious.

Why This Vulnerability Is Different From Earlier COW Bugs

pedit COW belongs to a growing set of Linux privilege-escalation bugs involving page-cache corruption. However, administrators should not assume earlier mitigations cover this flaw.

The CloudLinux update specifically warns that pedit COW is in a different kernel area from Dirty Frag and Fragnesia. Module blacklists or mitigations used for those bugs do not address act_pedit.

That makes inventory important. Teams should identify where act_pedit can load, where user namespaces are enabled, and where local users or containers may interact with kernel networking features.

What Linux Users Should Do Now

Linux users and administrators should update their kernels through official distribution channels as soon as patches are available. After updating, they should reboot and verify that the patched kernel is actually running.

Ubuntu administrators should track the Ubuntu security status for their exact release and package. Debian administrators should check the Debian package status before assuming their release has received a fixed kernel.

Enterprises should also search for local accounts, exposed web services, CI runners, container hosts, and shared environments where a low-privileged foothold could become root. pedit COW is local, but it can turn a small compromise into full system control.

FAQ