One week after PHP2Shell: attacked in the wild, and now a Linux kernel flaw on top

On 21 October the PHP team released emergency updates for two critical flaws, CVE-2026-109618 and CVE-2026-109619 (“PHP2Shell”). Back then the question was how fast you could patch. A week later the question has changed: were you attacked in the meantime, and what can an attacker do once PHP is breached?

What happened since 21 October

• Attacks started before the patches. According to reports (Amazon Threat Intelligence, among others), exploitation began about four days before the fixed versions were released. Honeypot data later confirmed successful attempts, for example against Apache with mod_php on PHP 8.4.26.
• CISA confirmed it on 26 October. Both PHP flaws are in the Known Exploited Vulnerabilities catalog, with a deadline of 29 October for US federal agencies. The listing does not say how many production systems were actually breached.
• The scale is large. TU Delft's threat intelligence lab has reportedly tracked more than 50,000 exploitation requests from over 600 IP addresses in 70 countries. One researcher found signs of exploitation for CVE-2026-109618 but none for CVE-2026-109619, so the two are not equally dangerous in practice. Patch both anyway.
• Early “successful breach” reports were partly premature. Be careful with numbers of compromised servers: nobody has a reliable count yet.

The new part: from PHP to root

On 28 October CISA added CVE-2026-46300, a Linux kernel flaw nicknamed “Fragnesia”. It is a local privilege escalation in the kernel's ESP-in-TCP code that lets an unprivileged user change the page cache of files they may only read. Public exploit code reportedly targets the cached copy of /usr/bin/su, so the next run of that program executes attacker code as root.

CISA's entry says this flaw can be chained with the two PHP flaws to implant PHP web shells and run commands as root. That is the point for server admins: PHP2Shell alone gives an attacker the rights of the web server user. With the kernel flaw on top, a vulnerable server is not just a defaced website but a fully taken-over machine, with every other site and every secret on it.

CISA does not say how widely the chain is used, and the entry lists ransomware use as unknown. The kernel flaw was disclosed in May and affects kernels built before 13 May 2026, so many servers that were patched regularly already have the fix. Servers that are never rebooted do not.

Is this a one-off?

No. CISA adds 8 entries a week on average, between 3 and 14 since August. What is unusual this week is that four of the eight are software you run on your own server: PHP twice, the Linux kernel and GitLab. The catalog is a good, free early-warning list. I publish every new entry on a page of its own, with what to check: actively exploited vulnerabilities.

Check in 15 minutes

1. PHP: which version runs, in which form? Fixed are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Web server and command line can use different PHP versions.

php -v
php-fpm -v 2>/dev/null || ls /usr/sbin/php-fpm*
apachectl -M 2>/dev/null | grep -i php      # mod_php

The details for Plesk, Synology, shared hosting and Docker are in the patch guide. If you cannot patch today, the php.ini workaround reduces the risk.

2. Kernel: is the fix installed and running? Installing is not enough, the new kernel only counts after a reboot.

uname -r
# Debian / Ubuntu
apt list --upgradable 2>/dev/null | grep -i linux-image
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required
# RHEL / Alma / Rocky
dnf updateinfo list security | grep -i kernel
needs-restarting -r

Your distribution's security advisory for CVE-2026-46300 tells you the fixed package version. I do not list kernel version numbers here because they differ per distribution.

3. Can't reboot yet? Reported interim measure. Reports recommend blocking the modules esp4, esp6 and rxrpc. This breaks IPsec and AFS. Check first whether you use them:

lsmod | grep -E 'esp4|esp6|rxrpc'
ip xfrm state | head
# only if you do NOT use IPsec/AFS:
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/block-esp.conf
sudo modprobe -r esp4 esp6 rxrpc

4. Look for web shells. Recently changed PHP files in the web roots, and the typical one-line shells:

find /var/www -name '*.php' -mtime -10 -ls 2>/dev/null
grep -rlE '(eval|assert|system|passthru|shell_exec)[[:space:]]*\([[:space:]]*\$_(POST|GET|REQUEST|COOKIE)' /var/www 2>/dev/null

Legitimate updates also show up in the first list, so read it, do not just count it. For the kernel flaw, check that the system binaries are untouched (dpkg -V util-linux on Debian and Ubuntu, rpm -V util-linux on RHEL). The output should be empty. A reboot or a kernel update clears a corrupted page cache; reports also mention dropping the cache (echo 3 | sudo tee /proc/sys/vm/drop_caches) after mitigation.

If you find something

Treat it as a compromise, not as a file to delete. A web shell with a kernel exploit behind it can have given root. Isolate the server, keep logs and disk image for the analysis, restore from a clean backup, rotate all secrets that were on the machine (database passwords, API keys, SSH keys, .env files) and patch before the machine goes back online.

What I would do today

• Patch PHP everywhere, including the PHP of the command line, cron jobs and containers.
• Install the kernel update and plan the reboot. A kernel patch that waits for “the next maintenance window” is an open door on a server that is already being attacked through PHP.
• Look at the logs back to 17 October, not to the day of your own patch.
• Reduce what PHP may do: disable_functions for exec, system, passthru, shell_exec where the application does not need them, and separate pools per site. It does not replace the patch but makes the chain harder.

Sources: Recorded Future, BleepingComputer, SOC Prime and CISA's Known Exploited Vulnerabilities Catalog. Status 30 October 2026; numbers come from the cited reports and the CISA feed and may change.