PHP 8.5.12 Fixes PHP2Shell, but a Third RCE Flaw Is Open

PHP has patched PHP2Shell: versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on October 21, fix both critical flaws, CVE-2026-109618 and CVE-2026-109619. The catch is that PHP disclosed a third remote code execution risk on October 23, CVE-2026-115560, and those releases don't fix it.

The new issue is narrow and has a one-line mitigation, but the reports we read show no severity score and no release named for the fix. This post covers what shipped, what's still open, and what to change on your servers. It follows our earlier PHP2Shell post, which was written before the patch existed.

Key Takeaways

• Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP says updating is the only complete fix for the two critical CVEs.
• CVE-2026-115560 is not fixed by those releases. PHP plans to fix it in its next regular bugfix release.
• Until then, set session.upload_progress.enabled=0 and restart every worker.
• PHP 7.4, 8.0 and 8.1 got minimal source backports. Distro and LTS vendors may ship fixes under the old version number.
• Reports about exploitation conflict. Scanning is real, so treat internet-facing PHP as a target now.

What did PHP fix on October 21?

Two memory-safety bugs that can lead to unauthenticated remote code execution. PHP's security advisory rates each one 9.2 on CVSS v4.0. The vector lists attack complexity as high, so these aren't trivial one-shot bugs, but PHP's own advisories describe confirmed exploitation against Apache mod_php in testing.

• CVE-2026-109618 (out-of-memory corruption): PHP uses longjmp() to bail out when memory runs out. If that happens while request data is only partly initialized, request cleanup can treat the invalid data as valid. The fix removes longjmp() for out-of-memory errors. It fails softly at the next VM safe point, with a hard exit at a higher threshold.
• CVE-2026-109619 (stale global state): state owned by a finished request, such as error or session state, can survive after its memory is freed. A later request handled by the same worker can read it before normal initialization resets it. More workers and recycling lower the success rate but don't remove the condition.

Which PHP setups are most exposed?

Anything serving web requests. The Canadian Cyber Centre's alert lists PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk, and says PHP rates mod_php highest. PHP's advisories break it down:

• 109618: confirmed exploitable on Apache mod_php with default limits and prefork. PHP-FPM is considered susceptible, but no complete exploit has been demonstrated. FrankenPHP and LSAPI are likely susceptible but unvalidated.
• 109619: the session upload progress path is confirmed on both mod_php and PHP-FPM. On PHP 8.5, the fatal error backtrace feature is the strongest demonstrated case, with confirmed code execution on mod_php.

One practical catch from Datadog's analysis: interpreters bundled in containers and applications count too, and may not match the PHP version your command line reports.

What about PHP 8.1 and older?

The PHP project no longer updates 8.1 and older, but it provided minimal source backports for 7.4, 8.0 and 8.1. That's a change from what was known when we published our earlier post. Linux distributions and LTS vendors may ship fixes too, and Datadog notes they may not change the version number, so a version check alone won't tell you whether you're covered. Check your vendor's advisory for the CVE IDs. watchTowr's FAQ lists PHP 7.3 and older, including PHP 5, as unfixed, so those need an upgrade.

Also note that PHP 8.2 reaches end of life on December 31, 2026, so landing there is a stopgap rather than a destination.

What is CVE-2026-115560, and is it fixed?

It isn't fixed. PHP published a short informational advisory on October 23 for a separate remote code execution risk, and The Hacker News confirms the October 21 releases don't cover it. It only applies when all of these are true:

• The application sets session.serialize_handler to php_binary or php_serialize in its configuration.
• It switches the handler to php at runtime with ini_set(), before calling session_start().
• Session upload progress is still enabled, which it is by default.

Apps that never change the serialize handler at runtime aren't exposed through this path. PHP calls the setup unlikely and is handling it in the regular release cycle, with a full advisory due alongside the next release. No exploitation of this CVE has been reported.

What the reports we read don't say: which PHP versions are affected, which release carries the fix, a severity score, or whether it shares a root cause with CVE-2026-109619.

The mitigation is the same one PHP listed on October 21 for CVE-2026-109619. If you applied it then, you're done. Otherwise set this in startup configuration (php.ini, your FPM pool config, or server config) and restart every worker:

session.upload_progress.enabled = 0

To confirm it took effect, run this from the same environment your site runs in. It should print string(1) "0" (or an empty string). Your CLI and your web server can load different php.ini files, so a clean CLI result doesn't prove your FPM or Apache config changed:

php -r 'var_dump(ini_get("session.upload_progress.enabled"));'

Is PHP2Shell being exploited?

Scanning is real, and mass successful exploitation is unproven. The sources disagree, so here is who said what.

• watchTowr says its honeypot network has observed exploitation in the wild since October 21. It also notes the flaws weren't in CISA's Known Exploited Vulnerabilities catalog as of October 22.
• Datadog cites Patchstack's reports and says AWS reported attempts as early as October 17, four days before disclosure. We couldn't confirm the AWS claim elsewhere.
• Sophos first reported a successful exploitation, then retracted it on October 22. Its telemetry shows scanning and a few failed attempts, and it says building a reliable exploit looks difficult.
• Huntress had not observed exploitation on partner systems as of 4:30 pm ET on October 21, and the Cyber Centre had not identified active exploitation as of its October 23 update. Huntress's post adds that Calif published a write-up and Wiz demonstrated unauthenticated code execution against WordPress, Drupal and Joomla.

Sophos also says public exploit code exists, but it didn't verify that. Between the write-ups and the demonstrations, the technique is public even if broad compromise hasn't been shown. Plan on attackers catching up.

What should you do today?

1. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Rebuild container images, then restart or replace every worker so none keeps the old runtime. Internet-facing systems come first.
2. On 7.4, 8.0, 8.1 or a distro package, check the vendor's advisory for the CVE IDs instead of trusting the version string.
3. Set session.upload_progress.enabled=0 and restart all workers. PHP's advisory recommends this even after patching if you don't use the feature.
4. If you can't patch yet, PHP lists partial mitigations, and the advisory says none of them makes an install safe. For 109618, that means enforcing memory_limit=-1 administratively, keeping post_max_size conservative at the frontend, and lowering max_input_nesting_level. On PHP 8.5, also set fatal_error_backtraces=0. Don't use RLIMIT_AS or RLIMIT_DATA, because they make mmap() fail and trigger the vulnerable path. The Cyber Centre also suggests isolating internet-facing apps if you can't patch right away.
5. Hunt for signs of attempts: shell processes spawned by web workers, memory exhaustion fatals during request initialization, worker segfaults, oversized POSTs and unusually long form field names. A successful exploit may return HTTP 200 and leave the worker running, so don't rely on crashes alone.

Wrapping Up

Patch first, then close the upload-progress gap, since the same one-line setting covers both CVE-2026-109619 and the new CVE-2026-115560. When PHP ships its next regular bugfix release, read its advisory for the affected versions and the real fix for 115560.

Sources

• PHP.net: News Archive 2026 (security advisory, release notes, informational advisory)
• GitHub advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Canadian Centre for Cyber Security: Alert AL26-026
• The Hacker News: PHP warns of another unpatched RCE risk
• Sophos: Proof-of-concept exploit released for PHP vulnerabilities
• Datadog Security Labs: PHP2Shell analysis
• Huntress: Rapid Response, php2shell (with post-patch updates)
• watchTowr: PHP Remote Code Execution FAQ