Security

Exploited Linux flaw and PHP2Shell: what website and VPS owners in Morocco should check

Read the step-by-step PHP2Shell guide →

On 28 October 2026, the US cybersecurity agency (CISA) added a Linux kernel flaw nicknamed "Fragnesia" to its list of exploited vulnerabilities. According to CISA, attackers chain it with PHP2Shell, the PHP flaw fixed on 21 October: first they get into the server through PHP, then they take full control (root) through the kernel. The day before, another kernel flaw, in TCP, had made the news. Here is what is established, who is affected and what to check.

In short

What happened

Fragnesia. Published on 13 May 2026 together with a proof of concept, it is rated 7.8 out of 10: an attacker must already be able to run code on the server to use it. That is exactly what PHP2Shell (CVE-2026-109618 and CVE-2026-109619) provides, and CISA listed it as exploited on 26 October. In its 28 October entry, CISA writes that Fragnesia "can be chained" with these two flaws "to implant PHP webshells and run commands as root". It gave US federal agencies a deadline of 31 October.

The actual attack was described on 26 October by the security company Dream. A single HTTPS request exploits PHP2Shell, then Fragnesia grants root; the attacker then leaves a booby-trapped PHP page (a "web shell") to come back at will. Dream says it found about 25 compromised systems in the United States, Japan, Taiwan and South Korea. An important detail: these were Palo Alto firewalls whose management interface was exposed to the internet, not websites. But nothing in the technique limits it to those devices: any Linux server running a vulnerable PHP on an unpatched kernel is open to the same chain.

CVE-2026-98432. This is a memory error in the kernel's TCP code, triggered while a connection is being opened, before any authentication. The kernel team rates it 9.8 out of 10; Red Hat, Oracle and SUSE rate it 8.1, because the race is hard to win. On 27 October, Anthropic published a research post: one of its AI models wrote, in a lab, an exploit that gives remote root access to a Linux server with an active multipath TCP (MPTCP) listener. The exploit has not been released and no real-world attack has been reported. It is no reason to panic, but it is a reason to apply the fix as soon as it arrives.

KSMBD. On 21 and 22 October, two flaws in the kernel's built-in SMB file-sharing server (ksmbd), rated 9.0 by the Zero Day Initiative, were made public before any fix: they only affect servers where this module is loaded, which is rare on a web server.

Who is affected?

How to check on a VPS

These commands change nothing: they only display information.

1. Which kernel is actually running?

uname -r

2. Is the Fragnesia fix in this kernel?

# AlmaLinux, Rocky, Red Hat
rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-46300

# Debian, Ubuntu
apt changelog linux-image-$(uname -r) | grep CVE-2026-46300

If a line appears, the fix is there. If nothing appears, check your distribution's advisory. For reference: on Red Hat 9, the fixed kernel is 5.14.0-687.10.1.el9_8 (20 May 2026) or later; on Ubuntu 24.04, 6.8.0-124 or later; on Debian 12, 6.1.174-1 or later. On an AlmaLinux 9 server I manage, kernel 5.14.0-687.59.1.el9_8 does contain the fix.

3. Is a reboot pending?

# AlmaLinux, Rocky, Red Hat
dnf needs-restarting -r

# Debian, Ubuntu
ls /var/run/reboot-required

If a newer kernel is installed but not yet loaded, the server is still running the old one.

4. Is MPTCP active?

sysctl net.mptcp.enabled
ss -Mln

The second command lists services listening over MPTCP. If it returns nothing, you are not in the case demonstrated by Anthropic. That does not mean you can skip the update: the official advisories do not say other servers are safe.

5. Is the ksmbd module loaded?

lsmod | grep ksmbd

No output: you are not affected by the KSMBD flaws.

What to do

  1. Update PHP, then restart PHP-FPM or Apache. The full method is in my PHP2Shell guide; I will not repeat it here.
  2. Update the kernel (dnf upgrade kernel* or apt upgrade), then reboot the server. This is the step most often forgotten: a server that has not rebooted since May may still be running a kernel vulnerable to Fragnesia, even if the fix is installed on disk.
  3. Look for suspicious PHP files in upload folders, where there should be none:
find /path/to/site/wp-content/uploads -name '*.php'

If you find something, do not just delete it: follow the "Was I compromised?" section of the guide.

  1. On shared hosting, write to support: "Have you applied the PHP fixes of 21 October 2026 and the kernel fix for CVE-2026-46300, and has the server been rebooted since?"
  2. For CVE-2026-98432, install the fixed kernel as soon as your distribution releases it, then reboot.

What we do not know yet

I will update this article when these points become clear.

Do you run a VPS and would rather have a professional take care of it? I offer server maintenance and monitoring. For a specific question, get in touch.

Sources

← All news