Fragnesia (CVE-2026-46300): Linux kernel flaw now exploited with PHP2Shell to root firewalls

CISA lists the Linux kernel flaw Fragnesia as exploited, and Dream Research reports it chained with PHP2Shell to root firewalls. Capture evidence before you reboot, then patch the kernel and PHP.

Why this matters now. Fragnesia (CVE-2026-46300) is a Linux kernel privilege-escalation flaw that was fixed upstream in May. CISA added it to the Known Exploited Vulnerabilities (KEV) catalogue on 28 October 2026, with a due date of 31 October, and notes that it can be chained with the PHP2Shell flaws to plant PHP webshells and run commands as root. Dream Research reports that an attacker used exactly that chain to root 24 firewalls and a firewall management server. Dream’s findings have not been independently confirmed by Tenable or TNW, so treat the campaign details as Dream’s account. The advice does not depend on them: find exposed Linux systems, capture evidence before you reboot anything, then patch the kernel and PHP.

What happened

Fragnesia was disclosed publicly on 13 May 2026, with a proof-of-concept exploit and a kernel patch. Tenable’s FAQ from that week said no exploitation in the wild had been reported. That has changed.

  • 26 October: Dream Research published a report on artefacts from a campaign that combined a custom, non-public PHP2Shell exploit with Fragnesia. Dream says the chain rooted 25 servers in the United States, Japan, Taiwan and South Korea: 24 firewalls running software from an unnamed “large vendor”, plus one internal firewall management server. Dream says the attacker worked through targets on 23 and 24 October, then pursued Active Directory in a US government-affiliated environment.
  • 28 October: CISA added CVE-2026-46300 to the KEV catalogue, based on evidence of active exploitation. The entry gives a due date of 31 October 2026 for US federal civilian agencies and lists ransomware campaign use as unknown. CISA’s description says the flaw “can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root”. CISA’s entry does not name Dream or cite its evidence.

The vulnerability itself is not new. The risk now is unpatched kernels, especially on long-lived appliances and servers that nobody has rebooted since May.

What Fragnesia is

Fragnesia is a local privilege-escalation flaw in the Linux kernel’s IPsec ESP-in-TCP code. When the kernel merges network buffers, it can lose the marker that says a piece of memory is shared with another part of the system. ESP processing then decrypts data in place over memory that is backed by the page cache, which is the in-memory copy of a file. The result is that a low-privileged local user can alter the cached copy of files they should only be able to read, and gain root. The on-disk file is not changed. Tenable notes that the public exploit relies on user and network namespaces, which most distributions enable by default.

NVD and Red Hat both score it 7.8 (High) on CVSS v3.1 and Red Hat rates it Important. It needs local code execution first, which is why the chain with PHP2Shell matters: PHP2Shell supplies remote code execution as the web server account, and Fragnesia turns that into root. In Dream’s account, SELinux stopped the web server account from altering system files directly, which is why the attacker added a kernel flaw.

Is the campaign confirmed?

  • CISA lists the flaw as exploited and describes the chain with PHP2Shell. That is the strongest public signal, and it is enough to treat the kernel flaw as actively targeted.
  • Dream’s campaign details come from Dream alone. Tenable says it has not independently confirmed the activity, and TNW says it has not independently verified Dream’s findings. SecurityWeek reports the same account.
  • Dream does not attribute the activity to a named actor. It says several indicators point to a Chinese-nexus operation, which is Dream’s assessment rather than confirmed attribution.
  • Dream has not named the firewall vendor or the affected versions, and says the vendor has been notified. It also says it could not determine how far the Active Directory compromise went.

Who is affected

Any Linux system running a kernel without the fix is potentially affected by the local flaw. NVD lists these upstream ranges:

Kernel line Affected (NVD) Fixed in
5.11 to 5.15 Before 5.15.208 5.15.208
5.16 to 6.1 Before 6.1.174 6.1.174
6.2 to 6.6 Before 6.6.141 6.6.141
6.7 to 6.12 Before 6.12.91 6.12.91
6.13 to 6.18 Before 6.18.33 6.18.33
6.19 to 7.0 Before 7.0.10 7.0.10
7.1 release candidates 7.1-rc1 to rc4 Not stated. Use a later build
3.9 to 5.10 Up to 5.10.257 No upstream fixed version shown. Use your distribution’s advisory

NVD’s record was still marked “Undergoing Analysis” when we checked on 29 October, so treat the ranges as provisional. Distributions backport fixes, so the kernel version number alone does not tell you whether you are patched. Go by your vendor’s advisory or package changelog:

  • Ubuntu: its tracker lists fixes in the main linux kernel for 26.04 LTS (7.0.0-22.22), 25.10 (6.17.0-35.35), 24.04 LTS (6.8.0-124.124) and 22.04 LTS (5.15.0-181.191). It lists 20.04 LTS and older as not affected. Derivative kernels such as HWE and cloud kernels have their own entries.
  • Debian: its tracker lists fixes in bullseye (5.10.257-1), bookworm (6.1.174-1) and trixie (6.12.90-1), with later security updates since.
  • Red Hat: RHEL 8, 9 and 10 are affected, and Red Hat says fixes have been released for all affected products. Layered products that use the RHEL kernel, such as OpenShift, depend on the underlying kernel being current.
  • Appliances: the reported targets were firewalls with PHP-based management interfaces. Vendors of firewalls, VPN gateways and similar devices need to confirm in writing whether their firmware includes both the kernel fix and the PHP fix.

