PHP2Shell: Critical PHP Vulnerabilities Require Immediate Patching

On 21 October 2026, the PHP project released fixes for two critical vulnerabilities in the PHP runtime. Known together as PHP2Shell, they allow an unauthenticated attacker to execute code on a web server. Both are rated CVSS v4.0 9.2.

Because the flaws sit in PHP itself, they affect any website or application running on it, including those built on WordPress, Drupal and Joomla. Updating the application or CMS does not remove the risk. The PHP runtime has to be updated and restarted.

Exploitation has started. Amazon reported exploitation attempts from 17 October, four days before the fixes were released. Cloudflare reported attacks against the two flaws before the release, and watchTowr confirmed active exploitation attempts against both. At the time of writing, we have not found a confirmed case of a successful compromise.

What organisations need to do

1. Identify every system running PHP, starting with those exposed to the internet.
2. Update to a fixed PHP version, then restart the web server and all PHP workers.
3. Confirm that the running process, not only the installed package, has the fix.
4. Where patching cannot happen immediately, apply the interim measures below and restrict access.
5. Review the affected hosts for signs of compromise.

The detail behind each step follows.

The vulnerabilities

CVE-2026-109618 is an out-of-memory handling flaw. When PHP runs out of memory while preparing request data, that data is left partly initialised, and the cleanup routine then treats it as valid. This can be exploited to achieve remote code execution.

CVE-2026-109619 is a stale-state flaw. PHP keeps references to request data after the underlying memory has been freed, and a later request on the same worker can use them. The result is a use-after-free that allows code execution. It also allows an attacker to read memory from the PHP worker, which can contain passwords, session tokens, API keys and certificates from other requests.

Researchers from Wiz, Calif and OpenAI found the flaws, and Wiz says AI models helped find the vulnerabilities and develop working exploits. Wiz demonstrated unauthenticated code execution against the latest WordPress, Drupal and Joomla container images.

What is affected

Any PHP installation that serves web requests: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The PHP security team rates mod_php as the highest risk. A demonstrated exploit needs a single unauthenticated request and runs before any application code. PHP-FPM is protected against one of the attack paths by its startup behaviour, but PHP has validated code execution against it as well, so it must also be patched.

Reports indicate that almost every PHP version back to 5.4 is affected.

PHP is also embedded in other software. This includes hosting control panels such as cPanel and Plesk, vendor appliances, and Windows applications that bundle php.exe or php-cgi.exe. Cisco has published an interim advisory rated critical. It lists Cisco products under investigation, including Webex and Slido, has not yet confirmed any as affected, and states that no workarounds are available. Other vendors are likely to publish similar lists in the coming days, so monitor their advisories.

Fixed versions

PHP 8.1 and earlier no longer receive upstream updates. The PHP project has published limited source backports for 7.4, 8.0 and 8.1, and some Linux distributions and long-term support vendors provide their own fixed packages. These packages often keep the old version number, so confirm the fix by checking the package changelog for the CVE identifiers instead of relying on the version string.

Systems on an unsupported branch should be treated as vulnerable until the vendor confirms a fix, and a move to a supported version should be planned.

Patching and verification

Prioritise systems that are reachable from the internet. After updating the PHP runtime, restart Apache, PHP-FPM and every long-running PHP worker. A system that has been updated but not restarted can continue to run the vulnerable code.

Verify the running process that serves web traffic. The command-line php -v can report a different version from the one behind the web server, and older workers may continue to run until restarted.

The fix introduces a hard memory limit. A worker that reaches it is ended immediately, without PHP’s normal cleanup. After upgrading, test the largest uploads and imports and review memory_limit and post_max_size against what your applications require.

Interim measures if patching is delayed

PHP states that updating is the only complete fix. The following measures reduce exposure while patching is arranged, and none of them replaces the update.

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, and restart all workers. Application-level ini_set and .user.ini files do not apply this setting. On PHP 8.5, also set fatal_error_backtraces=0.
• Set memory_limit=-1 administratively, keep post_max_size low, and enforce request-size limits at the web server or proxy. Removing the memory cap increases the risk of resource exhaustion, so use container or cgroup limits as a safeguard. Do not use process limits such as RLIMIT_AS or RLIMIT_DATA as a substitute; PHP advises against it.
• Block multipart requests where the application does not need file uploads.
• Restrict access to the system through a VPN, or take it offline if the above cannot be applied.

The upload-progress setting does not address CVE-2026-109618, so the measures should be combined. Web application firewall rules, including those Cloudflare deployed, are described as temporary, and attackers have already adjusted their payloads to bypass them.

Checking for compromise

Code execution through PHP runs with the privileges of the web server account, so the clearest evidence appears on the host. Indicators to review:

• PHP workers (php-fpm, php-cgi, httpd, apache2) starting shells, Python, Perl, curl or wget
• Reverse shell patterns such as /dev/tcp/, and reconnaissance commands such as whoami or id run from the web server
• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses
• Unusually large or malformed PHPSESSID cookies
• Unexplained PHP worker restarts
• New files in the web root, new scheduled tasks and new accounts

None of the sources we reviewed had published confirmed indicators of compromise. If a system cannot be patched or reviewed, treat it as exposed and isolate it.

Timeline

Wiz reported the vulnerabilities to PHP on 24 August 2026. PHP gave administrators advance notice that critical fixes were coming, and when details of the vulnerabilities, including the CVE identifiers, leaked on 20 October, it brought the release forward by a day. The fixes were released on 21 October, and researchers published technical details the same day.

Several organisations took services offline while they patched, including BambooHR and Dutch government services such as DigiD and MijnOverheid. The UK’s National Cyber Security Centre has advised organisations to update immediately, or to take affected systems offline until they are fixed.

How iConnect can help

To arrange a review, contact the iConnect team at iconnectitbs.com.

Based on public reporting from PHP, Qualys, Huntress, Wiz, Cisco, the NCSC and others, as of 22 October 2026. We will update this article as vendors publish further guidance.