It is Friday evening, the PHP2Shell advisory has been out for three days, and you have been told to “just update PHP.” Which PHP? To what? What if the app breaks on Monday? Those are good questions, and the answers depend on which version you are on today.
This is the checklist we would follow to patch PHP2Shell (CVE-2026-109618 and CVE-2026-109619), version by version, including what to do if you are on something that no longer gets updates.
Step one: find out what you are really running
Do this before anything else. Run php -v on the server, and then confirm what the web server uses, because they can differ. If you use Docker, check the image tag and rebuild date, not what you remember writing in the Dockerfile.
Also note your handler: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP or LiteSpeed. The PHP project says mod_php is the highest risk, so those servers go first.
Step two: pick the fixed version for your branch
- PHP 8.5: update to 8.5.12
- PHP 8.4: update to 8.4.27
- PHP 8.3: update to 8.3.36
- PHP 8.2: update to 8.2.35. This branch reaches end of life on 31 December 2026, so plan the next jump now instead of in January
- PHP 8.6: it is still a release candidate. Use RC4 or later if you are testing it, and keep it away from production
These are patch releases within the same branch, which means they should be low risk. Moving from 8.3.30 to 8.3.36 is not the same exercise as moving from 7.4 to 8.3.
If you are on PHP 8.1 or older
The PHP project no longer supports these. It has published fixes for 7.4, 8.0 and 8.1 as source branches, and some vendors, including several Linux distributions, ship their own backports. If you are using a distro package, find the changelog entry for the CVE numbers rather than judging by the version.
An unsupported PHP version isn't a patching problem. It is a decision you have been postponing.
The backport is a bridge. Use it to stop the immediate risk, then schedule the real upgrade, because the next critical bug will arrive without a backport.
Interim settings, if you cannot patch today
These come from the PHP advisory. They are partial mitigations, not a fix, and they are set at server level (php.ini, an FPM pool, or Apache config), not with ini_set() or a .user.ini file.
- Set session.upload_progress.enabled = 0 and restart all workers.
- Set memory_limit = -1 via php_admin_value, and keep post_max_size low, 8M if you take no uploads, 32M if you do, with upload_max_filesize below it.
- Enforce request size limits at the web server or proxy.
- On PHP 8.5 only, set fatal_error_backtraces = 0.
One warning from the advisory worth repeating: do not use RLIMIT_AS or RLIMIT_DATA to cap memory, because they can trigger the very code path you are trying to avoid. Use a container or cgroup limit instead.
After you patch
Restart PHP-FPM or Apache so old workers die. Confirm the version in a real request, not only in the terminal. Then look back through your logs. The PHP guidance suggests watching for unusual multipart requests followed by memory limit errors, runs of HTTP 500 responses, oversized PHPSESSID cookies, and PHP workers that restart without explanation.
Note too that the fix adds a hard memory limit, and when a process hits it, the process ends and shutdown handlers are skipped. If your app relies on shutdown functions to finish work, test that. Do the update on a staging copy first if you can.
For the big picture of what these two flaws are, read our plain English explanation of the PHP2Shell vulnerability.
If you would rather not do this on a Friday night, our software development team in Delhi NCR can audit your servers, patch them and plan the move off unsupported PHP. See what we do under services, or get in touch with your PHP version and we will map out the safest route.