PHP2Shell: What PHP Site Owners Should Do Today

On 21 October 2026, as scheduled, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. Every PHP installation that serves web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP security team rates both 9.2 out of 10 (CVSS v4.0) and considers the risk highest for mod_php, where a demonstrated exploit runs before any application code.

In practice, anyone who can reach your site like an ordinary visitor, with no account or password, could run their own commands on your server: read the database, steal passwords and API keys, change pages or install malware. The bugs sit in PHP, the language Drupal and WordPress run on, so updating Drupal or WordPress will not help. PHP runs 69% of websites whose server-side language W3Techs can identify, and the researchers demonstrated attacks against Drupal, WordPress and Joomla. They say temporary web firewall rules do not replace the PHP update.

If a host or developer runs your site, ask them today whether PHP has been updated. At Tag1 we have been updating client servers all day, and we made sure Drupal.org, whose infrastructure we manage, is patched.

What to do now

If a host or developer runs your server, start with them. Ask which PHP version is running and when PHP was restarted, then use the checks below.

Otherwise, update PHP. This is the only complete fix. I would patch mod_php servers first; where no patched build exists yet, use the stopgaps below. As of 18:25 UTC on 21 October:

• Ubuntu has published USN-8948-1 for 22.04, 24.04, 26.04 and 26.10, and USN-8948-2 for 14.04 to 20.04 through Ubuntu Pro.
• Debian has published DSA-6574-1 for trixie and, through Debian LTS, DLA-4848-1 for bookworm.
• Docker Hub has fixed images for all four branches on the main architectures, and latest now points at them. Pull fresh and rebuild; running containers keep the old PHP.
• The Remi repository carries the fixed releases for Enterprise Linux 9 (for example 8.4.27).
• Ondřej Surý's deb.sury.org repository is publishing the fix for every branch from 5.6 to 8.5, amd64 first. The ppa:ondrej/php PPA has the fix for every branch on amd64 for Ubuntu 22.04 and 24.04, but some arm64 and ppc64el builds were still pending, so check that apt installed a new PHP package.

Then restart PHP. After the update, restart Apache (for mod_php), PHP-FPM and any long-running PHP processes.

To confirm, check the version your site reports: Drupal shows it on its status report and WordPress under Tools > Site Health > Info > Server. Builds from php.net show the new number. Distribution packages often keep the old one: Ubuntu 24.04's fixed package is 8.3.6-0ubuntu0.24.04.13, yet the site still reports 8.3.6. There, check the installed PHP packages (for example dpkg -l | grep php) against your distribution's notice, or ask whoever runs the server to.

If you run PHP 8.1 or older, plan the upgrade. The PHP project no longer releases those versions, but its security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves. deb.sury.org, listed above, packages the fix for 5.6 through 8.1. When you do upgrade, skip 8.2: it reaches end of life on 31 December 2026.

If you cannot update today

The PHP project's advisory lists stopgaps that reduce exposure to specific attack paths. They are a bridge to the update, not a fix. Restart every PHP worker after applying them:

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the Apache configuration. Do not rely on ini_set() or FPM .user.ini files.
• Set memory_limit=-1 with php_admin_value so applications cannot override it, and put a container or cgroup memory limit in its place. This blocks only one route to CVE-2026-109618. Do not use RLIMIT_AS or RLIMIT_DATA for the replacement limit.
• Cap post_max_size at 8M if you accept no uploads, or 32M if you do, and keep upload_max_filesize below it.
• On PHP 8.5, also set fatal_error_backtraces=0.

After you patch

Patching does not tell you whether anyone got in first. The researchers list signs to look for, such as oversized PHPSESSID cookies, memory limit errors after multipart requests, and unexplained worker crashes. They add that none of these proves or rules out an attack. I would also look for PHP files in the web root that you did not deploy, and for new cron jobs and accounts. Because CVE-2026-109619 can leak process memory even if the attacker never gains code execution, I would rotate the database password and API keys on any internet-facing server that ran an affected version.

Thank you to the PHP security team, who shipped fixes for four branches and backports for three unsupported versions. The status list above is a snapshot from 18:25 UTC on 21 October, so check the linked sources for anything newer.

• DevOps
• Drupal
• Infrastructure
• Ongoing Support
• Open Source CMS
• Security
• WordPress