PHP2Shell: A PHP Patch Guide for Site Owners
On 21 October 2026, the PHP security team released fixes for two critical vulnerabilities that can allow remote code execution without authentication. They are CVE-2026-109618 and CVE-2026-109619, often discussed together as PHP2Shell. PHP says all installations serving web requests are at risk, including sites using PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The team considers the risk highest for mod_php. PHP's security advisory is the primary source for the affected deployments, fixes, and temporary measures below. If you run a PHP website, start with the PHP version that serves live requests. Your CMS or framework name alone does not answer whether the server is patched. This guide explains what changed, which releases contain the fixes, and what to ask your host.What are the two PHP2Shell vulnerabilities?
Both flaws are in PHP's handling of web requests:- CVE-2026-109618, out-of-memory corruption: An out-of-memory event can interrupt initialization of internal request data. Cleanup can then treat partly initialized data as valid.
- CVE-2026-109619, stale global state: Request-owned internal state can remain after its backing memory is freed. A later request handled by the same worker can use that stale state before normal initialization resets it.
Which PHP versions fix PHP2Shell?
The first fixed upstream releases published by PHP are:| PHP branch | First fixed upstream release |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
How to check your live PHP installation
- Identify the PHP runtime serving your site. Check your hosting control panel, PHP-FPM pool, server package inventory, or container image. A local
php -vcommand may report a different command-line installation. - Compare its full version with the table above. If multiple pools or servers handle requests, check each one.
- Ask about vendor backports. If the package keeps an older version number, request the vendor advisory or package changelog confirming fixes for both CVEs.
- Confirm deployment after updating. Restart or recycle PHP workers, then verify the patched build is the one serving the website.
What if you cannot patch immediately?
Treat temporary measures as exposure reduction while you arrange the update. PHP says updating is the only complete solution. For the out-of-memory path, PHP advises limiting POST request size and describes amemory_limit=-1 setting that removes one controllable failure route, while warning that an underlying allocation failure can still reach the vulnerable path. For the stale-state path, PHP advises setting session.upload_progress.enabled=0 in configuration that applies before request parsing and restarting every worker. PHP 8.5 has an additional fatal_error_backtraces=0 measure for a confirmed path. Each measure has conditions and limits, so follow the PHP security team's full guidance with your hosting or operations team.
If you use managed hosting, send your provider three questions: Which PHP package serves this domain? Does that package contain both fixes, including any vendor backport? Have all web-serving workers restarted on the patched build? Keep the provider's answer with your incident and maintenance records.