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 line | Fixed in |
|---|---|
| Upstream stable | 7.0.10, 6.18.33, 6.12.91, 6.6.141, 6.1.174, 5.15.208 |
| Ubuntu 26.04 LTS | 7.0.0-22.22 |
| Ubuntu 25.10 | 6.17.0-35.35 |
| Ubuntu 24.04 LTS | 6.8.0-124.124 |
| Ubuntu 22.04 LTS | 5.15.0-181.191 |
| Debian 13 trixie | 6.12.90-1 (DSA-6295-1) |
| Debian 12 bookworm | 6.1.174-1 (DSA-6306-1) |
| Debian 11 bullseye (LTS) | 5.10.257-1 (DLA-4606-1) |
| RHEL and OpenShift | Per 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
esp4andesp6from loading cannot reach the vulnerable path. Check withlsmod | grep -E '^(esp4|esp6) 'andcat /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
- CISA KEV entry for CVE-2026-46300
- NVD CVE-2026-46300
- oss-security: Linux kernel LPE ("fragnesia")
- oss-security: Hyunwoo Kim's analysis and mitigation
- oss-security: fix merged into netdev
- Kernel fix f84eca581739
- V12 Fragnesia disclosure and proof of concept
- Dream Research: Chained PHP2Shell Exploit Roots 25 Servers
- Ubuntu CVE-2026-46300
- Debian security tracker CVE-2026-46300
- Red Hat CVE-2026-46300
- Siemens SSA-019113




