PHP2Shell: update PHP on your web servers now

If your website, portal or web application runs on PHP, update PHP today. On 21 October 2026, the PHP project released emergency fixes for two critical flaws in the PHP interpreter. The name of the flaws is PHP2Shell. An attacker can use them to take control of a web server. The attacker needs only one special request and no login.

PHP2Shell is not a bug in a WordPress plugin or in one framework. The flaws are in PHP itself, below all of these applications. Thus, a site with correct code is exposed if its PHP version is vulnerable. This article tells you what happened, who is affected and what to do.

What PHP2Shell is

PHP2Shell is two separate memory-safety bugs. The PHP security team gives each bug a score of 9.2 out of 10 (CVSS v4.0). An attacker can use either bug for remote code execution without a login.

CVE-2026-109618: corruption when memory runs out. PHP can run out of memory while it sets up the internal data for a request. PHP then stops before it completes that data. The cleanup step uses the incomplete data. The researchers got to this bug through file-upload (multipart) requests.
CVE-2026-109619: stale global state. Some data from one request stays after PHP frees its memory. The next request on the same PHP worker can use that old data before PHP resets it.

The second bug can also leak data. Wiz Research found the bugs. Wiz showed that this bug can read the memory of a PHP worker without code execution. That memory can contain database passwords, API keys and session tokens.

Who is exposed

All PHP installations that serve web requests are in scope. This includes the usual setups: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

The PHP team gives the highest risk to mod_php (PHP inside Apache). There, an exploit starts before your application code starts. Thus, your application cannot stop it.

Wiz says that at least one of the two bugs affects every PHP version back to 5.4. Wiz took control of the latest WordPress, Drupal and Joomla images. Wiz also said that an attacker can exploit a simple “Hello World” page. If a system runs PHP and connects to the internet, think of it as affected until you check it.

How the bugs became public

PHP released the fixes one day early because the information leaked. The planned disclosure date was 22 October. On 20 October, the CVE numbers and a claim of critical PHP remote code execution flaws appeared online. PHP then moved the release to an earlier date.

When (UTC)	Event
21 Oct, about 14:19	watchTowr reports attempts to exploit both CVEs.
21 Oct, 14:00	PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Wiz publishes its disclosure.
21 Oct, 03:02	The Cloudflare WAF rules for PHP2Shell start on all plans, including Free.
20 Oct	The leak appears online. PHP gives advance notice of an emergency release. CERT-EU issues advisory 2026-018.

Wiz says that it used frontier AI models to make working exploits from these memory bugs. Thus, expect less time between the disclosure of a bug and real attacks.

Attacks have started

The reports do not agree about the scale. Several security companies say that attacks have started.

Companies that see attacks: Cloudflare saw early attack traffic against its customers. watchTowr reports attempts to exploit both CVEs in its honeypot network. Hadrian sees exploitation at scale, mostly through the session upload progress feature of PHP.
Companies that do not see attacks yet: Huntress found no exploitation on its partner systems on the evening of 21 October. CISA saw no exploitation when it published its alert. At that time, neither CVE was in the CISA Known Exploited Vulnerabilities catalog.

Proof-of-concept code is available, and the details of the bugs are public. Thus, update now. Do not wait for an official confirmation.

The fixed versions

The fix is in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Earlier versions on these branches are vulnerable.

PHP branch	Fixed version	Notes
8.5	8.5.12	The current release
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	End of life on 31 December 2026
8.1, 8.0, 7.4	Vendor backports only	No official PHP release
5.4 to 7.3	None	Isolate the server and migrate

Do not trust the PHP version number alone. Many Linux distributions and hosting panels fix the bug but keep the same PHP version number. This group includes all Ubuntu fixes, RHEL 8 and 9, and the cPanel backports for 7.4 to 8.1. Thus, the version from php -v can give the wrong answer. An “old” version can be safe, and a “new” version can be vulnerable. Look for the CVE number in the package version or the changelog from your vendor.

After the update, restart PHP-FPM or Apache. Then all workers use the patched code.

PHP 8.1 and older

The PHP project does not release new versions for 8.1 and older. But the flaws are severe. Thus, the PHP project published small source patches for 7.4, 8.0 and 8.1. These patches fix only these two bugs. Vendors supply ready packages:

Ubuntu: fixes for all supported releases. Ubuntu Pro (ESM) packages are available for older releases. On Ubuntu 20.04, the fix for php7.4 is in 7.4.3-4ubuntu2.29+esm5.
Debian and Red Hat: Debian (DSA-6574-1) and Red Hat (RHSA-2026:87072) released fixed packages. Late on 21 October, the Red Hat release was not yet complete.
cPanel: cPanel added the fix to its PHP 7.4, 8.0 and 8.1 packages.
CloudLinux: alt-php fixes are available for 7.4 and 8.0 on most platforms. Fixes for 8.1 are available on some platforms.

PHP 5.4 to 7.3 has no fix. For a server on these versions, do these steps:

Remove the server from the public internet, or put it behind strict access controls.
Apply the temporary settings in the next section.
Make a plan to move the server to PHP 8.4 or 8.5.

If you cannot update today

These settings decrease the risk until you can update. The PHP team says that they do not make a server safe. Only the update fixes the bugs.

Put the settings in php.ini, in the FPM pool or in the Apache configuration. Do not use .user.ini or ini_set(), because PHP reads them too late. Then restart all workers.

For CVE-2026-109619 (do this first):

Set session.upload_progress.enabled=0. Reports say that attackers use this path most.
On PHP 8.5, also set fatal_error_backtraces=0.

For CVE-2026-109618:

Set memory_limit=-1 in a way that applications cannot change, for example with php_admin_value.
Decrease post_max_size to 8M if you do not need uploads, or to 32M if you need uploads. Set upload_max_filesize to a lower value than post_max_size.
Do not use RLIMIT_AS or RLIMIT_DATA as a memory limit. They can cause the failure that this bug needs.

A web application firewall (WAF) gives temporary protection only. At 03:02 UTC on 21 October, Cloudflare started PHP2Shell rules for all plans with its WAF, including Free. A WAF sees only the traffic that goes through it. It can also miss new types of attack. Keep the WAF on, and update PHP.

Your checklist for this week

Make a list of all your PHP systems. Include websites, client portals, staging servers, internal tools and systems that a hosting provider manages for you.
Update the systems that connect to the internet first. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply the backport from your vendor.
Check the package, not the output of php -v. Make sure that the changelog shows CVE-2026-109618 and CVE-2026-109619.
Restart PHP-FPM or Apache. Then no worker uses old code.
Apply the temporary settings on each system that you cannot update today. Keep your WAF on.
Look for signs of an attack on the exposed systems. Look for unknown files in the web root, new cron jobs and new admin accounts. Change the database passwords and API keys on those servers.
Make a plan to move off old PHP. Each system on 8.1 or older needs a migration date. Each system on 8.2 needs a migration date before the end of December.

If a hosting provider manages your server, ask the provider if your PHP has the PHP2Shell fix. Get the answer in writing. Do not assume that the provider applied the fix.

The software below your application is as important as the application. The fix for PHP2Shell is fast. A delay can cost much more.

Do you want us to check your PHP servers? Talk to us. Under Ooroboros Operations, we install critical security fixes first on the systems that we manage.

Sources

This article is general information, not security advice for your specific systems.