Skip to content
ITLAB
ESEN

31 / 10 / 2026 · From the lab

Server security in the AI era (part 2): the kernel flaw that turned PHP2Shell into full control

Part 2: Fragnesia (CVE-2026-46300), the Linux kernel flaw chained with PHP2Shell. What it is, patch status as of October 31, and what to do.

The second part of our series on server security. In part 1 we described how attackers chained PHP2Shell with "a second flaw" to take full control of 25 devices. That second flaw is in the Linux kernel, the core of the operating system, and it's called Fragnesia. This article explains what it is, where patching stands as of October 31, 2026, and what to do. We'll update it as its status changes.

What Fragnesia is

Fragnesia is a Linux kernel vulnerability tracked as CVE-2026-46300. William Bowling of V12 Security disclosed it on May 13, 2026, together with a proof-of-concept exploit and a patch, according to Tenable and CloudLinux.

  • Where it is. In a part of the kernel that handles IPsec encrypted traffic encapsulated in TCP (the module known as ESP-in-TCP).
  • What it allows. It's a local privilege escalation: someone who has already managed to run code as an unprivileged user can become administrator (root) of the machine. According to Ubuntu's advisory, it could also allow escaping a container.
  • Severity. CVSS 3.1 score of 7.8 (high), according to the records cited by Rescana and Safeguard.
  • Public exploit. Available since the day it was disclosed.

On its own, Fragnesia can't be used to break into a server from the internet: it needs a foothold first. That's the role PHP2Shell played.

Why it matters now

A "local only" flaw often looks less urgent. This case shows why it isn't: chained with a flaw that grants remote access, such as PHP2Shell, it completes the attack chain.

  • The chain has already been used. According to the firm Dream, whose findings Palo Alto Networks' Unit 42 verified according to The Register, the attackers got in with PHP2Shell and used Fragnesia to gain full control of 25 devices.
  • Confirmed exploitation. The US cybersecurity agency (CISA) added it to its catalog of actively exploited vulnerabilities on October 28, 2026, giving federal agencies until October 31 to fix it. According to Rescana and Safeguard, CISA explicitly mentions its use alongside the PHP flaws.

Patch status as of October 31, 2026

The fix has existed in the official kernel since May, and most distributions have shipped it. But it isn't closed everywhere.

  • Official kernel. Fixed in stable branches 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 and 7.0.10, among others, according to Rescana and Safeguard, citing the official CVE record.
  • Ubuntu. According to its tracking page, updated October 29, the main kernels for 22.04, 24.04, 25.10 and 26.04 have a fixed version (for example, the 24.04 generic kernel from version 6.8.0-124 and the 26.04 one from 7.0.0-22); 20.04 and earlier, on their standard kernel, aren't affected. However:
  • some 24.04 kernel variants based on version 6.14 are listed as "end of life" and won't get the fix: you need to move to a supported variant;
  • at least one specialized 24.04 variant is still listed as "vulnerable, work in progress".
  • Ubuntu also notes that Fragnesia should be fixed together with a related flaw, Dirty Frag (CVE-2026-43284).
  • Red Hat and Debian. Shipped fixed kernels between May and June, according to Rescana.

The practical takeaway: the patch exists for almost everyone, but "exists" doesn't mean "applied". A fixed kernel only protects a machine once it boots into it.

Why a kernel patch is different

In part 1 we explained that installing an update isn't enough: you have to check what's actually running. With the kernel that's even clearer.

  1. It needs a reboot. The new kernel gets installed, but the machine keeps using the old one until it restarts. Many servers spend weeks with a fixed kernel installed and a vulnerable one running.
  2. Rebooting has a cost. Stopping a server takes a maintenance window and a rollback plan. Live patching systems apply fixes without a reboot, but they don't cover every kernel or every case.
  3. Variants and vendors. Clouds and hardware makers use their own kernel variants, which get fixes on their own schedule.
  4. End of life. A kernel or OS release without support simply doesn't get the patch.

What to do

  1. Check the running kernel, not just the installed one, and compare it with the fixed version your distribution lists.
  2. Update and reboot in a planned window, with a backup and a way back.
  3. If you can't reboot right away, evaluate the live patching your distribution or vendor offers.
  4. Temporary mitigation until the patch lands: block the affected modules (esp4, esp6 and rxrpc) from loading, according to Tenable and CloudLinux. It has side effects: IPsec stops working (site-to-site VPNs with strongSwan or Libreswan), as do AFS clients. CloudLinux warns not to apply it on hosts that terminate or carry IPsec tunnels.
  5. Close the front door. Keeping PHP and web applications up to date makes it less likely anyone gets to use Fragnesia.
  6. Migrate what's out of support. An unsupported kernel or OS will stay exposed to this flaw and the next ones.
  7. If you suspect a compromise, preserve evidence before rebooting: according to Rescana and Safeguard, the tampering this exploit performs lives in memory and disappears on reboot.

What to ask your IT provider

  • Which kernel version is running on our servers today, and is it fixed against Fragnesia and Dirty Frag?
  • When was the last reboot after a kernel update?
  • Do you use live patching? What does it cover and what doesn't it?
  • Are any servers on an out-of-support OS or kernel? When will they be migrated?
  • If you applied temporary mitigations, do they affect any VPN or service?

Frequently asked questions

Can Fragnesia be used to break into my server from the internet? Not on its own. The attacker needs an initial foothold first, for example through a web flaw like PHP2Shell. That's why it's used in a chain.

Is there a patch yet? Yes for most kernels and distributions, since May 2026. Some kernel variants are still unfixed or out of support.

I installed the updates. Am I protected? Only if the machine rebooted into the fixed kernel or a live patch covered the flaw. You have to check the running kernel.

Does the module-blocking mitigation carry risks? Yes: it breaks IPsec and AFS. Assess it case by case and remove it once the patch is applied.

Update note

This article reflects the public status as of October 31, 2026. We'll update it when the pending fixes for the remaining kernel variants are released or the flaw's status changes.

Sources

More in this series

Contact

If you'd like to review the kernel and patch status of your organization's servers, ITLab can help. Contact us.

Do you need someone to take care of your technology?

Tell us what you need to organize, protect or solve. The first conversation has no cost: we assess whether our model fits you and what the next steps would be.

Let's talk about your business