Which PHP versions fix PHP2Shell
Install PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a patched build from your Linux distribution or host. All four came out on 21 October 2026 and fix both flaws, CVE-2026-109618 and CVE-2026-109619.
Last reviewed . Rules of .
Fixed release for each branch
Your branch is the first two numbers of your version, such as 8.3. You need that branch’s fixed release or a newer one. The patch number differs per branch, so 8.3.35 and 8.4.26 do not have the fix.
| Branch | Fixed release | Security support ends | Status |
|---|---|---|---|
| 8.5 | 8.5.12 | 31 Dec 2029 | Supported. Update to 8.5.12 or newer. |
| 8.4 | 8.4.27 | 31 Dec 2028 | Supported. Update to 8.4.27 or newer. See the crash note. |
| 8.3 | 8.3.36 | 31 Dec 2027 | Supported. Update to 8.3.36 or newer. |
| 8.2 | 8.2.35 | 31 Dec 2026 | Supported until the end of 2026. Update to 8.2.35 now and plan a move to a newer branch. |
| 8.6 | 8.6.0RC4 | Not released yet | Test build only. RC4 has the fix. Earlier 8.6.0 test builds do not. |
| 8.1 | none | Ended 31 Dec 2025 | End of life. Source backport only. Get a patched vendor build or upgrade. |
| 8.0 | none | Ended 26 Nov 2023 | End of life. Source backport only. Get a patched vendor build or upgrade. |
| 7.4 | none | Ended 28 Nov 2022 | End of life. Source backport only. Get a patched vendor build or upgrade. |
| 7.3 and older | none | Ended | End of life. No fix from the PHP project. Upgrade, or ask your vendor. |
PHP 8.6 test builds
PHP 8.6.0 has no final release yet. Its RC4 test build, out on 21 October 2026, contains the fixes for both flaws. If you test an earlier 8.6.0 build (alpha, beta, RC2 or RC3), move to RC4. php.net says not to use RC4 in production. The next release candidate, RC5, is planned for 5 November 2026.
PHP 8.1, 8.0 and 7.4 (end of life)
The PHP project makes no new releases for PHP 8.1 or older. Because the flaws are severe, its security team published minimal source backports for three of these branches:
They are source code only, for people who build PHP themselves or have no LTS vendor. They do not come with a new version number. PHP 7.4, 8.0 and 8.1 lists the vendor builds with the fix and what to do now.
The PHP project has nothing for PHP 7.3 and older. The researchers at php2shell.com found affected releases as far back as PHP 5.4. Upgrade to a supported branch, or ask your vendor whether it ships a patched build.
Vendor builds keep old numbers
Linux distributions and LTS vendors got the patches in advance. Some, such as Ubuntu and the RHEL 9 default PHP, add the fix to their own package and keep the old upstream number. Ubuntu 24.04 ships it as package 8.3.6-0ubuntu0.24.04.13, and php -v still says 8.3.6.
A low version number is not proof that PHP is unfixed.
If your number is below the fixed release but matches your distribution’s base version, check the package version. See fixed PHP packages on Linux and how to check your PHP version.
After you update
- Restart every PHP process. That means Apache, every PHP-FPM pool and any long-running PHP workers (php2shell.com). A new package does nothing until the old processes stop.
- Rebuild containers. Pull the new base image, rebuild your images and recreate the containers. A container restart alone keeps the old PHP (our advice).
- Check the running version again. Check the web server’s PHP, not only the command line. See how to check your PHP version.
- Review any stopgap
memory_limit. If you setmemory_limit=-1before the update, revisit it now. php2shell.com says to reviewmemory_limittogether with your request-size limits and the memory your app needs. - Know the new hard memory limit. The fix adds the setting
memory_hard_limit_percent. It is unset by default, which acts like-1: the hard limit is 2 ×memory_limitup to 1G, andmemory_limit+ 1G above 1G. A process that reaches it ends at once, and shutdown handlers do not run. - Keep upload progress off if you do not use it. The PHP advisory for CVE-2026-109619 suggests keeping
session.upload_progress.enabled=0after patching if your application does not need it. - Rotate secrets on exposed hosts. php2shell.com says the memory leak can expose passwords, tokens, API keys and certificates. If the server ran an affected PHP on the internet, change the secrets that PHP could read (our advice).
Crash report in 8.4.27 and 8.5.12 (GH-24488)
php-src issue GH-24488 reports a crash with the message zend_mm_heap corrupted in 8.4.27 and 8.5.12. It happens when a SimpleXML object whose properties were read (get_object_vars, an array cast or json_encode) is freed by the garbage collector as part of a reference cycle. The PHP team marked it verified. On 2026-10-22 they closed the issue with a fix in the php-src source (commit f963484725, PHP-8.4 branch). No PHP release contains that fix yet.
Nobody has reported it as a vulnerability. Do not go back to an older release because of it (our advice). Watch php.net for a follow-up release.
Check your site
The php2shell.fyi checker reads what your site sends to the public and lists the signals it found. It cannot see a patched package behind an old number, so confirm the result on the server or with your host.
Sources
- php.net: Security advisory, 21 October 2026
- php.net: Supported versions
- php.net: Unsupported branches
- php.net: release candidates (8.6.0RC4)
- php-src: NEWS for 8.6.0RC4
- php-src: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- php-src: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- php-src: main.c in 8.5.12 (memory_hard_limit_percent)
- php-src: issue GH-24488
- php2shell.com: research site