PHP 8.3 and PHP2Shell: Fixed in 8.3.36, What to Do

As of 23 October 2026, PHP 8.3 is patched for PHP2Shell in PHP 8.3.36, released on 21 October 2026. Releases up to and including 8.3.35, from 24 September 2026, are affected. The fix for most 8.3 sites is a package update from the operating system or the host, followed by a PHP restart.

Of the four fixed releases, 8.3.36 is the least disruptive. PHP 8.3 is in its security-only phase, so this release contains the PHP2Shell fix and nothing else. There are no bundled bug fixes to test around.

PHP 8.3 is also everywhere. It is the PHP in Ubuntu 24.04 LTS, the default on RHEL 10 and its rebuilds, the runtime in the official wordpress:latest Docker image, and the minimum for current Drupal, Joomla and Laravel releases. This page lists the fixed package for each of those platforms and explains why so many patched 8.3 servers report a version number lower than 8.3.36.

PHP 8.3 Quick Reference

Branch dates are from PHP's supported versions page. The full cross-branch list is in our PHP2Shell fixed versions table.

Why 8.3.36 Is the Easiest PHP2Shell Update

PHP's ChangeLog entry for 8.3.36 has one line: "Fixed GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp (Avoid state corruption via bailout)." The 8.4 and 8.5 fix releases add more than a hundred other bug fixes, and a SimpleXML regression has been reported against 8.4.27 and 8.5.12. That report does not name 8.3.

The fix does change one behavior on every branch. From 8.3.36, memory_limit is a soft limit, and a separate hard limit sits above it. By default, the hard limit is twice memory_limit when memory_limit is 1G or less. A process that hits the hard limit is stopped at once with exit status 137, without running shutdown code. Most sites will never notice. Code that regularly runs near its memory limit should be watched after the update.

Ubuntu 24.04 LTS: Why Your Patched Server Says 8.3.6

Ubuntu 24.04 LTS ships PHP 8.3. Ubuntu fixed PHP2Shell by backporting the patch into its own package, so the upstream number did not change. According to Ubuntu's CVE page, the fixed version is 8.3.6-0ubuntu0.24.04.13, in standard support. No Ubuntu Pro subscription is needed, and 24.04 standard support runs to May 2029.

So php -v on a fully patched 24.04 server still says 8.3.6. The part that matters is the suffix after "ubuntu". USN-8948-1 lists the fixed binary packages, including libapache2-mod-php8.3, php8.3-cgi, php8.3-cli and php8.3-fpm.

An example update and restart (use apache2 instead of php8.3-fpm if you run mod_php):

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm
apt policy php8.3-fpm

The last command shows the installed package version, which should be 8.3.6-0ubuntu0.24.04.13 or later. Ubuntu installs most security updates automatically each day by default. Even so, confirm that the PHP service restarted after the update, because old workers keep running old code. Our guide to restarting PHP workers covers every setup.

RHEL 10, RHEL 9 and Their Rebuilds

PHP 8.3 is the default PHP on RHEL 10 and is also a module stream on RHEL 9. Red Hat's application streams life cycle lists the RHEL 9 PHP 8.3 stream as supported until May 2029. That is longer than PHP's own support for the branch, because Red Hat backports fixes itself.

The same branch carries three different numbers here: 8.3.36, 8.3.33 and 8.3.19. All of them are fixed builds. AlmaLinux puts it plainly: "Don't rely on php -v." Its documented steps are:

sudo dnf clean metadata && sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
rpm -q php-common

Compare the result with the builds above. If you are unsure which stream a RHEL 9 or AlmaLinux 9 server uses, dnf module list php shows it.

Alpine, Amazon Linux and Debian

• Alpine: php83 is fixed as 8.3.36-r0 in the community repository on 3.22, 3.23, 3.24 and edge. On 3.21, the package index has php83 8.3.36-r0, built on 22 October, but Alpine's security database had not been updated as of 23 October, so vulnerability scanners may still report it as unfixed. We found no fix for 3.20. See our PHP2Shell on Alpine guide. Alpine says its community repository "is supported until next stable release", per Alpine's release page. Treat those older releases as unfixed and move to a supported one.
• Amazon Linux 2023: php8.3 is fixed in ALAS2023-2026-3302 (php8.3-cli-8.3.36-1.amzn2023.0.1).
• Debian: no Debian release ships PHP 8.3 as a distribution package. Debian 12 uses 8.2 and Debian 13 uses 8.4.

Docker and the wordpress:latest Image

The official php:8.3 Docker tags carry 8.3.36. They were pushed late on 21 October. The official wordpress:latest image is WordPress 7.1.3 on php8.3-apache, rebuilt on 22 October. Docker's Apache variants run PHP as mod_php. PHP's advisory says: "We consider the risk highest for mod_php." Our Apache mod_php guide explains why.

Containers do not patch themselves. Pull the current image, rebuild anything based on it, and redeploy. If you build your own image with a pinned PHP version, change the pin to 8.3.36 or later.

CMS and Framework Support for PHP 8.3

For many platforms, 8.3 is the floor, not the ceiling:

• WordPress recommends "PHP version 8.3 or greater," per its requirements page. Our WordPress PHP2Shell guide covers the WordPress side.
• Drupal 11 requires PHP 8.3 or newer.
• Joomla 6 has a minimum of 8.3.0, with 8.4 recommended.
• Laravel 13 "requires a minimum PHP version of 8.3."
• Magento and Adobe Commerce 2.4.7 supports 8.3 and 8.2. 2.4.8 supports 8.4 and 8.3.

So if you run a current release of any of these on 8.3, never "fix" PHP2Shell by switching to an older branch. Patch 8.3, or move up.

Checking the memory_hard_limit_percent Directive

The fixed releases add a new directive, memory_hard_limit_percent. PHP's manual says that if it "is not recognized, the PHP version in use is affected by these vulnerabilities and must be updated immediately." One example check:

php -r 'echo ini_get("memory_hard_limit_percent") === false ? "missing" : "present";'

Use this test with care on 8.3. It is contested, and it is only reliable on builds of PHP's own 8.3.36 release, such as the official Docker image. The 8.3 branch has several fixed builds with lower numbers: Ubuntu's 8.3.6, AlmaLinux's 8.3.33 and RHEL 10.0 EUS's 8.3.19. We could not verify whether those include the directive. A "missing" result there does not prove you are vulnerable. Check the package version instead. And remember that the command-line PHP may not be the one serving your site.

Planning Beyond PHP 8.3

PHP's security support for 8.3 ends on 31 December 2027. Ubuntu 24.04 and RHEL 9 support their 8.3 packages longer, through their own backports. If you rely on that, you rely on the vendor's patches, not php.net's. Our guide to the shared responsibility model explains who patches what.

For most sites, the sensible plan is to finish patching now and move to PHP 8.4 during 2027. 8.4 gets security fixes until the end of 2028. Our PHP 8.4 page lists the 8.3 to 8.4 changes that break older code. Test that move on a copy of the site first. Our staging sites guide shows how.

Conclusion

PHP 8.3 is the simplest branch to patch. The fix release contains nothing else, and every major platform that ships 8.3 has a fixed package, except Alpine 3.20. Update through your vendor, restart PHP, and confirm the package version rather than trusting php -v. If you manage many servers or need it done today, our emergency PHP patching service can take it on. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions