php2shell: which PHP versions are hit, what to do today, and the year-end deadline

PHP fixed two critical flaws on 21 October 2026. Which versions are affected, what to do today, stopgaps if you cannot update yet, and the end of PHP 8.2.

Kenji Sakuramoto · ｋｅｎｓａｕｒｕｓ合同会社 · Published 2026.10.22

Accurate as of 22 October 2026. We will update this page when new information is published.

What happened

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed "php2shell". Both are rated 9.2 on CVSS v4.0. Someone who is not logged in may be able to run their own code on your server from outside.

Details leaked on 20 October, before the fixes were out, and PHP posted an advance notice that evening. The fixed releases followed on the 21st at about 14:00 UTC.

Which versions are affected

8.2 to 8.5: the fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
8.1 and older: PHP ships no fixed release. It published minimal source-only backports for 7.4, 8.0 and 8.1. You build them yourself or wait for your Linux distribution or extended-support vendor.
GMO Flatt Security's analysis says to treat PHP 5 through 8 as broadly affected. Attacks were reproduced on common setups built with WordPress, Laravel and Symfony.

What to do today

Check the version production actually runs. php -v on the server shows the command-line PHP, which can differ from the one serving web requests. Check your hosting panel, or your PHP-FPM or Apache configuration.
On 8.2 to 8.5, update to the fixed release. Linux distributions and extended-support vendors received the fixes in advance, so check your packages.
If you cannot update today, apply the stopgaps. PHP's advisory lists setting session.upload_progress.enabled=0 in php.ini or the FPM pool and restarting every worker, setting memory_limit=-1 where applications cannot override it (php_admin_value), lowering post_max_size, and on 8.5 setting fatal_error_backtraces=0. ini_set() and .user.ini do not work for this. PHP is clear that these close only some paths and that updating is the only complete fix.
On 8.1 or older, patch for now and plan the move. Close the hole with a backport or your vendor's fix, then decide the order in which you move to a supported version.
Check whether anyone got in. The details were public before the fix, so review access logs, unfamiliar files and the permissions your server holds.

The second deadline: PHP 8.2 ends this year

Security support for PHP 8.2 ends on 31 December 2026. Updating to 8.2.35 today is right, but from January the next vulnerability will get no fix on 8.2. Plan the step to 8.3 (supported to the end of 2027) or 8.4 (to the end of 2028) now.

Old PHP is still common. W3Techs (22 August 2026, websites worldwide) counts PHP 7 on 28.9% and PHP 5 on 7.9% of the sites that use PHP.

How kensaurus can help

We take on old PHP systems and bring them up to date one step at a time, without switching them off. That covers checking what runs today, applying the fix or the stopgaps, upgrading to a supported version, and moving only the parts that need it to a newer stack. This page explains how we run it.

We do not share or discuss attack steps or proof-of-concept code, on this page or in an engagement.