Linux kernel CVE-2026-46300 (Fragnesia) is now on CISA's list, and CISA ties it to PHP2Shell

Security teams rank bugs one at a time. Attackers do not. On 28 October CISA added a Linux kernel flaw from May to its list of vulnerabilities that are being exploited, gave it a three-day deadline, and said in the entry that it can be chained with the two PHP flaws we wrote about on 22 October to implant PHP webshells and run commands as root. A local bug that most teams had slotted as "patch later" is now the second half of a remote chain.

This note is for you if you run Linux servers, especially ones that run PHP or that let untrusted users or containers run code. Everything is as of 28 October 2026 and every claim links to its source at the end. One caution on sourcing: the statement about the PHP chain is in CISA's own catalog entry. We found no independent write-up of the chain, so we state it as CISA's claim and no more.

The short version

• CVE-2026-46300, nicknamed Fragnesia, is a flaw in the Linux kernel's network stack. CVSS 3.1 7.8: local, low privileges. A third-party write-up says it was disclosed publicly on 13 May 2026, with a proof of concept, by William Bowling of V12 Security.
• CISA added it to the Known Exploited Vulnerabilities catalog on 28 October, due 31 October. Ransomware use is not recorded.
• CISA's entry says it can be chained with CVE-2026-109618 and CVE-2026-109619, the PHP flaws, to implant PHP webshells and run commands as root.
• Fixed in stable kernels, among them 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91 and 6.18.33. Distributions backport, so use your distribution's advisory and the running kernel, not a version number alone.
• A stop-gap exists, with a cost: block the esp4, esp6 and rxrpc modules. It breaks IPsec on hosts that use it.
• If a host was exposed to the PHP flaws and has not had this kernel fix, assume the chain is possible and look for evidence it ran.

Free PDF · 8 pagesLinux kernel CVE-2026-46300 (Fragnesia): Assessment & Action PlanThe full version as a PDF for whoever runs your Linux servers: the mechanism, severity decoded, a dated timeline from the May disclosure to the KEV listing, exposure by situation, the patch and the stop-gap with its cost, how the PHP chain works at the level the sources support, hunting and a definition of done.Download the PDF →

What the bug is

The kernel moves network data around in buffers called socket buffers, and sometimes merges one into another to save work. Some of those buffers point at memory that belongs to someone else, such as the file cache, and carry a marker that says so. The marker tells later code not to write into that memory in place.

The CVE record describes the fault precisely. When the kernel merges fragments from one buffer into another, the function that does it did not carry the marker across. The merged buffer then holds the same externally owned pages, but without the flag. Later, the code that handles incoming encrypted traffic (ESP, the part of IPsec that wraps packets) checks the flag to decide whether it can decrypt in place. Seeing no flag, it decrypts in place, over memory it should have copied first. The upstream fix is two lines that preserve the marker.

The practical result, as a third-party write-up describes it, is that a local user can alter the in-memory copy of a file that the system caches, such as a setuid program, without touching the file on disk. The next time that program runs it runs the altered version, which gives root. The same write-up says the proof of concept targets the ESP-in-TCP path and depends on the espintcp module being present. We have not run it.

Why the score undersells it

CVSS 7.8 describes the flaw as it is: it needs a foothold on the machine. A score is a statement about one bug. It cannot say what else is on the machine, and what is on the machine is the point. A web server that runs PHP is a machine where an attacker who finds a remote flaw in PHP lands as the web server's account. That account is exactly the local, low-privilege foothold this bug needs.

That is the chain CISA describes. The PHP flaws provide the way in and the kernel flaw provides the way up. Neither needs the other to be dangerous, and together they remove the thing that usually limits the damage of a PHP compromise: that the attacker is stuck as an unprivileged user.

Why it is on the list now

CISA's Known Exploited Vulnerabilities catalog is for vulnerabilities it has evidence are being exploited. A listing is CISA's statement that exploitation has been seen; it does not say who, how widely or since when. The disclosure was in May. The listing is in October, two days after the PHP listings. We do not know what changed, and the entry does not say. Two reasonable readings fit what we can see: exploitation was observed recently, or the chain with PHP made it newly worth listing. Neither is stated. What is stated is the deadline: 31 October, three days from the entry.

Who is exposed