Evidence first, then patch

CISA’s catalogue entry for this CVE shows “Forensic triage required per BOD 26-04: Yes”, and its required action tells organisations to comply with CISA’s “Forensics Triage Requirements” as well as the patching guidance. BOD 26-04 binds US federal civilian agencies. CISA encourages everyone else to adopt risk-based vulnerability management, so for other organisations this is good practice rather than an obligation.

CISA’s implementation guidance says to prioritise volatile data such as memory, to avoid altering or remediating systems before evidence is collected where possible, and to collect required evidence before patching because patching may destroy artefacts. It describes its timelines as best practice and says the requirement is that an adequate triage is performed.

That guidance matters for this flaw because the change lives in memory. Tenable notes that a reboot or cache flush restores normal behaviour, and that the file on disk is never changed. A disk image or backup of an affected host can therefore look clean while the running system does not. Getrff, a commercial endpoint tool vendor, describes comparing a normal read of a file with a direct read that bypasses the page cache, and says tools such as rpm -V, debsums and AIDE can see the altered version until the host reboots. We have not tested that approach, so validate it on a lab system first.

Do not let triage become a reason to leave exposed systems unpatched for days. For hosts that face the internet, do the evidence step first, then patch and reboot promptly. Where you cannot reboot yet, see the interim mitigations below.

What to do now

  1. Inventory exposure. List internet-facing Linux servers and appliances, especially those that run PHP or expose a web management interface. Take management interfaces off the internet where you can.
  2. Triage before you reboot. On exposed hosts you can access, follow your incident response process: capture volatile data and a memory image where you can, record what you collect, and check the sensitive files listed under “What to look for”. If anything looks altered, do not reboot, preserve evidence, and treat the host as compromised. Rebuild it rather than cleaning it.
  3. Patch the kernel. Install your distribution’s fixed kernel, or the vendor’s firmware update for an appliance, and reboot into it. Confirm the running kernel, not just the installed package.
  4. Patch PHP too. CISA added CVE-2026-109618 and CVE-2026-109619 to KEV on 26 October with a due date of 29 October. Breaking either link breaks the chain, but fix both. Our PHP2Shell guide covers fixed versions and hardening for runtimes you cannot update.
  5. If you cannot patch yet, use the vendor’s interim mitigations. Red Hat’s bulletin describes two, and both have a cost. Blocking the esp4 and esp6 modules stops IPsec working on that host. Disabling unprivileged user namespaces can break rootless containers, sandboxed browsers and Flatpak. Getrff notes that neither undoes tampering that has already happened, so triage first. The researchers who published the exploit note that a namespace restriction can be bypassed by chaining other bugs, so treat these as stopgaps.
  6. Reduce local attack surface. Keep web server accounts tightly confined, run services as non-root, and keep SELinux or AppArmor enforcing where your platform supports it.
  7. Hunt for follow-on activity. Dream reported credential extraction from the compromised devices and Active Directory enumeration. Review logs for unexpected root sessions, new accounts, new persistent services or outbound tunnels from appliances, and use of service accounts stored on those devices, such as LDAP bind accounts. Rotate stored credentials and keys if an appliance may have been compromised.
  8. Ask your vendors. If you run edge appliances with PHP-based management, get their PHP2Shell and Fragnesia status in writing.

What to look for

  • PAM configuration files, especially for su, whose authentication rules have been replaced with an accept-all pam_permit line. Dream reports this as the backdoor in its campaign. Distributions can use pam_permit legitimately, so compare against a known-good configuration rather than relying on a keyword.
  • Differences between the in-memory and on-disk versions of PAM files, sudoers, shadow and setuid-root binaries, found with the comparison described above.
  • Unexpected PHP files in web-accessible directories on appliances. Dream reports that the attacker left a PHP webshell with root access on each device.
  • Reverse SSH tunnels, new systemd services or boot-time script entries on appliances. Dream reports these were used to keep access to the government-affiliated network.
  • Unusual LDAP queries, failed sign-in spikes or attempts to create accounts in Active Directory from a firewall management server.

What we do not know yet

  • Which firewall vendor and versions were targeted.
  • How widely the chain is being used beyond the 25 servers in Dream’s artefacts. Dream also says the attacker did nothing beyond planting a webshell on 22 of the rooted firewalls, so a lack of follow-on activity does not mean a device was not rooted.
  • Whether other actors have adopted it. CISA’s entry confirms exploitation, but it does not say who is exploiting it or how.
  • How far the Active Directory compromise went. Dream says the artefacts it recovered do not show whether the password spraying, account creation or key theft attempts succeeded.

How PoCForge can help

If you want an independent view of which of your internet-facing Linux systems and appliances are exposed to this chain, or want your patching and triage checked, get in touch and we can scope an assessment with you.

Sources

PoCForge publishes offensive-security research to explain attack paths and defensive controls. This article summarises public advisories and reporting only; it is not an exploit guide and does not describe a named client engagement.