On 28 October 2026 CISA added CVE-2026-46300 to its Known Exploited Vulnerabilities catalog. The bug is Fragnesia, a Linux kernel privilege escalation that was disclosed on oss-security on 13 May 2026. The KEV catalog entry says it "can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root." Those two CVEs are PHP2Shell. A remote PHP bug gets the attacker a shell as the web server user, and Fragnesia turns that shell into root.
Patched kernels have been out since May, which is exactly why this one is easy to get wrong. On a VPS with unattended upgrades, the fixed kernel package may have been installed months ago while the machine kept running the old kernel, because nobody rebooted. The package list says patched. The running kernel says otherwise. Below: who is exposed, how to check what your hosts and containers really run, how to patch, and what to look at if someone may have got there first.
What Fragnesia does
The researchers, William Bowling and the V12 team, describe it in their public write-up as "a universal Linux local privilege escalation exploit" in the XFRM ESP-in-TCP code. During TCP receive coalescing, the kernel forgets that a buffer fragment is shared with a file's page cache (the NVD description traces it to skb_try_coalesce()). The ESP code then decrypts in place, on top of that cached file page. By picking the encryption nonce, an attacker can set any byte of any file they can read, and the write-up says this works "without requiring any race condition."
The public proof of concept rewrites the first 192 bytes of /usr/bin/su in memory and executes it to get a root shell. The kernel.org CNA scored the bug CVSS 3.1 7.8 (High). Ubuntu's CVE page gives it high priority with the reason "Trivial local privilege escalation" and says an attacker could "possibly escape a container".
One detail changes how you investigate. The V12 write-up states that "the page cache modification is not backed to disk; the on-disk binary is untouched." A file integrity check against the disk will look clean, and a reboot erases the in-memory change itself.
Who is actually exposed
Fragnesia is local, so the attacker has to run code on the machine first. On a small team's server that usually comes from one of these:
- A web application with a remote code execution bug that hands out a shell as
www-dataor a similar user. This is the chain CISA describes. - Containers started with
--privilegedor--security-opt seccomp=unconfined, including CI runners that build images on the same host as production. - Servers where several people or customers have their own shell accounts.
The exploit needs to create namespaces. Per the write-up, it calls unshare(CLONE_NEWUSER | CLONE_NEWNET) to obtain CAP_NET_ADMIN "without any real privileges on the host." Two existing controls get in the way of that step. Neither one replaces the patch.
The first is Ubuntu's AppArmor restriction. The same README says that on Ubuntu "AppArmor restricts unprivileged user namespaces by default", and the public exploit only works after you switch that off. It also says other bugs can be chained to bypass the requirement. Check yours with sysctl kernel.apparmor_restrict_unprivileged_userns; a value of 1 means the restriction is on.
The second is Docker's default seccomp profile. We tried this on one of our own Ubuntu 24.04 hosts with Docker Engine 29.9.2. In a default container, unshare -U -r -n id failed with "Operation not permitted". The same command in a container started with --security-opt seccomp=unconfined succeeded and printed uid=0(root) inside the new namespace. Containers that run without seccomp are where your attention should go first.
Step 1: check the kernel you are running, not the one you installed
A container has no kernel of its own. Run docker run --rm alpine uname -r and you get the host's kernel version back. So the usual advice for library bugs, rebuilding images with docker build --pull, does nothing for Fragnesia. The fix lives on the host, and it only counts after a reboot.
On each host, compare the running kernel with what is installed:
uname -r
dpkg -l 'linux-image*' | grep ^ii
cat /var/run/reboot-required.pkgs 2>/dev/null
sudo needrestart -k -bOn Ubuntu servers, needrestart -k -b prints the running kernel as NEEDRESTART-KCUR and the newest installed one as NEEDRESTART-KEXP. If the two differ, you are booted into an older kernel than the one on disk. On Debian, uname -v includes the Debian package version.
Then compare against the fixed versions. From Ubuntu's CVE-2026-46300 page:
- Ubuntu 26.04 LTS: fixed in 7.0.0-22.22
- Ubuntu 24.04 LTS: fixed in 6.8.0-124.124
- Ubuntu 22.04 LTS: fixed in 5.15.0-181.191, and 6.8.0-124.124~22.04.1 for the HWE kernel
- Ubuntu 20.04 LTS: the default 5.4 kernel is listed as not affected; the 5.15 HWE kernel is fixed in 5.15.0-181.191~20.04.1 through Ubuntu Pro
- Ubuntu 26.10: not affected
From the Debian security tracker:
- Debian 13 trixie: fixed in 6.12.90-1 (DSA-6295-1)
- Debian 12 bookworm: fixed in 6.1.174-1 (DSA-6306-1)
- Debian 11 bullseye LTS: fixed in 5.10.257-1 (DLA-4606-1), or 6.1.174-1~deb11u1 for the linux-6.1 backport (DLA-4607-1)
Cloud kernel flavours such as linux-aws or linux-azure have their own version numbers, so look up your flavour on the Ubuntu page rather than matching the generic kernel number.
Step 2: patch and reboot
Canonical's Dirty Frag guidance, which Ubuntu's Fragnesia page links for the same mitigation steps, comes down to a normal upgrade followed by a reboot:
sudo apt update && sudo apt upgrade
sudo rebootThe same post notes that unattended-upgrades applies security updates every 24 hours, "but a reboot is still required." That last part is easy to miss. After the reboot, run uname -r again and confirm it matches the list above. Then run docker ps -a and look for containers that did not come back, usually the ones without a restart: policy in their compose file.
While you are on the host, list containers that run without seccomp or in privileged mode:
docker inspect --format '{{.Name}} privileged={{.HostConfig.Privileged}} {{.HostConfig.SecurityOpt}}' $(docker ps -q) \
| grep -E 'privileged=true|unconfined'No output means none of your running containers has those settings. Anything that does show up should have a written reason.
Step 3: if you cannot reboot today
The interim mitigation is the same one used for Dirty Frag: stop the kernel from loading the esp4, esp6 and rxrpc modules. These are the commands from Canonical's post:
echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all
sudo rmmod esp4 esp6 rxrpc 2>/dev/null
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"Know what this breaks before you run it. Canonical warns that it affects IPsec deployments, which "are common with VPN implementations such as StrongSwan". Docker users have one more case: overlay networks created with --opt encrypted use IPsec encryption, so a Swarm cluster with encrypted overlays will lose that traffic. Once the patched kernel is running, remove /etc/modprobe.d/dirty-frag.conf and run sudo update-initramfs -u -k all again.
Step 4: if you think it was already used
The KEV entry marks this CVE "Forensic triage required per BOD 26-04: Yes". That rule binds US federal agencies only, but the reasoning applies to everyone: a host that ran a vulnerable kernel next to an exposed PHP app should be checked for compromise, not only patched.
Rebooting removes the modified page cache. It does not remove anything an attacker wrote to disk after becoming root. Look for PHP files in upload and cache directories that your application did not create, new accounts in /etc/passwd, unknown keys in authorized_keys, and new cron jobs or systemd units. On a host that never uses IPsec, esp4 or esp6 appearing in /proc/modules is worth a closer look, because the exploit sets up an ESP security association. Treat it as a lead, not as proof.
Root on a Docker host means access to every container, every volume and every secret passed in as an environment variable. If you find signs of compromise, rebuild the host from a known-good image instead of cleaning it, and rotate the credentials it held. We wrote about that order of work in patch first, then rotate every secret the box held. If the entry point was PHP, our PHP2Shell guide covers patching the PHP runtime inside your images. And logs that already left the server are the ones a root attacker cannot quietly edit, which is one reason we send container logs to stdout and ship them off the host.
Frequently asked questions
My images are rebuilt every week. Am I covered?
No. Containers use the host's kernel, so Fragnesia is fixed only by a patched host kernel and a reboot. Image rebuilds matter for userland bugs like PHP2Shell, not for this one.
Can Fragnesia be exploited over the network?
Not by itself. It needs local code execution. CISA's catalog entry describes it being chained with the PHP2Shell remote bugs, which is how an internet-facing server ends up exposed.
Ubuntu restricts unprivileged user namespaces. Is that enough?
It stops the public exploit as written, but the researchers say other bugs can be chained to bypass it. Install the fixed kernel anyway.
Do I really need to reboot?
Yes. Canonical's guidance says a reboot is required after the kernel update, even when unattended-upgrades installed it for you. Until then the old kernel keeps running.
Will blocking esp4 and esp6 break my setup?
It breaks IPsec, including strongSwan VPNs and Docker overlay networks created with --opt encrypted. If you use neither, the mitigation is low risk until you can reboot.
Sources: CISA KEV alert, 28 October 2026, CISA KEV catalog, NVD CVE-2026-46300, Ubuntu CVE tracker, Debian security tracker, oss-security disclosure thread, V12 Fragnesia write-up, Canonical Dirty Frag mitigation post and Docker overlay network documentation. Commands tested on Ubuntu 24.04.5 LTS with kernel 6.8.0-147-generic and Docker Engine 29.9.2 on 1 November 2026. The module-blocking mitigation was not applied on that host.
