PHP2Shell: What Website Owners Need to Do Now
Two critical PHP flaws, the available fixes, and a practical response checklist.
TL;DR: Act now
If you own a PHP-powered website, web application or server, contact your hosting provider or server administrator right now. If you cannot confirm that the security updates are installed, take the affected service offline or restrict public access until it is secured.
According to W3Techs (21 October 2026), roughly 69% of websites whose server-side programming language can be identified use PHP. With PHP this widespread, there is a good chance your own website, online store or web application uses it too, even if you did not choose the technology yourself. Ask your hosting provider or developer to confirm. Source: https://w3techs.com/technologies/breakdown/pl-PHP/ranking
Security update | 21 October 2026
A security issue in the software powering a website can become a business issue very quickly. PHP2Shell is the name given to two critical PHP vulnerabilities disclosed this week. If your website, customer portal or internal application uses PHP, ask your hosting provider or technical team to confirm its patch status today.
What is PHP2Shell?
The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS v4.0 severity score of 9.2. Successful exploitation can allow an attacker without a login to execute code with the permissions of the PHP web worker.
CVE-2026-109618 concerns memory exhaustion: an interrupted operation can leave internal request data incompletely initialised, which cleanup then processes incorrectly. CVE-2026-109619 concerns internal state that outlives the memory it refers to and can be reused by a later request in the same worker. The PHP project's technical advisories explain the conditions and differences between server configurations.
Who should act?
PHP's warning covers web-serving installations including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team identifies mod_php as the highest-risk configuration, with a demonstrated attack before application code runs. A framework update alone is therefore not an adequate response.
Which versions contain the fixes?
On 21 October 2026, PHP released the following fixed versions: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Install the security release for your supported branch, or a newer supported release containing both fixes.
Distribution packages can include backported patches without matching those upstream version numbers. Ubuntu, for example, lists 8.3.6-0ubuntu0.24.04.13 as fixed for Ubuntu 24.04. Verify the complete package version against your vendor's advisory. For PHP 8.1 and older, ask your vendor about maintained backports or move to a supported branch.
A practical response checklist
- Find every deployment. Include the public website, administration tools, staging systems, containers and older applications. Assign one person responsibility for confirming completion.
- Patch the runtime. Ask the operator to identify the PHP build serving each application and apply the appropriate vendor update. Rebuild and redeploy container images where needed.
- Restart and verify. Ensure web servers and PHP workers load the patched runtime. A command-line version check alone does not prove that web requests use the same installation. Test login, forms, uploads and other important workflows afterwards.
- Record the evidence. Keep the package or image version, deployment time, restart confirmation and test results together. If hosting is managed, request written confirmation that both CVEs are addressed.
Can configuration changes replace patching?
No. Disabling session upload progress blocks particular confirmed paths for CVE-2026-109619, but other paths remain. On PHP 8.5, disabling fatal error backtraces also addresses only a specific path. Follow the current official guidance with your operator; do not treat a workaround or a firewall rule as proof that the runtime is fixed.
If you suspect a compromise, preserve logs and involve your incident-response team. Updating closes vulnerabilities, but it does not establish whether a system was previously accessed.
Sources and further reading
- PHP project: https://www.php.net/archive/2026.php#2026-10-21-5
- CVE-2026-109618: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- CVE-2026-109619: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
Technical details checked on 22 October 2026. Check the linked advisories for subsequent updates.
