PHP 8.5 and PHP2Shell: Fixed in 8.5.12, What to Do

As of 23 October 2026, PHP 8.5 is fixed for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) in PHP 8.5.12, released on 21 October 2026. Every earlier 8.5 release is affected, up to and including 8.5.11 from 24 September 2026. If your site runs PHP 8.5, install 8.5.12 or your Linux vendor's patched 8.5 package, then restart every PHP worker.

PHP 8.5 gets its own page because it is the newest branch and it carries one extra exposure. PHP's advisory for CVE-2026-109619 calls the PHP 8.5 fatal error backtrace path "the strongest demonstrated case", and it was the basis of the confirmed exploit against Apache mod_php. That path exists only on 8.5. So does the setting that blocks it.

The good news: 8.5 has the longest runway of any PHP branch. Once patched, you can stay on it until the end of 2029.

PHP 8.5 at a Glance

The dates come from PHP's supported versions page. For every other branch, see our PHP2Shell fixed versions table.

Why PHP 8.5 Has an Extra Exposure

PHP2Shell is two bugs in the PHP engine itself, not in your CMS or plugins. CVE-2026-109618 involves out-of-memory handling and affects every supported branch. CVE-2026-109619 involves internal state that one request can leave behind for the next request on the same worker.

PHP 8.5 added a feature that puts a backtrace into fatal error messages. PHP's advisory for CVE-2026-109619 names that backtrace code as a confirmed path: "PHP 8.5 fatal error backtrace: confirmed... This is the strongest demonstrated case and is the basis of the confirmed mod_php exploitation." Older branches lack this feature and this path, but still have the others. Our CVE-2026-109619 explainer covers the bug at a summary level.

What 8.5.12 Fixes, and What Else It Changes

PHP's ChangeLog lists the PHP2Shell fix as "Fixed GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp (Avoid state corruption via bailout)." Unlike the 8.3 and 8.2 fix releases, which contain only that line, 8.5.12 also bundles a normal month of bug fixes. Examples include an optimizer bug that could crash the engine (GH-23644), a file descriptor leak in the built-in server (GH-23764) and several OPcache and JIT fixes.

The fix also changes how memory limits behave. As of 8.5.12, memory_limit is a soft limit: an allocation that crosses it usually completes before the fatal error. A new hard limit sits above it. When a process hits the hard limit, PHP terminates it immediately with exit status 137 and skips shutdown functions. Under PHP-FPM, the client gets no response and the process manager starts a replacement worker.

One regression has been reported. A php-src issue titled "8.4.27 / 8.5.12 regression: GC double-frees the SimpleXMLElement properties table" describes crashes ("zend_mm_heap corrupted") in some code that uses SimpleXML. The issue was closed as fixed in the PHP source on 22 October. As of 23 October, we could not find which release will ship that fix. If your application parses XML and starts crashing after the update, tell your developer or host. Do not go back to 8.5.11, which is vulnerable.

PHP 8.5 on Linux Distributions

Most servers get PHP from the operating system, not from php.net. Vendors often backport the fix into an older version number, so the package version is what matters.

Red Hat's security data shows no RHEL AppStream stream for PHP 8.5, only the Hardened Images build. No other Ubuntu release ships php8.5, according to Ubuntu's CVE page.

On Ubuntu, Canonical's general advice is a full system update rather than cherry-picking packages. An example (replace the service name with the one your server uses):

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.5-fpm

On Amazon Linux 2023, the ALAS2023-2026-3304 advisory gives this command: dnf update php8.5 --releasever 2023.12.20261021. On Alpine, update the php85 packages until they report 8.5.12-r0.

Control panels have their own builds. cPanel's EasyApache 4 moved ea-php85 from 8.5.11 to 8.5.12. CloudLinux says its alt-php85 now ships as 8.5.12-1, and that earlier fixed builds such as alt-php85 8.5.11-5 are already protected. So a hosting panel that shows "8.5.11" is not proof that your site is unpatched. Ask the host which build you run.

Docker Images and Bundled Runtimes for PHP 8.5

The official Docker php image lists 8.5 at 8.5.12, in Debian trixie and bookworm variants (cli, apache, fpm and zts) and Alpine 3.24 and 3.23 variants. See the official php image page.

A running container does not update itself. Pull the new image, rebuild any image built on top of it, and redeploy. The official drupal:latest image now runs Drupal 11.4.11 on PHP 8.5 with Apache. It was rebuilt on 22 October, so redeploy if you use it.

