Fragnesia CVE-2026-46300 is on CISA KEV: the Linux kernel bug that turned a web shell into root. Check memory, then patch

7 min read

How to fix CVE-2026-46300: upgrade the Linux kernel to 7.0.10, 6.18.33, 6.12.91, 6.6.141, 6.1.174, 5.15.208 or your distro's fixed build, then reboot. Fragnesia rewrites files in memory, so check su and PAM before you restart.

Fragnesia CVE-2026-46300 is on CISA KEV: the Linux kernel bug that turned a web shell into root. Check memory, then patch
On this page

CISA added CVE-2026-46300, the Linux kernel bug known as Fragnesia, to its Known Exploited Vulnerabilities catalog on Wednesday, October 28 (catalog 2026.10.28, released 3:00 PM ET). This is the second half of the PHP2Shell chain that rooted 25 firewall appliances and reached a US government-affiliated network: PHP2Shell gets a process running as nobody, and Fragnesia turns that into root by rewriting a system file in memory. Federal agencies have until October 31 to fix it, three days, and CISA flagged it for forensic triage, not just patching.

The fix has been in stable kernels since late May. What makes this one awkward is where the damage lives. Fragnesia writes into the kernel's page cache, the in-memory copy of a file, and never touches the disk. A reboot clears the backdoor and the evidence together, so look before you restart anything.

How to fix

Install your distribution's fixed kernel and reboot into it. A kernel package that is installed but not booted does nothing.

# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade
# RHEL, Rocky, Alma, Fedora
sudo dnf upgrade --refresh kernel
# then, after the checks in the next section
sudo reboot
uname -r
Kernel lineFixed in
Upstream stable7.0.10, 6.18.33, 6.12.91, 6.6.141, 6.1.174, 5.15.208
Ubuntu 26.04 LTS7.0.0-22.22
Ubuntu 25.106.17.0-35.35
Ubuntu 24.04 LTS6.8.0-124.124
Ubuntu 22.04 LTS5.15.0-181.191
Debian 13 trixie6.12.90-1 (DSA-6295-1)
Debian 12 bookworm6.1.174-1 (DSA-6306-1)
Debian 11 bullseye (LTS)5.10.257-1 (DLA-4606-1)
RHEL and OpenShiftPer stream, see Red Hat's CVE-2026-46300 page (RHSA-2026:19521 and later)

If you cannot reboot yet, the stopgap is the one published for Dirty Frag in May, because Fragnesia sits in the same IPsec code. It blocks the ESP modules from loading:

sudo tee /etc/modprobe.d/dirtyfrag.conf <<'CONF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
CONF
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

That kills IPsec on the box. If the host terminates a strongSwan or Libreswan tunnel, this breaks the VPN, so patch those hosts instead. The original mitigation also runs echo 3 > /proc/sys/vm/drop_caches. That evicts any tampered pages, which also erases the only copy of what an attacker changed. Do the checks below first.

Check memory before you reboot

In the public proof of concept from V12, Fragnesia overwrites the first 192 bytes of /usr/bin/su with a tiny root shell. In the firewall intrusion that Dream reconstructed, the attacker overwrote /etc/pam.d/su so it says pam_permit.so, which makes su root accept any password. In both cases the file on disk is untouched and every program that reads the file sees the attacker's version, until the cached copy is dropped.

# 1. The PAM line Dream found. Any hit in su is wrong on a normal system.
grep -n pam_permit /etc/pam.d/su /etc/pam.d/su-l 2>/dev/null

# 2. Compare what memory says with what the package says.
rpm -V pam util-linux shadow-utils     # RHEL family: a "5" in the flags means the content differs
dpkg --verify login util-linux libpam-runtime   # Debian / Ubuntu: same idea

# 3. Compare the cached file with the on-disk file directly.
#    A normal read goes through the page cache. O_DIRECT skips it (works on ext4 and XFS).
for f in /usr/bin/su /etc/pam.d/su /usr/bin/sudo /etc/pam.d/su-l; do
  a=$(sha256sum "$f" | cut -c1-64)
  b=$(dd if="$f" iflag=direct bs=4096 status=none | sha256sum | cut -c1-64)
  [ "$a" = "$b" ] || echo "MISMATCH: $f (memory differs from disk)"
done

A mismatch on step 3 is the signature of this bug class. Normal edits change the disk too. Before you reboot a host that shows one, copy the cached file out (cp /etc/pam.d/su /root/evidence-pam-su), save last, journalctl _COMM=su and the process list, and treat the box as rooted. Passing all three checks does not clear a host that has already been rebooted, because the evidence is gone. On those, look at what root could have left on disk: new systemd units, rc.local lines, authorized SSH keys and outbound SSH sessions, which is what Dream found on the government firewall.

