PHP2Shell Is Patched, but a Third PHP RCE Edge Case Remains

PHP’s emergency updates fix the two critical PHP2Shell flaws, but CVE-2026-115560 still needs a temporary session upload setting change. Here is how to verify every web runtime.
PHP programming language logo
Official PHP logo by Colin Viebrock, via Wikimedia Commons, CC BY-SA 4.0.

PHP administrators who installed this week’s emergency PHP2Shell updates have one more setting to check. On October 23, the PHP project disclosed a third remote-code-execution condition, CVE-2026-115560, involving session upload progress. It is not fixed in the October 21 releases, although the project describes the required configuration as unusual and plans to include a fix in the next regular bugfix release.

The immediate advice is narrower than the original PHP2Shell response: keep the emergency updates installed, then set session.upload_progress.enabled=0 until the next PHP release unless an application genuinely needs that feature. PHP’s October 23 advisory says sites that never change the session serialization handler at runtime can leave upload progress enabled, but disabling it temporarily removes uncertainty while teams inspect their applications.

What the emergency PHP updates fixed

The October 21 releases patched two critical PHP engine flaws collectively known as PHP2Shell. PHP’s original advisory lists PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as the first fixed upstream versions. The bugs affect PHP installations serving web requests through PHP-FPM, Apache mod_php, PHP-CGI, FrankenPHP and LiteSpeed; the project rated mod_php the highest-risk setup because researchers demonstrated exploitation before application code runs.

Issue What goes wrong Current response
CVE-2026-109618 An out-of-memory bailout leaves partially initialized request data for cleanup code to treat as valid. Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor package that backports the fix.
CVE-2026-109619 A fatal error can leave request-owned pointers behind after their memory has been freed, allowing later work on the same process to use stale state. Install the same emergency update. There is no complete configuration-only workaround.
CVE-2026-115560 An uncommon session-handler change can leave the upload-progress path exposed to a separate RCE condition. Temporarily disable session upload progress. A code fix is due in the next regular bugfix release.

The first two bugs are not ordinary flaws in a framework, plugin or application route. They sit in the PHP runtime’s request lifecycle. Red Hat’s technical summary explains that one path operates on incomplete state after a failed allocation, while the other reuses stale pointers after a fatal error interrupts cleanup.

Amazon also found an attempted exploit in its MadPot sensor network dated October 17, four days before public disclosure. Its threat-intelligence report does not claim that the attempt succeeded on a real server or identify how the actor obtained the vulnerability information. It does establish that defenders should treat pre-patch exposure as an incident-scoping question, not assume the risk began when the CVEs became public.

The third CVE needs a rare combination of settings and code

CVE-2026-115560 does not make every patched PHP server immediately exploitable. PHP says all of the following conditions must be present:

  • session.upload_progress.enabled is enabled.
  • The configured session.serialize_handler is php_binary or php_serialize.
  • Application code changes that handler to php at runtime with ini_set().
  • The application then calls session_start().

That sequence is uncommon, but checking only a server’s starting php.ini value can miss it because the decisive handler change occurs inside application code. Search first-party code and installed dependencies for calls that modify session.serialize_handler, especially code paths that run before session_start().

rg -n "session\.serialize_handler|session_start\s*\(" /path/to/application

Do not scan a production tree by blindly following generated caches, uploaded files or vendor directories if that will overwhelm the result. Start with application-owned code, then inspect matching packages and framework adapters deliberately.

Check the PHP runtime that actually serves traffic

php -v reports the command-line interpreter on the current shell path. A host can simultaneously run a different PHP-FPM service, an Apache module, several container images or separate versions for different virtual hosts. Inventory each web-facing execution path.

php --version
php --ini
php -i | grep -E "Server API|session.upload_progress.enabled|session.serialize_handler"

php-fpm -i | grep -E "Server API|session.upload_progress.enabled|session.serialize_handler"
apachectl -M | grep -i php

Binary names are often versioned, such as php8.3-fpm, and FPM pool files can override global settings. Check the service units, pool configuration and container image digest in use, not just the default CLI binary. Restart or roll the relevant Apache, FPM and container workers after updating; a package on disk does not replace already running processes by itself.

Distribution packages may also backport the fixes without changing to PHP’s upstream version number. For example, Ubuntu’s security notice lists fixed packages such as 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04 LTS and 8.1.2-1ubuntu2.28 for Ubuntu 22.04 LTS. Compare the installed package against the advisory for the exact operating-system release instead of declaring it vulnerable solely because its version looks lower than 8.2.35.

Disable session upload progress until the next release

For a global PHP configuration, add the following to the applicable php.ini and restart the web workers:

session.upload_progress.enabled = Off

On PHP-FPM, administrators can enforce the value in the relevant pool configuration:

php_admin_value[session.upload_progress.enabled] = 0

Confirm the effective value through the same server API that handles requests. If the site exposes an upload-progress interface, test that workflow after the change; ordinary file uploads do not require PHP’s session upload-progress feature.

Managed-hosting customers should ask the provider two separate questions: whether its PHP builds include fixes for CVE-2026-109618 and CVE-2026-109619, and whether it has disabled or otherwise mitigated session upload progress for CVE-2026-115560. Updating WordPress, a PHP framework or an application plugin does not patch the runtime beneath it.

A WAF buys time, but it does not close the case

AWS updated its PHP managed rule group to version 2.4, adding coverage for both original PHP2Shell request patterns and the session-upload-progress path. Customers following the default version receive the current rules automatically; customers who pinned an older version must move to the latest one. The AWS WAF guidance repeatedly notes that patching is the only complete fix for the first two CVEs.

The same limitation applies to other edge protections. A rule can block known request shapes, but alternate encodings, unprotected origins, internal traffic and a misrouted hostname can bypass that layer. Keep WAF coverage as defense in depth, then verify the runtime and configuration at the server.

Scope possible exposure before closing the ticket

Amazon recommends looking for POST requests containing PHP_SESSION_UPLOAD_PROGRESS, unexpected process execution and unexplained file changes on PHP servers. Most standard access logs do not record request bodies, and enabling blanket body logging can capture passwords, tokens and personal data. Use existing WAF, reverse-proxy or detection telemetry where available rather than turning on indiscriminate production logging.

Investigate PHP worker processes spawning shells, download tools or unfamiliar interpreters; new files in the document root, upload directories and temporary paths; modified scheduled tasks; and outbound connections that do not match the application’s normal behavior. Amazon published several observed IP addresses but warned that they include shared anonymization infrastructure and are not exclusive to this activity, so a match is a lead to investigate rather than proof of compromise.

If evidence points to code execution, isolate the affected host, preserve volatile evidence and rebuild from a known-good image. Rotate credentials the PHP process could read, including database passwords, cloud tokens, deployment keys, mail credentials and application secrets. Restoring files without replacing exposed secrets leaves the most valuable part of the intrusion intact.

The response order is straightforward: deploy the emergency runtime fixes or verified vendor backports, disable session upload progress while CVE-2026-115560 awaits its code fix, restart every serving process, validate the effective configuration and examine the pre-patch window. A green package report is useful, but it is not the same as proving that the web-facing worker changed.

Sources

Previous Post
eMudhra graphic announcing its exit from the global SSL and TLS certificate business

eMudhra TLS Certificates Could Break in Chrome on Oct. 27: What to Check

Related Posts