PHP2Shell: two critical PHP vulnerabilities and what businesses should do
Status as of 23 October 2026. The situation is still developing, so always check the latest information on php.net before you act.
The PHP2Shell vulnerability is a pair of critical flaws in PHP itself, the language behind a large share of websites, online shops and business applications. It is not a CMS or plugin bug, so updating WordPress or changing your application code will not fix it. Only updating PHP on the server will.
The fixes were released on 21 October 2026. Details leaked before the planned disclosure date, so the flaws were quickly being discussed well beyond the developer community. Several European public bodies, including Germany's ITZBund, Finland's Valtori, French prefectures and Dutch institutions, took some of their websites offline as a precaution.
There is no need to panic, though. The steps are clear, and for most servers this is a routine update. Below you will find out whether the flaws affect you, how to check and what to do if you cannot update straight away.
PHP2Shell is a flaw in PHP's core that can lead to remote code execution
Both CVEs in plain language
A CVE is the public identifier of a specific security flaw, used to look it up in databases and vendor advisories.
CVE-2026-109618 is triggered when PHP runs out of memory while handling a request. At that point, memory can become corrupted. CVE-2026-109619 is caused by stale global state that PHP keeps from a previous request. The program may then use memory that has already been freed, a so-called use-after-free.
Why the score is 9.2
RCE (remote code execution) means an attacker can run their own code on someone else's server. Both flaws can lead to it, which is why PHP rates them 9.2 out of 10 on CVSS 4.0, the standard scale for vulnerability severity. The NVD database also lists details of the scoring.
The score also reflects that an attack requires certain conditions to be met. It does not mean that every PHP server has been compromised.
Who is affected depends on how PHP runs on your server
Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed
All common ways of serving web requests with PHP are affected, but the level of risk differs:
- Apache with mod_php is the worst case. According to the researchers, an attacker can run code without logging in, before any application code runs, using only the default limits.
- PHP-FPM, typically paired with Nginx, is vulnerable to CVE-2026-109618, and the researchers demonstrated the attack on that setup. CVE-2026-109619 applies only under specific conditions, for example when settings are passed through PHP_VALUE or PHP_ADMIN_VALUE, or when session upload progress is enabled.
- php-cgi, FrankenPHP and LiteSpeed are affected as well.
Officially, the fix covers branches 8.2 to 8.5, but Calif researchers say the earliest affected path dates back to PHP 5.4, and to 7.3 for mod_php. The exact range of affected versions is not settled yet.
WordPress, Drupal, Joomla and custom applications
The flaw is in PHP, not in the CMS. It affects WordPress, Drupal and Joomla sites as well as applications built on the Nette framework or custom code, even when the application code itself is fine and every plugin is up to date.
How to check your PHP version: the server counts, not composer.json
The composer.json file states which PHP version your application requires, not which one is actually running on the server. Check the real version in one of these ways:
- Hosting control panel. Most hosting providers show the PHP version for each domain.
- WordPress. In the admin area, go to Tools, Site Health, the Info tab and the Server section.
- A temporary phpinfo() file. Upload a file that calls phpinfo(), check the version and delete the file immediately. Do not leave it on the server.
- Command line. php -v shows the version used on the command line, which may differ from the one serving your website. For PHP-FPM, also check its own binary, for example php-fpm8.3 -v.
- Docker. Check the version inside the running container. An image tag such as php:8.3-fpm does not tell you whether it already includes the fix.
Watch out for distribution packages. Debian and Ubuntu often backport fixes to older versions, so a version number may look unpatched even when the package contains the fix. What counts is the package version listed in the distribution's security notice.
Update to the patched release of your branch
| PHP branch | Patched version | Supported until |
|---|---|---|
| 8.5 | 8.5.12 | 31 Dec 2029 |
| 8.4 | 8.4.27 | 31 Dec 2028 |
| 8.3 | 8.3.36 | 31 Dec 2027 |
| 8.2 | 8.2.35 | 31 Dec 2026 |
| 8.1, 8.0, 7.4 | no official release | end of life |
End of support dates come from the supported versions page on php.net.
PHP 8.2 to 8.5: update within your branch and restart
On branches 8.2 to 8.5, updating to the patched release within the same branch is enough, and your application should not need any changes. After the update, restart PHP-FPM or Apache, otherwise the old processes will keep running. Note that PHP 8.2 support ends on 31 December 2026.
PHP 8.1, 8.0 and 7.4: end of life and a migration plan
There is no official release for older PHP versions. The PHP project published only minimal source backports for 7.4, 8.0 and 8.1. Ready-made packages for these versions are available, for example, from Ubuntu (USN-8948-2, older LTS releases only with Ubuntu Pro) or from long-term support vendors. Debian released fixed packages for its supported versions: php8.4 in Debian 13 (DSA-6574-1) and php8.2 in Debian 12 (DLA-4848-1).
If your application runs on PHP 8.1 or older, a patched package is only the first step. The next step is planning a move to a supported version.
Need help with the update right now? Use our urgent programmer help.
If you cannot update straight away, temporary measures reduce the risk
According to the advisory, updating is the only complete mitigation. If you cannot update immediately, these steps reduce the risk:
- set memory_limit=-1 via php_admin_value (you then need to monitor the server's memory by other means),
- lower post_max_size (8M without file uploads, 32M with uploads),
- limit request size at the web server or proxy,
- set session.upload_progress.enabled=0,
- on PHP 8.5, set fatal_error_backtraces=0,
- restart all PHP worker processes after the change.
Do not apply these settings through ini_set() or .user.ini, as they must apply to the whole server or pool. Do not use RLIMIT_AS or RLIMIT_DATA either.
A web application firewall (WAF) also reduces the risk. Cloudflare deployed protective rules roughly nine hours before the flaws were disclosed. A WAF does not replace the fix, though.
Status as of 23 October 2026: a new CVE-2026-115560 and what we know about attacks
On 23 October 2026, PHP flagged another flaw, CVE-2026-115560, and will publish a full advisory with the next release. The flaw relates to session upload progress and involves a rare combination with switching session.serialize_handler. Until the next release, PHP recommends setting session.upload_progress.enabled=0.
As of 23 October 2026, CISA has not added the flaws to its KEV catalogue, but Cloudflare reports early attack attempts, so do not delay the update. The flaws were discovered by researchers at Calif in cooperation with Wiz and OpenAI, and the disclosure was coordinated.
Ongoing application support shortens your response to flaws like this
With PHP2Shell, what matters is whether someone knows which PHP version your application runs on and can safely update and restart the server. If nobody does, you lose time, and with critical flaws that time is measured in hours.
1. Web IT, based in Prague and Brno, develops PHP web applications and online shops and supports them over the long term. As part of our application support or server and infrastructure management, we will check your PHP version with you and help with the update. What good support should include is covered in our article on application support SLAs. If nobody has looked after your application since your previous vendor left, see our article on taking over an application from another vendor.
Is your website looked after by a friend who “knows computers”? Plenty of business websites and applications are kept running by a helpful friend, a former colleague or whoever happened to be nearby. That is perfectly normal, but it often means nobody has touched the server for a long time. If that sounds familiar, get in touch. We will take a look together at which PHP version your site runs on and whether everything is up to date.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the name for two critical flaws in the PHP language, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. They can allow an attacker to run their own code on a server. PHP rates them 9.2 on CVSS 4.0.
Which PHP versions are affected and which should I update to?
Officially, the 8.2 to 8.5 branches are affected. The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. No official release was issued for PHP 8.1 and older. PHP published only minimal source patches; some distributions provide packaged fixes.
How do I check which PHP version my website uses?
The quickest way is your hosting control panel, or in WordPress go to Tools, Site Health, Info. On the server, use a temporary phpinfo() file or the PHP-FPM version command. composer.json does not show the version that is actually running.
Does PHP2Shell affect WordPress?
Yes. The flaw is in PHP, not in WordPress, so it affects every site running on an affected PHP version. Updating WordPress or plugins will not fix it; you need to update PHP on the server.
What if I am on PHP 7.4 or 8.1?
These versions are no longer officially supported and received no patched release. PHP published only minimal source patches for them; packaged fixes come from some distributions, such as Ubuntu, or LTS vendors. In the long run, plan a move to a supported PHP version.
Not sure which PHP version you run, or did the update run into a problem? Get in touch and we will go through your server, PHP version and update steps with you.
