Exploited Linux Kernel Flaw: Is Your Server at Risk?

What matters now

CVE-2026-46300 is a flaw in the Linux kernel's networking code. When the kernel merges network buffers, it can lose a marker that says some of the data is backed by shared memory. IPsec's ESP input code then decrypts in place over those pages, including the kernel's cached copies of files. In practice a low-privileged local user can alter what the system sees when it reads a protected file, such as a setuid program, and climb to root. Ubuntu rates it High, Red Hat rates it Important and the CVSS v3.1 score is 7.8.

On 28 October 2026 CISA added it to the KEV catalogue with a federal due date of 31 October 2026. CISA's entry says the flaw can be chained with CVE-2026-109618 and CVE-2026-109619, the PHP vulnerabilities covered in our earlier PHP security note, to implant PHP webshells and run commands as root. CISA lists known ransomware use as Unknown.

The bug itself needs local access, so it is not a way in from the internet. The risk is what it does after something else has gone wrong. A compromised website, a stolen low-privilege login or a hostile workload on a shared host would normally be contained. This bug can remove that containment.

Information is still developing. The flaw was publicly disclosed on 13 May 2026, with exploit code published at the time, and fixed kernels have been shipping since. What is new is CISA's confirmation of exploitation. As of 29 October 2026 we have not located public detail on who is exploiting it or against whom, and we name no victims.

Which systems to check

Any Linux system running a kernel without the fix is affected in principle, and Tenable notes the exploit does not rely on a race condition. The technique uses user and network namespaces to gain the capability it needs, and those are enabled by default on most distributions. Ubuntu also notes that a local attacker could possibly escape a container. Check in this order: servers that run internet-facing web applications (especially PHP), shared or multi-tenant hosts, container and Kubernetes nodes, CI build runners and anywhere staff or contractors have shell access. A single-purpose appliance nobody can log in to is lower priority, though it still wants updating.

Distributions backport fixes, so compare against your vendor's advisory rather than the upstream version number. These are the fixed builds we could confirm from vendor pages:

• Ubuntu `linux` package: 26.04 LTS 7.0.0-22.22, 25.10 6.17.0-35.35, 24.04 LTS 6.8.0-124.124, 22.04 LTS 5.15.0-181.191. Ubuntu lists 20.04 and older as not affected, and cloud-specific kernels (aws, azure, gcp and others) have their own fixed versions on Ubuntu's CVE page.
• Debian: bullseye 5.10.257-1, bookworm 6.1.174-1 (or later) and trixie 6.12.90-1 (or later), per Debian's security tracker. Check the tracker for the exact build on your release.
• Red Hat Enterprise Linux 8, 9 and 10 are affected and Red Hat reports fixes released. We could not retrieve the per-release package versions, so take those from the Red Hat CVE page for your release.
• AlmaLinux 8, 9 and 10 have shipped fixed kernels. Amazon Linux was reported by Tenable in May as not shipping the espintcp module and so not affected. Confirm that with Amazon's own advisory before relying on it.

1. Make a list of the Linux machines you are responsible for, including virtual machines, container hosts and cloud instances. Managed hosting and platform services are the provider's to patch, so ask them for written confirmation of their status.
2. On each machine, show the running kernel. This is read-only and any user can run it.
   bashCopy

   uname -r

3. On Debian and Ubuntu, list installed kernel packages and compare them with the fixed version for your release. The installed package version is what counts, not the shorter string above.
   bashCopy

   dpkg -l 'linux-image*' | grep ^ii

4. On Red Hat-family systems, list installed kernel packages and compare them with the version in your vendor's advisory.
   bashCopy

   rpm -q kernel

5. Remember the running kernel is what matters. A fixed package that is installed but not yet booted into protects nothing.

Install the fixed kernel

Installing a fixed kernel is the real answer. Ubuntu is explicit that the workaround in the next section is only for systems that cannot update. The reboot is the disruptive part: services on that machine will be unavailable while it restarts, so schedule it, take web servers out of any load balancer first and do not reboot a machine you suspect is compromised until you have read the section on checking for compromise below.

1. You need administrator (sudo) rights on the machine. On Debian and Ubuntu, refresh the package lists.
   bashCopy

   sudo apt update

2. Install the available updates. Ubuntu recommends a full upgrade; if you can only update the kernel, follow the targeted method in Ubuntu's published guidance. On Red Hat-family systems apply the vendor kernel erratum through your normal update process.
   bashCopy

   sudo apt upgrade

