CVE-2026-46300

What it is. "Fragnesia" is the name used by the researcher who found it, William Bowling, and by Red Hat and Ubuntu. It belongs to the "Dirty Frag" class of ESP/XFRM page-cache bugs. The kernel's skb_try_coalesce() loses the "shared fragment" marker on network buffers, so IPsec ESP input can decrypt in place over memory that is really a cached copy of a file. It was disclosed on May 13, 2026 and the CVE was published May 23. What's new is CISA's listing.

CISA's KEV text, as written. "Linux Kernel contains a missing initialization of a variable vulnerability that could allow for unintended modification of page-cache-backed data via failure to preserve the shared-frag marker during socket buffer coalescing, causing ESP input processing to decrypt shared fragments in place. This vulnerability can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root." CISA also marks the CVE for forensic triage under BOD 26-04, and its SSVC entry records exploitation as active, automatable as no, and technical impact as total. EPSS on October 28 was 10.19% (95.7th percentile).

Severity. NVD, the kernel.org CNA and Red Hat all score it 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). SUSE scores it 8.8 because it rates the scope as changed. The "AV:L" (local) part is the key point. An attacker needs to be able to run code on the host first.

How it works, in plain words. Linux keeps recently read files in memory (the page cache). When a program sends a file over a socket with splice() or sendfile(), the kernel can hand the network stack the cached file pages directly and marks them "shared" so nothing writes over them. This bug drops that marker when TCP merges two buffers. If the data then reaches IPsec ESP decryption, which is what ESP-in-TCP (espintcp) does, the kernel decrypts in place and overwrites the cached file. Per the researcher's write-up, Tenable and the kernel CNA's scoring notes, any local user can do this without elevated privileges. They create a user and network namespace (unshare -Urn) to get CAP_NET_ADMIN inside it, install an ESP-in-TCP security association, and flip chosen bytes in any readable file's cached copy, such as a setuid binary. The file on disk is not changed, which matters for detection.

The chain CISA describes. In the chain, the PHP2Shell flaws give the attacker a foothold on the PHP server, and CVE-2026-46300 is the local step that raises that access to root. CISA's entry does not say more about how the two are combined, and we found no public write-up that does.

Public proof of concept. Yes. William Bowling (Zellic) published a working exploit on May 13, 2026, under the v12-security GitHub account. It writes a root shell stub into the cached copy of /usr/bin/su.

Distribution fixed packages, as published by each vendor.