FrankenPHP bundles PHP inside its own binary. Its 1.13.2 security release builds the static binaries with PHP 8.5.12, so FrankenPHP users must install 1.13.2 or later rather than update PHP separately.

CMS and Framework Support for PHP 8.5

Staying on 8.5 only works if your software supports it. As of 23 October 2026:

• WordPress: the core compatibility table marks PHP 8.5 as supported for WordPress 6.9, 7.0 and 7.1, and not for 6.8 or older. The "beta support" label was retired in May 2026. Our WordPress PHP versions guide explains the requirements.
• Drupal: only Drupal 11.3 and 11.4 support PHP 8.5. Drupal 10 does not.
• Magento and Adobe Commerce: 2.4.9 lists PHP 8.5. 2.4.8 lists only 8.4 and 8.3.
• Laravel: Laravel 12 supports 8.2 to 8.5, and Laravel 13 supports 8.3 to 8.5.

If you run an older CMS version on 8.5, patch PHP first. Then bring the CMS into its supported range.

The 8.5-Only Settings: fatal_error_backtraces and max_memory_limit

fatal_error_backtraces

This setting arrived in PHP 8.5.0. It defaults to 1 (on). PHP's interim advice for unpatched servers is: "On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only." Put it in php.ini or the PHP-FPM pool, not in application code. The cost is small: fatal error messages lose their backtrace, which makes debugging harder. The setting does nothing for CVE-2026-109618 or the other paths. Our interim mitigations guide covers the full list.

max_memory_limit

Also new in 8.5.0, this startup-only setting caps the highest memory_limit anyone can configure. It defaults to -1 (no cap). The PHP manual says that setting memory_limit above max_memory_limit "results in a warning and the value being capped."

That matters if you used PHP's stopgap of memory_limit=-1. If someone set a finite max_memory_limit, the stopgap will not take effect, and it adds a startup warning. PHP's advisory separately tells admins to remove settings that emit warnings before a request is initialized. Check both values before you rely on the memory mitigation.

After you patch, there is one more reason to revisit memory_limit=-1. The manual says that if memory_limit is set to -1, "there is no hard limit either." The stopgap therefore switches off the new safety net that 8.5.12 adds.

How to Confirm You Are on a Fixed 8.5 Build

If you run PHP built from php.net's source or the official Docker image, the version should read 8.5.12 or later. Remember that the command-line php can differ from the PHP that serves your site. Our guide on checking your PHP version covers the web-facing check.

The fixed releases also add a new directive, memory_hard_limit_percent. The PHP manual says: "If this directive is not recognized, the PHP version in use is affected by these vulnerabilities and must be updated immediately." An example check from the command line:

php -r 'var_dump(ini_get("memory_hard_limit_percent"));'

On a fixed upstream build, this prints an empty string, because the directive exists but is unset by default. If it prints bool(false), the directive does not exist.

A caveat: this test is contested. It is reliable only for builds of PHP's own releases. Ubuntu's 8.5.4 and 8.5.9 based packages are backports, and we could not verify that they include the directive. On a distro build, compare the package version with the table above, or read the package changelog.

CVE-2026-115560: The Follow-Up That 8.5.12 Does Not Cover

On 23 October, PHP published an informational advisory about a separate, unlikely session upload progress issue, CVE-2026-115560. It needs an unusual mix of configuration and application code. Cloudflare notes that it "affects fully patched PHP releases, including 8.5.12." PHP suggests setting session.upload_progress.enabled=0 "until the next regular bugfix release." If you set it for PHP2Shell, keep it. As of 23 October, no CVE record had been published for it, and CERT-EU says PHP will not issue an out-of-band release.

What to Do Next on PHP 8.5

1. Update to 8.5.12, or to your vendor's fixed 8.5 package.
2. Restart every PHP worker, including PHP-FPM, Apache, detached LiteSpeed PHP processes and containers. See how to restart PHP workers.
3. Confirm the build that serves your site, using the version, the package version or the directive check above.
4. Keep session upload progress off unless you need it.
5. Remove stopgaps you no longer need, and decide deliberately about memory_limit=-1.
6. Watch logs for SimpleXML crashes from the reported regression.
7. Stay on 8.5. If a plugin or extension is not ready for it, PHP 8.4 is supported until the end of 2028.

Then put PHP updates on a schedule, as covered in our security patching guide.

Conclusion

PHP 8.5 is the branch with the confirmed backtrace path, but it is also the one with the most support left. Update to 8.5.12 or a vendor-patched package, restart every worker, confirm the build, and keep upload progress off until PHP's next release. If you would rather have someone else patch, restart and verify it, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions