How to check your server has the php2shell patch

On 21 October the PHP team released 8.2.35, 8.3.36, 8.4.27 and 8.5.12, the php2shell patch for CVE-2026-109618 and CVE-2026-109619. Both flaws let an attacker run code on the server without logging in, and both are now being exploited. If your site or online shop runs on PHP, check this week that the process actually serving it has the fix.

In short

• The flaws are being exploited, so patch now rather than at the next maintenance window.
• After updating, restart PHP-FPM or Apache, and rebuild your container images.
• The PHP team ships fixes for PHP 8.2 only until 31 December 2026.

The flaws are already being exploited

News of the flaws and the release date leaked the day before the planned release. According to The Hacker News, watchTowr reported active attack attempts just 19 minutes after the patches went out, and by early on 22 October Cloudflare had counted millions.

On 26 October BleepingComputer reported a confirmed successful takeover. It happened on a honeypot running Apache with mod_php and PHP 8.4.26, and the researcher Marcus Hutchins confirmed the finding independently. A day earlier Aviatrix described a breach at an unnamed European government body, where the attackers left a web shell on an unpatched server to keep their access.

Servers running mod_php in Apache are the most exposed, but PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected too. With millions of attempts, any unpatched PHP server can expect this traffic, small ones included.

What to check this week

An installed package is not enough on its own. Go through these in order:

1. The package version, not the output of php -v. Ubuntu 24.04 backported the fix into its own PHP 8.3.6, so php -v still says 8.3.6. The fix is in package 8.3.6-0ubuntu0.24.04.13 or newer. Debian 12 has 8.2.35, and RHEL 9 got the same version in RHSA-2026:87072.
2. A restart. PHP-FPM workers and Apache with mod_php keep the old code in memory until you restart them.
3. Containers. Updating the host does not change the PHP inside your image, so rebuild it with docker build --pull and deploy it. If your Dockerfile pins a version such as php:8.2.34-fpm, bump that first.
4. Hosting. On shared hosting the provider patches PHP, so ask them whether the fix is in. As Malwarebytes points out, updating WordPress does not update PHP, which is a separate engine the site runs on.

The commands for PHP from Ubuntu 24.04 and RHEL 9 packages:

# Ubuntu 24.04 (Debian 12: replace 8.3 with 8.2, package 8.2.35-1~deb12u1 or newer)
dpkg-query -W php8.3-fpm   # 8.3.6-0ubuntu0.24.04.13 or newer
sudo ls -l /proc/$(pgrep -o php-fpm8.3)/exe
sudo systemctl restart php8.3-fpm

# RHEL 9, php:8.2 module
rpm -q php-fpm   # 8.2.35 or newer
sudo ls -l /proc/$(pgrep -o php-fpm)/exe
sudo systemctl restart php-fpm

If the path ends in (deleted), the process is still running the version from before the update and needs a restart. With mod_php you restart Apache itself: systemctl restart apache2 on Debian and Ubuntu, systemctl restart httpd on RHEL.

PHP 8.2 gets fixes until 31 December

According to the PHP support schedule, security fixes for PHP 8.2 end on 31 December 2026. If a similar flaw turns up in January, the PHP team will not release a fixed 8.2, so the official Docker images will not get one either. That is what happened this week to PHP 8.1 and older, which got only source patches.

Debian, Red Hat and some hosts backport fixes to older versions, but on their own schedules. If your 8.2 comes from their packages, ask how long they will keep shipping fixes. If it comes from php.net or the official Docker image, plan the move before the end of the year. I would go straight to 8.4, which gets fixes until the end of 2028, a year longer than 8.3. Staging first, then production.

Who decides when you cannot patch straight away

Sometimes the update has to wait. Then someone has to choose between a workaround and taking the service offline. A workaround means, for example, turning off session.upload_progress.enabled, lowering the request size limit or adding a WAF rule. It does not replace the patch, but it shortens the time the server is an easy target. Some companies took their sites offline for a few hours, and that was a sensible call.

Write down on a single page who makes that decision in your company, how to reach them quickly, which services can go offline without much harm and who does the update itself. My maintenance service includes alerts and a response in business hours, and I handle critical incidents in the evening too.