What the bug does

Linux can carry IPsec ESP packets inside a TCP stream (ESP-in-TCP, the espintcp mode). To save copies, the kernel lets file data sent with splice() sit in the network buffers as references to the file's page cache, and it marks those buffers as shared so nothing writes into them. The function that merges TCP buffers, skb_try_coalesce(), moved those references into a new buffer without carrying the shared marker across. The ESP receive path then saw an unmarked buffer and decrypted it in place, directly over the cached file pages.

V12's William Bowling turned that into a write primitive. AES-GCM decryption XORs a keystream byte into the data, and the attacker picks the nonce, so they can choose which byte lands. One trigger writes one byte, with no race to win. The fix, "net: skbuff: preserve shared-frag marker during coalescing", copies the marker when frags move.

The Dream case shows why that matters on locked-down systems. SELinux confined the firewall's web server so nobody could not edit system files. Fragnesia never asks the filesystem for write access. It goes around it.

Firewalls and appliances are the hard part

The 25 rooted boxes in Dream's report were firewall appliances from a vendor Dream did not name. You cannot apt upgrade an appliance kernel. Ask your firewall, VPN and storage vendors whether their firmware ships a kernel with the CVE-2026-46300 fix, and get it in writing. Siemens has already listed affected SIMATIC S7-1500 MFP controllers in SSA-019113, with a fix in V3.1.7, so embedded Linux is in scope too. Until firmware arrives, keep management interfaces off the internet. That is the door PHP2Shell used.

Who is not in scope

  • Ubuntu 20.04 and older on their standard kernels are listed as not affected by Canonical. The HWE 5.15 kernel on 20.04 is affected and has a fix through Ubuntu Pro.
  • Hosts that already block esp4 and esp6 from loading cannot reach the vulnerable path. Check with lsmod | grep -E '^(esp4|esp6) ' and cat /etc/modprobe.d/*.conf | grep esp.
  • Per Hyunwoo Kim's analysis on oss-security, exploitation needs permission to create user namespaces unless it is chained with another bug. Hosts that disable unprivileged user namespaces raise the bar for a lone local user. They do not stop a chain like the one Dream documented.
  • Being patched for Dirty Frag (CVE-2026-43284 and CVE-2026-43500) in early May is not the same as being patched for Fragnesia. It is a separate fix that landed later.

What this is not

Fragnesia is not a remote attack. Nobody can use it against a Linux server from the network alone. It needs code already running on the machine, which is exactly what a web shell, a stolen SSH login, or a compromised CI job provides. It also does not change files on disk, which is why integrity tools that only hash stored files after a reboot will miss it.

What do people ask about Fragnesia CVE-2026-46300?

Is Fragnesia being exploited?

Yes. CISA added CVE-2026-46300 to the Known Exploited Vulnerabilities catalog on October 28, 2026, and Dream documented it chained with PHP2Shell to root 25 firewall appliances, including systems on a US government-affiliated network.

Which Linux kernel versions fix CVE-2026-46300?

Upstream stable kernels 7.0.10, 6.18.33, 6.12.91, 6.6.141, 6.1.174 and 5.15.208 contain the fix. Distribution kernels carry it under their own version numbers, such as Ubuntu 24.04 6.8.0-124.124 and Debian 12 6.1.174-1. You must reboot into the new kernel.

Can Fragnesia be exploited remotely?

No. It is a local privilege escalation. An attacker needs code running on the machine first, for example through a web application bug like PHP2Shell.

What is the workaround if I cannot reboot?

Block the esp4, esp6 and rxrpc kernel modules with a modprobe install rule and unload them. This disables IPsec on that host, so do not use it on VPN gateways.

Will a file integrity check find a Fragnesia backdoor?

Only before the page cache is cleared. The change exists in memory, not on disk, so compare a normal read of the file with a direct read that bypasses the cache, and check before rebooting.

Timeline

  • May 13, 2026: V12 discloses Fragnesia with a public exploit. CVE-2026-46300 assigned the same day.
  • May 21, 2026: The standalone fix is merged into the networking tree.
  • May 23, 2026: CVE record published. Stable kernels and distributions ship fixes over the following weeks.
  • October 23 to 24, 2026: Per Dream, the PHP2Shell plus Fragnesia chain roots firewalls on a US government-affiliated network, part of a campaign that rooted 25 servers.
  • October 28, 2026: CISA KEV add, due date October 31, forensic triage required.

The HOL Guard evidence pack for CVE-2026-46300 keeps the source record. For the web half of the chain, read our PHP2Shell KEV follow-up.

References

All articles

Keep exploring

The engineering desk continues across the ecosystem: security research on shipping agents safely, and plugins that put the standards to work.