Blog · 2026-10-29 · Gardience Engineering

Fragnesia (CVE-2026-46300): check, patch, and reboot every Linux server

CISA added the Fragnesia Linux kernel flaw to its exploited list after attackers chained it with PHP2Shell to get root. The fixed kernels per distribution, what to check before you reboot, and why a patched server is not protected until it restarts.

On October 28, 2026, CISA added CVE-2026-46300, "Fragnesia," to its Known Exploited Vulnerabilities catalog, with a federal deadline of October 31 and a requirement for forensic triage. Fragnesia is a Linux kernel flaw that lets any local user become root. On its own it needs a foothold on the server. Attackers found one: researchers at Dream reported a campaign that used PHP2Shell to get a web shell, then Fragnesia to turn it into root, on 25 servers.

So if a server ran an unpatched PHP in the last few weeks and has not had a kernel update since May, treat it as a candidate, not just as a patching job.

What it is#

Fragnesia was disclosed on May 13, 2026, with a public exploit. It is a bug in how the kernel merges network buffers for ESP-in-TCP (part of its IPsec code): a flag that marks a buffer as shared is lost, so the kernel can decrypt data in place over the page cache, the in-memory copy of files. The public exploit uses that to change /usr/bin/su in memory and become root. Red Hat rates it Important (CVSS 7.8) because it needs local access, which PHP2Shell supplies.

It is related to "Dirty Frag" (CVE-2026-43284 and CVE-2026-43500) but is a separate fix. A server patched for Dirty Frag only is still exposed.

The fixed kernels#

Upstream fixed it in 7.0.10, 6.18.33, 6.12.91, 6.6.141, 6.1.174 and 5.15.208. Your distribution's own version is what counts:

Ubuntu fixes each kernel type separately (generic, aws, azure, gcp, and the newer 6.17 and 7.0 kernels), so check the Ubuntu page for the type you run. Amazon Linux does not ship the affected module.

Before you patch: check for a break-in#

This is the step most guides skip, and the one CISA asks for. Fragnesia changes files in memory, not on disk. A reboot, which you need to load the fixed kernel, throws away the change, and with it the evidence. So look first:

grep -n pam_permit /etc/pam.d/su                   # the reported backdoor: su lets anyone in
sudo rpm -V util-linux pam                         # RHEL family: files that differ from the package
sudo dpkg --verify util-linux login libpam-runtime # Debian and Ubuntu: the same check

Reading a file reads the in-memory copy, so a changed su shows up in the package check before the reboot. If anything turns up, keep the server running, take it off the network, and investigate before you patch. Then check for PHP2Shell's web shells too: the server's PHP was the way in.

Patch, then reboot#

Install the new kernel the usual way:

sudo apt update && sudo apt install --only-upgrade linux-generic     # Ubuntu: or linux-aws, linux-virtual: your kernel's metapackage
sudo apt update && sudo apt install --only-upgrade linux-image-amd64 # Debian: linux-image-cloud-amd64 on cloud images
sudo dnf upgrade --cve CVE-2026-46300                                # RHEL, Rocky, AlmaLinux

Then reboot. A kernel fix does nothing until the machine runs the new kernel. This is where fleets get caught: the package is installed, every package-based scanner reports the server as fixed, and the old kernel keeps running for weeks because nobody scheduled the restart.

After the reboot, uname -r should show the new version. If you cannot reboot yet, block the vulnerable modules as a stopgap:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/fragnesia.conf
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

That breaks IPsec using those modules, so check first whether the server runs an IPsec VPN.

What it looked like on three real servers#

We started three servers on AWS today from images built before the fix, and ran the same steps on each.

On Rocky, dnf updateinfo listed the kernel packages as the fix before the update, and only kernel-tools (updated separately) after it, which is right for the installed packages. It is also exactly the moment a package-only view looks done while the vulnerable kernel is still running.

Doing it across a fleet#

On a handful of servers, the commands above are enough. On hundreds, the hard parts are knowing which machines run a vulnerable kernel, patching them with someone signing off, and making sure the reboots actually happen.

Gardience checks every machine daily against its distribution's own security data, kernel included: on Debian and Ubuntu (since 1.19) it checks the kernel each machine is actually running, and on Rocky, Alma, Oracle and RHEL it reads the distribution's advisories. Look up CVE-2026-46300 on the Vulnerabilities page to see every exposed machine; it is marked actively exploited, from CISA's catalog. Machines that installed the fixed kernel but have not restarted are marked restart needed. Then patch with the Patch, reboot, wait, verify workflow: it installs the new kernel, restarts each machine and waits until it is back before the run counts as done, inside your change windows. Every request, approval and per-machine result goes into the audit log.

Questions#

Is Fragnesia remotely exploitable?#

Not by itself. It needs code running on the server as any user. In the reported attacks, PHP2Shell provided that.

I patched for Dirty Frag. Am I covered?#

No. Fragnesia needs its own fix. If you blocked the esp4 and esp6 modules for Dirty Frag, that mitigation does cover Fragnesia.

Do I really have to reboot?#

Yes. Live-patching services can apply some kernel fixes without a restart, if you use one. Otherwise the fixed kernel runs only after a reboot.

What is the CISA deadline?#

October 31, 2026, for US federal agencies, with forensic triage. Everyone else should treat it as a strong hint.