PHP released fixes for two critical remote code execution vulnerabilities on 21 October 2026. Teams serving web requests should treat this as runtime maintenance that needs a verified rollout. The PHP security announcement calls for an immediate update across PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
There is also a separate 23 October follow-up about session upload progress. Keep that configuration review alongside the runtime update.
What the two fixes address
- CVE-2026-109618: RCE via OOM corruption. An interrupted memory allocation can leave internal request data invalid. Cleanup may then use that data. The advisory describes a confirmed mod_php attack that runs before application code starts.
- CVE-2026-109619: RCE via stale global state. A worker can retain references to memory from a finished request. A later request may use that stale state before normal initialization clears it.
The SAPIs do not have identical failure paths. PHP-FPM is not universally immune, and a mod_php demonstration should not be described as proof that every deployment is equally exploitable.
Install the security release for your branch
The fixed releases published on 21 October are:
- PHP 8.2.35.
- PHP 8.3.36.
- PHP 8.4.27.
- PHP 8.5.12.
Use one of these releases for the corresponding supported branch, or a later vendor-confirmed patched package. For managed hosting, ask which runtime package is installed and when all workers will restart. Distribution and LTS packages may contain backports; check the vendor's security record. PHP 8.1 and older no longer receive regular upstream fixes. See the release and update guidance.
Make the rollout cover every worker
Our suggested rollout sequence is:
- Identify the web-serving PHP runtime, worker pools, extensions and deployment image.
- Update through the hosting or operating-system package channel you maintain.
- Restart or replace every affected worker. Include Apache or other server processes that load PHP as a module.
- Check sign-in, session handling, expected uploads and background tasks in staging with synthetic data.
- Verify the production package and worker state after deployment, then monitor application errors and resource use.
An installed package and a running process are separate things. Record both the updated package and the process replacement so an old worker is not left serving requests.
Do not use the CLI version as proof of the web runtime
These commands are useful during inventory:
php -v
php --ini
They show the command-line PHP version and configuration files, as documented in the PHP CLI options. They do not establish the version or settings used by Apache, PHP-FPM or another web SAPI.
Confirm the web runtime through the hosting control plane, deployment records and the actual server or pool configuration. The PHP configuration manual explains that configuration loading depends on the SAPI. Avoid adding a public phpinfo page to perform this check.
Apply the 23 October session follow-up where relevant
PHP's 23 October informational advisory describes an uncommon combination: configuration selects php_binary or php_serialize, application code switches the handler to php before starting the session, and session upload progress remains enabled.
The recommendation is to set session.upload_progress.enabled=0 until the next regular bugfix release for that situation. Applications that never switch the handler at runtime can keep the feature enabled. The notice identifies CVE-2026-115560, with a full advisory planned for the next release. As of this article's publication, that notice does not specify a fixed release.
Keep this follow-up separate from the two vulnerabilities patched on 21 October.
Temporary configuration changes have limits
For the confirmed session paths in CVE-2026-109619, disabling upload progress must take effect before request parsing. Use the appropriate php.ini, pool or server configuration and restart every worker. An application-level ini_set call or FPM .user.ini is too late for this path. The stale-state advisory also explains why hiding warnings or disabling error display does not protect the process.
These measures cover particular paths. They do not replace the complete patch. Likewise, changing PHP's memory limit is not a general fix for CVE-2026-109618. The OOM advisory documents remaining allocation-failure risk and availability tradeoffs.
If patching is delayed, have the platform owner choose temporary controls for that deployment and record their limits. Keep the runtime update scheduled rather than closing the issue after a configuration change.