Skip to content
Knowledge Hub/Guide
Guide

PHP2Shell: A 5-Step Checklist for the Critical PHP Vulnerabilities

What to do today about CVE-2026-109618 and CVE-2026-109619 (CVSS 9.2): inventory, patch and restart, isolate, WAF rules, log review. Fixed versions inside.

Oğuzhan Gerçek··8 min read
PHP2Shell: A 5-Step Checklist for the Critical PHP Vulnerabilities

Short answer: On 21 October 2026 the PHP project released security updates for two critical vulnerabilities publicly known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2): 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The flaws allow code execution on the server with a single unauthenticated HTTP request and are triggered before the request reaches application code, so the login screen of your application does not protect you. Exploitation attempts have begun, and four EU countries plus Canada temporarily took some government websites offline. Five things to do today: inventory your PHP installations, patch and restart PHP, disconnect anything you cannot patch, enable WAF rules as a stopgap, and review your logs back to 17 October.

What happened

As Help Net Security reports, the PHP team released emergency security updates on 21 October 2026 and strongly urged all users to update immediately. The technical core of the two flaws: in CVE-2026-109618, an out-of-memory condition interrupts PHP while request data is only partly initialized, and the cleanup stage then treats the invalid data as valid; in CVE-2026-109619, request-owned internal state survives after its memory is freed and can be used by a later request on the same worker. Datadog Security Labs built a working exploit before public disclosure: a single unauthenticated HTTP POST request executes code while bypassing ASLR; application-level authentication offers no protection, because PHP processes the request before application code runs.

The timeline:

  • 17 October: According to Help Net Security, Amazon's honeypot network (MadPot) recorded an exploitation attempt four days before public disclosure.
  • 20 October: The flaws leaked on social media. According to The Next Web, CERT-EU, the cybersecurity team for the EU institutions, published advisory 2026-018 advising organisations that cannot patch quickly to isolate internet-facing applications from public networks, and to take websites offline if necessary; Australia's ACSC issued similar guidance.
  • 21 October: The patches were released; the PHP team moved the release up by a day after the leak. watchTowr observed exploitation attempts on its honeypot network the same day. As Engadget reports, citing Reuters, the Netherlands, Denmark, France and Finland took down some government websites as a precaution, and the Canadian government temporarily took its sites offline. In the US, CISA urged organizations to apply the patch.

Who is affected

Every PHP installation that serves web requests. According to Help Net Security's list, PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are all in scope, with mod_php setups facing the greatest danger. The application does not matter: WordPress, Drupal, Joomla, Magento and every custom PHP application. In the words of Tiffany Farriss, interim CEO of the Drupal Association, quoted by Engadget, servers running any version of PHP released in the last 20 years are vulnerable.

Version status (21 October 2026):

  • 8.5, 8.4, 8.3, 8.2: Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35 respectively.
  • 8.1, 8.0 and 7.4: No longer supported by the project; only minimal source backports were published for those who build from source. Check your distribution's or your long-term support (LTS) vendor's packages; according to Help Net Security, Linux distributions received the patches before the public release.
  • PHP 5: No patch. A system still running it must be disconnected from the internet and migrated.

How an exploit works, and the difference between zero-days and n-days, is in the exploit article; why the patch window has to be measured in hours is in the patch management article.

The 5-step checklist

1. Take inventory

A system you cannot patch is a system you do not know about. On every server, list which PHP version runs and how:

php -v                      # CLI version
php-fpm -v                  # FPM version (php8.3-fpm -v on some distributions)
dpkg -l | grep -i php       # Debian/Ubuntu packages
rpm -qa | grep -i php       # RHEL/Rocky/Alma packages

If you use containers, check the image tags (such as php:8.3-fpm); if you use managed hosting, ask your provider which version you are on and when it will be patched. Flag the internet-facing systems first; they come first.

2. Patch and restart PHP

Updating the package is not enough; running PHP-FPM workers and Apache processes with mod_php loaded keep executing the old code in memory.

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade 'php8.3*' && sudo systemctl restart php8.3-fpm apache2
# RHEL/Rocky/Alma
sudo dnf update 'php*' && sudo systemctl restart php-fpm httpd

In container environments, pull the patched image tag and redeploy. According to Help Net Security, the widely used Remi repository had no update available at release time; its users were advised to switch to distribution packages or build from source. After patching, confirm that php -v shows the new version and that the processes have restarted.

3. Disconnect what you cannot patch

This is the advice of CERT-EU and the UK NCSC: a system that cannot be patched promptly is isolated from the public network. A temporary outage is cheaper than a compromised server; four countries did it for their government sites. PHP 5 and the 7.x/8.0/8.1 installations without a patched package are the main addresses of this step. The way to isolate is to block 80/443 traffic to that server at the firewall or to remove it from the load balancer pool, not to shut the server down, because you will need its logs.

4. Enable WAF rules as a stopgap

According to Help Net Security, Cloudflare deployed WAF rules for the known exploit vectors to all customers including the free plan, and other providers are publishing rules too. A WAF does not replace the patch; it narrows the door while you patch. Datadog's warning matters: the session.upload_progress.enabled=0 setting suggested in the community does not protect you; the only real fix is the patch. What a WAF can and cannot do is covered separately.

5. Review the logs back to 17 October

Datadog's detection guidance: unusually large form submissions, memory-exhaustion errors during request initialization, and unexpected shell processes spawned by PHP processes. A successful exploit may not crash the worker, so the absence of errors does not mean you are safe. Scan your web server and PHP-FPM logs, and your EDR and SIEM records if you have them, from 17 October onward, when the first exploitation attempt was seen. If you find a suspicious trace, preserve the logs before shutting anything down and start your incident response process; the first-hour steps in the ransomware recovery playbook apply here too.

If you use a managed service

Ask your provider three questions: which version are we on, when was the patch applied, and were the PHP processes restarted. If the answer is "we updated", ask the second and third questions anyway; the patched package may be installed while the old process is still running. On our side, patching, vulnerability scanning and 24/7 monitoring are the subject of the patch and vulnerability management and security operations services.

Frequently asked questions

What is PHP2Shell? The public name for two critical PHP vulnerabilities patched on 21 October 2026 (CVE-2026-109618 and CVE-2026-109619). Both are CVSS 9.2 and allow code execution on the server with a single unauthenticated HTTP request.

Which PHP versions are affected? Every version that serves web requests. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; 7.4, 8.0 and 8.1 only have source backports; there is no patch for PHP 5.

Is updating the package enough? No. Unless PHP-FPM and the web server are restarted, the old code keeps running in memory. After updating, confirm the version with php -v and the restart through the service status.

Is my WordPress site affected? Yes. The flaw is in PHP itself, not in WordPress; WordPress, Drupal, Joomla, Magento and custom PHP applications are all in the same position. It is the PHP on the server that needs updating, not a plugin.

How do I know if I have been attacked? Unusually large form submissions, memory errors at the start of a request and unexpected shell processes spawned by PHP are the indicators. Look back to 17 October; a successful exploit may produce no error at all.

What does a source backport mean? For the unsupported 7.4, 8.0 and 8.1 branches, the PHP team published a minimal fix that people who build from source can apply, not ready-made packages. Those on packages should wait for their distribution's or LTS vendor's patched package, or move to a supported version.

Sources