PHP releases emergency PHP2Shell fixes for two critical flaws allowing unauthenticated code execution. Website owners and hosting providers must update.
PHP developers have released emergency security updates for two critical vulnerabilities that can let attackers run code on web servers without logging in. The fixes arrived on October 21, 2026, a day after maintainers warned administrators to prepare for immediate patching.
Known publicly as PHP2Shell, the flaws are tracked as CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. PHP’s official announcement identifies installations serving web requests as at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
Google-owned security company Wiz said its researchers identified both vulnerabilities with help from AI tools. Separately, OpenAI said cybersecurity firm Calif identified a critical PHP flaw using GPT-5.6 Sol through its Patch the Planet initiative. PHP’s maintainers led the fixes and release, with support from the researchers and infrastructure providers.
Apache mod_php Faces the Highest Risk
PHP maintainers consider Apache’s mod_php setup the highest-risk deployment because researchers demonstrated an attack that works before the website’s own code begins running.
An attacker exploiting the flaws gains the permissions of the process handling web requests. That access can expose application files and credentials available to that process, although it does not automatically grant administrator privileges over the entire server.
Shahak Shalev, Global Head of Scam and AI Research at Malwarebytes, described how attackers could abuse a compromised website’s existing reputation.
“This is a goldmine for hackers. They can hijack real websites to take advantage of the site’s reputation to do things like phish people, serve malicious software from the trusted channel; the opportunities are endless,” Shalev said.
PHP’s advisories describe different attack conditions depending on the server configuration, application and installed extensions.
Errors in Memory Handling Allow Code Execution
The first vulnerability, CVE-2026-109618, affects how PHP handles running out of memory. Processing can stop while internal request data is only partly prepared, leaving PHP’s cleanup routines to use invalid data. Researchers confirmed remote code execution against Apache mod_php under default PHP input and memory limits.
The second flaw, CVE-2026-109619, allows information from an earlier request to remain referenced after its memory has been released. A later request handled by the same worker process can act on those references, enabling memory disclosure or code execution.
Researchers validated attacks against both mod_php and PHP-FPM, although the confirmed FPM route requires a suitable operation within the application. PHP’s advisory warns that running multiple workers reduces the success rate per request but does not remove the vulnerability.
Emergency Updates Are Available
Administrators should install the fixed release for their PHP branch.
| PHP branch | Fixed version |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Linux distributions and long-term support vendors received patches in advance. Organisations using vendor-maintained packages should check the corresponding security notice for confirmation that the fixes are included.
PHP 8.1 and older are outside the project’s normal support period. Maintainers have also supplied minimal source patches for PHP 7.4, 8.0 and 8.1, while users of older installations should consult their vendor or move to a supported release.
Website owners using managed hosting should ask their provider to confirm that the PHP runtime has been patched. Updating WordPress, its plugins or themes does not replace the server’s PHP installation.
Configuration Changes Offer Incomplete Protection
Administrators unable to patch immediately can consult the official advisories for temporary controls. These include disabling session upload progress and, on PHP 8.5, disabling fatal-error backtraces, followed by restarting every PHP worker.
Those changes block specific demonstrated attack paths. PHP maintainers warn that no generic configuration change covers every route, and hiding error messages does not prevent exploitation of the stale-state vulnerability. Installing the complete fixes remains necessary.