• Any Linux host with a kernel from 3.9 up to the fixed builds, in the sense of the CVE record. Distribution kernels differ; check the vendor.
• Hosts where an attacker can get code running as an unprivileged user: web servers (the PHP chain), shared development and build servers, CI runners, shared hosting, container hosts.
• On container hosts, the third-party write-up argues a single compromised container can reach the host.
• The write-up says Amazon Linux was not affected at the time of writing because it does not ship the loadable espintcp module. Treat that as a May statement about one distribution and check your own.

Things people will get wrong

• "It is only local." So is the second half of every chain. Ask what remote flaws put an attacker on the machine.
• "The file is unchanged on disk, so we are clean." The write-up says the on-disk file and its hash stay the same. File-integrity tools that read the disk will not see this.
• "A reboot cleared it." Rebooting or dropping caches clears altered cache pages. It does not undo anything the attacker did once they had root.
• "We patched PHP." Good, but the PHP flaws are only half of the chain, and an attacker with any other foothold still needs the kernel fixed.
• "The kernel is installed, so we are patched." The running kernel changes only after a reboot or a live patch.

How we would triage it

This is our judgement. The facts are from the sources.

• Rank by foothold. Hosts that run PHP, or let untrusted users or containers run code, come first, because for them the chain's first step is available.
• Treat the CISA deadline as the schedule. Three days is short. If you cannot reboot everything, reboot the exposed hosts and use the module stop-gap on the rest.
• Assume the PHP flaws may already have been used on any unpatched server and look for evidence, because this entry says the second step exists.

Step 1: what kernel is running, and is it fixed

# The running kernel (not the newest installed one)
uname -r

# Debian and Ubuntu: does the package changelog list the fix?
apt changelog linux-image-$(uname -r) | grep -i CVE-2026-46300

# RHEL family
rpm -q --changelog kernel-$(uname -r) | grep -i CVE-2026-46300

# Are the ESP modules loaded?
lsmod | grep -E '^(esp4|esp6|espintcp|rxrpc)'

Compare with your distribution's security advisory for CVE-2026-46300. If the changelog does not mention it, do not assume the build is fixed.

Step 2: patch, in order

• Hosts that run PHP or let untrusted code run: update the kernel and reboot, or apply a vendor live patch if you have one.
• Then the rest of the fleet in your normal cycle, with a short deadline.
• Update PHP everywhere it runs, to the fixed releases in our PHP2Shell note.

Step 3: the stop-gap, if you cannot patch yet

# Stop the modules loading, and unload them if nothing is using them
echo 'install esp4 /bin/false'  | sudo tee    /etc/modprobe.d/block-esp.conf
echo 'install esp6 /bin/false'  | sudo tee -a /etc/modprobe.d/block-esp.conf
echo 'install rxrpc /bin/false' | sudo tee -a /etc/modprobe.d/block-esp.conf
sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null || true

The cost is real. Hosts that terminate IPsec VPNs, for example with strongSwan or Libreswan, will stop working. Do not apply this to a VPN gateway without a plan. It is a stop-gap and should have an end date.

Step 4: assume the chain may have run

• On every PHP server that was unpatched for the PHP flaws, look in web roots and upload directories for files you did not put there, particularly PHP files with recent modification times.
• Review the web server and PHP-FPM accounts' activity: new child processes, shells, outbound connections.
• Look for root activity that does not belong to an administrator: new user accounts, new SSH keys, new scheduled jobs, new services.
• Remember that disk-based integrity checks will not see an altered cache. Rely on process and authentication logs, and on a reboot to clear any lingering cache changes.
• If you find a webshell, treat the host as compromised and rebuild it. Rotate the secrets it could read.

What we do not know yet

• How the chain works in detail, and whether it has been used. CISA's entry states it and we found no independent account.
• Why the listing came in October when the disclosure was in May.
• Which distributions have shipped a fix for which of their kernels. Vendors differ and the picture was changing.
• Whether the espintcp requirement in the write-up applies to every route to the bug.

If you take one thing from this: stop ranking bugs alone. For every local flaw, ask which remote flaws on the same machine put an attacker where it needs them. This week, PHP is the answer.

Read next

• PHP2Shell: what to do this week →Both PHP CVEs are in CISA's catalog. Which versions fix them and how to check a server.
• Daily CVE highlight, 28 October →Where this sits among the day's picks, in the order to act.
• The first 15 seconds →A one-page plan for the moment you suspect a compromise.
• A new CVE, an agent, and four questions →What to ask an AI agent about a CVE, and how to read the answer without being misled by it.