On 21 October 2026 the PHP project shipped emergency releases for two critical vulnerabilities in the PHP interpreter itself. The bugs, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, are rated 9.2 under CVSS v4.0 and can let an unauthenticated attacker run code on the server with the privileges of the web server account. Details leaked before the planned coordinated disclosure, so the release was brought forward and administrators had very little warning.
This article explains what is affected, which versions fix it, and the order of work we followed on the servers we manage.
What the two vulnerabilities are
Both issues sit in PHP’s request lifecycle, not in any framework or application code. That is the part that makes them unusual: updating WordPress, Magento, Laravel or your own code does nothing here. The PHP binary has to be updated.
- CVE-2026-109618 concerns how PHP handles out-of-memory conditions. An out-of-memory error can interrupt PHP while internal request data is only partly initialised, and request cleanup can then treat that data as valid.
- CVE-2026-109619 concerns request-owned internal state that can survive after its memory has been freed. A later request handled by the same worker process may use that stale state before normal initialisation resets it.
According to the published analyses, a single crafted request can be enough, and it is processed before any application code runs. Authentication, login pages and application firewalls inside your code do not stand in the way.
Who is affected
Every way of serving PHP over the web is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers mod_php deployments the highest risk. In practice, if a server answers web requests with PHP and has not been updated since 21 October, treat it as vulnerable.
The fixed releases are:
| Branch | Fixed version | Branch status |
|---|---|---|
| PHP 8.5 | 8.5.12 | Active support |
| PHP 8.4 | 8.4.27 | Active support |
| PHP 8.3 | 8.3.36 | Security fixes only |
| PHP 8.2 | 8.2.35 | Security fixes only, ends 31 December 2026 |
| PHP 8.1 and older | No official release | End of life |
For PHP 7.4, 8.0 and 8.1 the security team published minimal source patches for people who build PHP themselves. Linux distributions and long-term-support vendors received the fixes before the public release, so a distribution package may carry the fix under its own version string. Check your vendor’s advisory rather than comparing version numbers by eye.
Is it being exploited?
Yes. Amazon Threat Intelligence reported an exploitation attempt against its honeypots on 17 October, four days before public disclosure, and watchTowr has reported exploitation in the wild since the release. Researchers also noted that a working exploit was demonstrated quickly once details were public. The safe assumption is that automated scanning for this is already running against every public PHP server.
What to do, in order
1. Find every PHP installation
Most teams know about their main web server and forget the rest: a staging box, an old marketing site, a reporting tool, a Docker base image that has not been rebuilt in months. List them all before you start patching, including containers.
2. Update the PHP packages
Install the fixed version from the same source your PHP originally came from. Mixing repositories (for example distribution packages for the core and a third-party repository for extensions) is a common cause of broken upgrades. If you pin packages, pin the fixed version so a later update cannot quietly roll you back to a different build.
3. Restart the PHP processes and verify the running version
The command-line PHP and the PHP that serves web traffic are separate binaries. php -v in a terminal tells you nothing about what PHP-FPM is running. After the update, restart PHP-FPM (or Apache when using mod_php), then confirm the version from a request served by the web server, for example a temporary phpinfo() page on a restricted URL, which you delete straight afterwards.
# CLI version (not enough on its own)
php -v
# FPM binary version
php-fpm8.2 -v
# Then confirm through the web server and remove the test file4. Rebuild container images
Containers do not update themselves. Rebuild from a base image that contains the fixed release, redeploy, and remove the old images from your registry so nobody deploys them again by accident.
5. Use a WAF as a bridge, not a fix
Cloudflare deployed managed rules for the known exploit patterns, including on free plans, and other providers followed. That is useful while you patch, but rules only match known patterns. The update is the fix.
6. Look for signs of compromise
Because exploitation began before disclosure, a server that is now patched may already have been touched. Look for PHP files that appeared recently in upload or cache directories, unknown cron entries, new admin users in your applications, outbound connections to unfamiliar hosts, and unexpected processes running as the web server user.
The follow-up advisory: CVE-2026-115560
On 23 October the PHP project published an informational advisory for a related issue in the session upload progress feature, CVE-2026-115560. It affects fully patched releases, including 8.5.12, and is planned for the next regular release.
Very few applications use upload progress tracking. If yours does not, switching the feature off removes that code path entirely:
; /etc/php/8.x/mods-available/hardening.ini
session.upload_progress.enabled = 0
session.use_strict_mode = 1Apply it to both the FPM and CLI configuration, restart PHP-FPM, and confirm the value with ini_get() from a web request. This setting is a sensible default anyway and does not affect normal sessions, logins or file uploads.
What this tells us about running PHP
PHP2Shell is a reminder that the runtime is part of your application. Three habits made the difference between a calm afternoon and a long night for the servers we look after:
- Know your versions. An up-to-date list of servers, PHP versions and package sources turns an emergency into a checklist.
- Stay on a supported branch. Sites on PHP 8.1 or older have no official fix and depend on vendor backports or self-built patches. PHP 8.2 joins that group on 31 December 2026.
- Be able to restart safely. If restarting PHP-FPM on production feels risky, that risk will be there during every security release. Fix it before the next one.
If you are not sure whether your servers are patched, or you are still on an unsupported PHP version, get in touch and we will help you check.
