PHP issued a new upload-progress advisory on October 23, two days after shipping emergency releases for two critical remote-code-execution flaws. The project recommends setting session.upload_progress.enabled=0 until the next regular bugfix release to cover an additional, unlikely code-execution path. Administrators of PHP sites that accept web requests should check the setting even if they have already installed the emergency update.
That update fixed two memory-corruption vulnerabilities, CVE-2026-109618 and CVE-2026-109619, in PHP web services. An unauthenticated attacker with network access can send crafted HTTP requests and potentially execute code in a vulnerable worker. CERT/CC says a proof of concept against Apache mod_php reaches the vulnerable path before application code runs. The October 23 upload-progress advisory concerns a separate issue, CVE-2026-115560, planned for a later release; the emergency patches remain the necessary fix for the original pair.
Two ways PHP workers fail
The PHP-assigned record for CVE-2026-109618 describes an out-of-memory interruption while request data is partly initialized. PHP aborts the current context; cleanup can then treat invalid request memory as valid. The record for CVE-2026-109619 describes a different lifetime mistake: global state keeps a reference to memory owned by a finished request, and another request on the same worker may touch that freed memory before normal initialization resets it. Both records rate the flaws critical, with CVSS v4.0 base scores of 9.2.
The PHP release advisory covers web-serving PHP in PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The same worker may handle multiple requests; application code alone cannot shield a service when the request parser or worker state fails first. CERT/CC and PHP call for updates to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on their respective maintained branches. PHP 8.1 and earlier need a vendor-supported backport or an upgrade to a supported branch; the PHP project also supplied limited source backports for 7.4, 8.0 and 8.1 to help source builders.
The later upload-progress warning
The PHP project says the additional path requires an unusual combination: an application configures session.serialize_handler as php_binary or php_serialize, switches it to php with ini_set() before session_start(), and leaves session upload progress enabled. PHP describes the path as unlikely and plans a full advisory for CVE-2026-115560 with the next release. Applications that never change the serializer at runtime can keep upload progress enabled. For administrators who cannot promptly establish that condition across their applications, PHP’s precaution is direct: “We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector.”
The project had already named session.upload_progress.enabled=0 as an interim measure for the confirmed session paths in CVE-2026-109619. Set it in php.ini, an FPM pool or server configuration applied before request parsing, then recycle every serving worker so the effective setting changes. PHP says ini_set() and FPM .user.ini are too late for that protection. A setting already disabled under the October 21 guidance needs no additional change for this advisory.
Verify builds and live settings
Map each web entry point to the PHP runtime actually serving it, including embedded or bundled PHP, and compare that runtime’s installed build with the release floor for its branch. For a distribution build, check the vendor advisory for its installed package: upstream version strings alone can miss vendor backports. This work extends our earlier advance warning, which told teams to locate PHP ahead of the release.
Read the effective session.upload_progress.enabled setting from the serving configuration after worker recycling, especially on sites that change session handlers at runtime. A command-line PHP configuration may differ from a web worker’s pool or server configuration. If patching the original pair is delayed, PHP’s interim guidance also calls for an administrative memory_limit=-1, bounded request sizes, and limits on request fields, multipart parts, headers and nesting; those measures reduce specific paths rather than replace the fix. Avoid RLIMIT_AS and RLIMIT_DATA as memory guards here: failed allocations under those limits can reach the vulnerable out-of-memory path. On PHP 8.5, PHP also recommends fatal_error_backtraces=0 and restarting every worker to block the confirmed fatal-backtrace path. Container or cgroup limits can instead contain worker availability impact.
Confirm each web worker changed
Install a fixed or vendor-backported build for both original CVEs, then check the build loaded by every live serving pool. Set session.upload_progress.enabled=0 in pre-request configuration where PHP’s later precaution applies, recycle the workers, and read back the effective value from the web-serving context. Correlate unusual PHP worker exits or memory-allocation behavior with the web requests those workers handled; retain request and worker logs for investigation.
The fixed build addresses the two disclosed memory flaws. The upload-progress setting covers the newly described, narrow session path until the next release. Record the live build and effective setting together for each serving pool.