PHP Critical Security Bugs: October 2026 Fixes and Session Follow-up

PHP released fixes for two critical remote code execution vulnerabilities on 21 October 2026. This report was checked on 23 October and also includes today's separate session upload progress advisory. The distinction matters: the main security releases address two disclosed bugs, while the new notice describes an additional, narrowly conditioned issue.

The two critical advisories are CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 under CVSS v4.0. Under the required conditions, exploitation can run code without an authenticated account. This is a PHP engine security update, so reviewing application dependencies alone does not answer whether the PHP runtime has been patched.

Bug 1: out-of-memory handling can corrupt internal state

The CVE-2026-109618 advisory describes a failure during memory allocation that can interrupt PHP while request-owned structures are only partly initialized. Later cleanup can use that invalid state. The advisory documents remote code execution against Apache mod_php before application code begins.

Its patch changes how PHP handles memory exhaustion so execution does not abandon those unsafe intermediate states in the same way. The advisory identifies updating to a release containing the fix as the complete mitigation. A configuration workaround that reduces one trigger should not be presented as equivalent to installing the patch.

Bug 2: stale state can survive into another request

The CVE-2026-109619 advisory concerns worker-level state that still points to memory from a request after that memory has been released. A later request on the same worker can reach the stale value before ordinary initialization replaces it. The affected paths depend on configuration, extensions and application behavior.

The advisory includes session upload progress and early initialization diagnostics among the relevant paths. Hiding errors with display settings does not prevent the underlying invalid access. Updating with the complete state-reset patch is the reliable remediation; the listed configuration mitigations cover particular paths rather than every possible variant.

Which PHP releases contain the main fixes?

Both linked advisories list these patched versions for the supported branches. Earlier upstream releases within each branch are affected.

The 21 October PHP announcement includes PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed in its web-serving risk scope. It describes mod_php as the highest-risk case. It also directs distribution users to their vendors for patched packages; a vendor backport must be checked against that vendor's notice.

23 October follow-up: session upload progress

In a new informational advisory dated 23 October, PHP recommends session.upload_progress.enabled=0 until the next regular bugfix release for an unlikely RCE path. The described combination requires session serialization configured as php_binary or php_serialize, a runtime switch to php before session_start(), and upload progress still enabled. Applications that never change the serializer at runtime can keep the feature enabled. PHP says a full advisory for CVE-2026-115560 will accompany the next release.

Keep this follow-up on the same change record as the main update. It should not be lost when someone marks the first two CVEs as patched, nor generalized into a claim that every PHP application has the additional configuration combination.

Why the disclosure date is not the discovery date

The PHP Foundation's 21 October account traces signs of the OOM problem back to work following a 2024 audit. It says later reports made the practical RCE impact clear and discusses compatibility trade-offs and changes to security coordination. These are recently disclosed and fixed issues with an earlier research history, rather than proof that all discovery happened this week.

Toolzify analysis: what to check before closing the update

Our recommendation is to keep the task focused on the runtime serving the application and the configuration it actually uses. This section is editorial guidance, not a report that Toolzify has upgraded your server or reproduced an exploit.

1. Identify every application runtime. Record the site, PHP branch, deployment image or package and worker service. A terminal PHP executable may be different from the one serving web requests. Keep those observations separate until you can connect them to the same application.
2. Match the package to evidence. For upstream builds, compare the branch with the fixed versions above. For vendor packages, read the applicable security notice and package revision. Retain the source of that conclusion so a reviewer can distinguish a verified backport from an assumption based only on a short version string.
3. Review the session follow-up deliberately. Have the application owner check whether its session serializer changes at runtime and whether upload progress is needed. Apply the official guidance through the appropriate server configuration process. Record what was checked, rather than silently copying a setting into a single script.
4. Replace the running workers and check normal behavior. Follow the deployment's restart or replacement procedure, then verify the active build. Exercise representative application paths such as a normal page, login/session flow, an expected error and a required upload. Record actual outcomes, including failures that need follow-up.
5. Keep the scope of success precise. A passing smoke test shows that the tested workflow still operates. It does not establish that exploitation never occurred or that the whole application is free of vulnerabilities. Keep any incident investigation separate from routine update verification.

This article provides primary-source news and an operational checklist. No server configuration or PHP runtime was changed to produce it, no attack payload was executed, and no compatibility benchmark is claimed. Follow the dated official advisories for later corrections and subsequent releases.