3. Reboot into the new kernel in your agreed maintenance window. Unattended upgrades may have downloaded the update already, but a reboot is still needed before the fix takes effect.
   bashCopy

   sudo reboot

4. After the machine returns, run the kernel check again and compare the result with the fixed build for your distribution. If it still shows the old kernel, the machine booted the old entry and needs looking at before you call it done.
   bashCopy

   uname -r

If you cannot patch yet: block the ESP modules

Red Hat's bulletin for the related Dirty Frag flaws, which Ubuntu's page for this CVE also points to, describes stopping the esp4 and esp6 kernel modules from loading. Tenable states that systems which already applied this for Dirty Frag are protected against this bug too. It is a stopgap, not a fix.

The cost is real. esp4 and esp6 carry IPsec ESP traffic, so blocking them breaks IPsec VPNs and tunnels (strongSwan is the example Ubuntu gives). Check first. Red Hat's guidance is that if the modules are loaded and you use IPsec, do not simply block them. Red Hat describes a different workaround that disables unprivileged user namespaces, but that can affect rootless containers, sandboxed browsers and Flatpak, so read its bulletin and test before using it. Neither workaround removes every local route to root, so keep the patch on the list.

You need root or sudo, and the changes below persist across reboots until you remove them.

1. See whether the modules are in use. No output suggests IPsec is not active on this machine. Output means the modules are loaded, so work out whether you rely on IPsec before going further.
   bashCopy

   lsmod | grep -E 'esp4|esp6'

2. Create a modprobe configuration that refuses to load both modules. The file name follows Red Hat's guidance. It changes how the kernel handles those two modules from now on and does not alter running IPsec connections by itself.
   bashCopy

   printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf

3. Unload the modules if they are currently loaded. The command refuses to unload a module that is in use, which protects a running tunnel, but it also means the block is not yet in effect for that module until the next reboot.
   bashCopy

   sudo rmmod esp4 esp6

4. On Debian and Ubuntu, regenerate the initramfs so the block also applies in early boot. This is what Ubuntu advises. Red Hat-family systems do not need this step in Red Hat's guidance.
   bashCopy

   sudo update-initramfs -u -k all

5. Confirm the result. You should see the message that the modules are not loaded. If they are still loaded, a reboot is needed for the block to take hold.
   bashCopy

   grep -qE '^(esp4|esp6) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

6. Once the fixed kernel is installed and running, remove the workaround so IPsec works again. On Debian and Ubuntu, regenerate the initramfs afterwards.
   bashCopy

   sudo rm /etc/modprobe.d/dirtyfrag.conf

   bashCopy

   sudo update-initramfs -u -k all

Patching does not tell you whether it was already used

Tenable reports that the public exploit changes the cached copy of a file in memory and leaves the file on disk untouched. A reboot clears that cache, so a patched and rebooted machine can look clean even if the bug was used beforehand. What an attacker did with root access in the meantime, such as dropping files, adding accounts or planting persistence, stays behind.

CISA's directive BOD 26-04 requires US federal agencies to carry out forensic triage on KEV additions like this one, and its guidance says to avoid altering systems before evidence is collected where possible. It does not bind UK organisations, but it is a sensible model for any server you think may have been touched. Our judgement: for an ordinary patch-and-reboot of a server with no warning signs, do it. For one you have a reason to doubt, preserve logs and a snapshot first, then patch.

Reasons to doubt include a website on that server that was vulnerable to the PHP2Shell flaws before it was updated, or signs such as:

• PHP or other script files in web directories that nobody on your team put there.
• User accounts, SSH keys or scheduled jobs you cannot explain.
• Unexpected processes running as root, or outbound connections from a web server that it does not normally make.
• Authentication or web-server logs showing odd activity around the time the server was last exposed.

Real-world reporting

CISA's KEV entry is evidence of exploitation. It is not an identification of victims, and we have not found a public organisational disclosure tying this specific CVE to an incident. CISA's own wording on chaining it with the PHP vulnerabilities is the only attack pattern we can currently cite, and we have not independently observed it. Treat 'exploited' as meaning 'prioritise this', not 'assume you were hit'.

How to know you are finished

For each Linux system in scope you should be able to show that the running kernel is the vendor's fixed build, that any temporary module block has either been removed or consciously kept because you do not use IPsec, and that anything you could not patch has an owner, a date and an interim decision. For servers with a reason for doubt, record that someone looked for the signs above and what they found.