• Debian 11: linux 5.10.257-1 (DLA-4606-1); linux-6.1 6.1.174-1~deb11u1 (DLA-4607-1)
• Debian 12: linux 6.1.174-1 (DSA-6306-1)
• Debian 13: linux 6.12.90-1 (DSA-6295-1, Debian's own backport)
• Ubuntu 26.04 LTS: linux 7.0.0-22.22. Ubuntu 25.10: linux 6.17.0-35.35. Ubuntu 24.04 LTS: linux 6.8.0-124.124, HWE 6.17.0-35.35~24.04.1. Ubuntu 22.04 LTS: linux 5.15.0-181.191, HWE 6.8.0-124.124~22.04.1. Ubuntu 20.04 LTS: the 5.4 kernel is not affected; HWE 5.15.0-181.191~20.04.1 (Ubuntu Pro)
• RHEL 10: kernel 6.12.0-211.16.1.el10_2 (RHSA-2026:19569). RHEL 9: kernel 5.14.0-687.10.1.el9_8 (RHSA-2026:19568). RHEL 8: kernel 4.18.0-553.125.1.el8_10 (RHSA-2026:19666), kpatch livepatch RHSA-2026:23470. RHEL 6 and 7 are not affected. Red Hat also lists fixed RHEL CoreOS images for OpenShift 4.12 through 4.21
• SUSE Linux Enterprise Server 16.0: kernel-default 6.12.0-160000.31.1 or later. SLES 15 SP7: kernel-default 6.4.0-150700.53.55.1 or later
• Amazon Linux 2023: ALAS2023-2026-1710 plus livepatch advisories. Amazon Linux 2: ALAS2-2026-3307 and the Kernel-5.4, 5.10 and 5.15 Extras advisories plus livepatch advisories. Tenable says Amazon Linux is not affected because it doesn't ship the espintcp module; Amazon's own security center lists these advisories, so we keep them

Check your vendor's page for older or extended-support streams not shown here. The earlier Dirty Frag flaws CVE-2026-43284 (ESP) and CVE-2026-43500 (RxRPC), disclosed May 7, 2026, are separate CVEs with separate fixes and are not on CISA KEV as of the October 28 catalog.

Checks, in order. Run these only on systems your organization owns. None of them runs exploit code.

1. Check the running kernel, not just the installed one. Run uname -r and compare it to the fixed version for your distribution above. A patched kernel package does nothing until the host reboots into it or a livepatch is applied. List installed kernels with dpkg -l 'linux-image*' | grep ^ii (Debian, Ubuntu) or rpm -q kernel (RHEL, SUSE, Amazon Linux). For livepatch, check kpatch list (RHEL) or canonical-livepatch status (Ubuntu).
2. Ask whether an attacker can get local code execution. This is a local bug, so the first question is who can run code on the host. Prioritize in this order. PHP servers exposed to PHP2Shell (use the companion post to find them); this is the chain CISA names. Any internet-facing service that runs as a local user and could be turned into a shell (web apps, CI runners, notebooks, plugin hosts). Shared and multi-tenant hosts such as shell servers, build farms and hosting platforms. Container hosts, because containers share the host kernel and Ubuntu's security team says the flaw could "possibly" be used to escape a container.
3. Check whether unprivileged users can create user and network namespaces. The published exploit uses them to get CAP_NET_ADMIN without elevated host privileges, and Tenable notes they are enabled by default on most distributions. Run sysctl user.max_user_namespaces (0 means no user namespaces can be created). On Ubuntu, check sysctl kernel.apparmor_restrict_unprivileged_userns; the researcher's README says the exploit needs this set to 0 on Ubuntu, and also says other bugs could be chained to get around it, so treat it as a speed bump, not a block. For a specific service account, test as that user with sudo -u www-data unshare -Urn true && echo "userns allowed". This creates and immediately exits an empty namespace and changes nothing.
4. Check whether the IPsec ESP modules can load. The bug is reached through ESP input processing. lsmod | grep -E 'esp4|esp6|xfrm' shows what is loaded right now. A module that is not loaded can usually still be loaded on demand, so also run modprobe -n -v esp4 and modprobe -n -v esp6. If the output is install /bin/false, loading is blocked. Find out whether the host really uses IPsec (for example strongSwan or Libreswan VPNs) before blocking anything.

A host is in the highest-priority group when all of these are true. Unpatched running kernel, a realistic path to running code on it (especially PHP2Shell), unprivileged user namespaces allowed, and ESP modules loadable.

The real fix is a patched kernel plus a reboot or livepatch. Use these only to cover the gap, and test each one on the host where it matters, for example by confirming that modprobe esp4 is refused after you block the modules. A rule that exists is not the same as a rule that works.

• Patch and reboot, or livepatch. Red Hat (kpatch), Ubuntu (Livepatch) and Amazon Linux publish livepatches for this CVE. Confirm the patch is active, not just installed.
• Block the esp4, esp6 and rxrpc modules (the researcher's stopgap, as reported by BleepingComputer). BleepingComputer quotes William Bowling saying "the mitigation is the same as for dirtyfrag," and reports that systems that can't be patched right away should remove the vulnerable kernel modules. The commands, identical in BleepingComputer and the researcher's README, are rmmod esp4 esp6 rxrpc followed by printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf. Caveat. This breaks IPsec VPNs and AFS distributed network file systems, so check whether the host uses either first. Tenable says organizations that already applied this module block for Dirty Frag are already protected against Fragnesia, while those that only installed the Dirty Frag kernel patches are not. Confirm with lsmod | grep -E 'esp4|esp6|rxrpc' and modprobe -n -v esp4, and reboot if a module won't unload. In May, the developer who fixed the related Dirty Frag variants recommended keeping this mitigation in place because more variants in the ESP module are expected.
• Patch PHP. Closing PHP2Shell removes the remote first step of the chain CISA describes. Follow the companion PHP2Shell post. This does not fix the kernel bug for anyone who already has local access.
• EDR rules for the chain. Because CISA says the chain runs commands as root through PHP webshells, alert on web server and PHP-FPM processes (www-data, apache, nginx, php-fpm) that spawn shells, and on any process that becomes root from a web server parent. The researcher's write-up shows the exploit calling unshare(CLONE_NEWUSER | CLONE_NEWNET), installing an ESP security association over NETLINK_XFRM and enabling the espintcp TCP option, so those are worth alerting on from web server accounts too. A root shell whose parent chain leads back to the web server is the signal to look for.
• File integrity monitoring. Watch web roots for new or changed .php files (CISA says the chain plants webshells). Per the researcher and Tenable, this bug changes the cached copy of a file, not the file on disk, so on-disk hash checks of /usr/bin/su and other setuid binaries may look clean while the in-memory copy is altered. Tenable notes that a reboot or cache flush restores normal behavior, which also erases the evidence, so collect evidence first.
• Follow CISA's forensic triage steps. CISA flags this CVE for forensic triage under BOD 26-04. Its guidance, summarized as written. (1) Scope which systems and services are in play and set up an out-of-band communication channel. (2) Preserve and collect evidence, volatile data such as memory first, before changing or fixing systems where possible, and keep a collection log. (3) Apply critical patches after evidence is collected. (4) Contain and isolate affected systems after evidence collection, without alerting the attacker. (5) Analyze evidence for unauthorized access, lateral movement, persistence and data staging, and check whether indicators appear elsewhere. (6) Write a triage report and decide whether to escalate. CISA's suggested timeline runs from the first two hours to 72 hours after the KEV addition. Because this bug lives in memory, the "volatile data first" step matters here.

• Shells or child processes spawned by www-data, apache, nginx or php-fpm, and any process that becomes root with a web server in its parent chain.
• Calls to unshare with CLONE_NEWUSER and CLONE_NEWNET, NETLINK_XFRM security association installs, or the espintcp TCP option enabled from a web server or other service account.
• New or changed .php files in web roots.
• Setuid binaries whose on-disk hash is clean but whose in-memory behavior is wrong. A reboot or cache flush erases this evidence, so capture memory first.

Am I exposed to CVE-2026-46300?

You are if a Linux host runs a kernel older than the fixed version for your distribution, someone untrusted can already run code on it (for example through an unpatched PHP server, a shared shell account or a container), and the IPsec ESP modules can load. Start with uname -r and your vendor's fixed version.

Is there a patch for CVE-2026-46300?

Yes. Upstream stable kernels 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 and 7.0.10 (and 7.1) include the fix, and Debian, Ubuntu, Red Hat, SUSE and Amazon Linux have shipped fixed kernels, several with livepatches. You must reboot into the new kernel or apply the livepatch for it to take effect.

How do I mitigate CVE-2026-46300 without patching?

The researcher's stopgap is to unload and block the esp4, esp6 and rxrpc kernel modules. This breaks IPsec VPNs and AFS, so check whether you use them first. Patching PHP also closes the PHP2Shell entry point that CISA names. Test each change on your hosts, because these reduce exposure but are not a fix.

Is CVE-2026-46300 related to PHP2Shell?

They are separate bugs. CISA says CVE-2026-46300 "can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root." PHP2Shell gives the foothold on the PHP server, and this kernel bug is the local step that can raise that access to root. Patching only PHP leaves the kernel bug open to anyone who already has local access, so fix both.

Is CVE-2026-46300 a zero-day?

No. It was disclosed and fixed in May 2026. What changed on October 28 is that CISA listed it as exploited and set an October 31 deadline for federal agencies.

Oct 29, 2026. First published. CISA added the CVE to KEV on Oct 28 with an Oct 31 due date and a forensic triage flag.

• CISA KEV catalog JSON feed (catalog version 2026.10.28; entries for CVE-2026-46300, CVE-2026-109618, CVE-2026-109619)
• CISA BOD 26-04 implementation guidance (forensic triage steps)
• NIST NVD: CVE-2026-46300
• CVE record (kernel.org CNA affected ranges and CVSS rationale; CISA ADP)
• Linux mainline fix commit and 5.10 backport
• oss-security, CVE assignment (May 13, 2026) and Dirty Frag variant fixes and keeping the mitigation (May 21, 2026)
• William Bowling (Zellic), Fragnesia write-up and proof of concept, v12-security GitHub (read only, not run)
• BleepingComputer, New Fragnesia Linux flaw lets attackers gain root privileges (May 14, 2026)
• Tenable, Fragnesia FAQ (May 14, 2026), cited for exploit mechanics and mitigation only; its KEV and exploitation statements predate CISA's listing
• Vendor pages: Red Hat, Ubuntu, Ubuntu blog on Dirty Frag mitigations, Debian, SUSE, Amazon Linux
• FIRST EPSS
• Companion post, Tuskira on PHP2Shell