CVE-2026-109619 in PHP: reused global state, sessions, and code execution
Published on 2026-10-27 by frfrand
Practical analysis of CVE-2026-109619: what fails in PHP workers, patched versions, official temporary mitigation, and how to update.

A different flaw, published the same day
On October 21, 2026, PHP published a second critical vulnerability: CVE-2026-109619. Unlike the OOM memory flaw in case CVE-2026-109618, here the problem is linked to internal state that improperly survives after memory is freed. This can cause a PHP worker to reuse references that are no longer valid and, under specific conditions, allow memory corruption or remote code execution.
What is a PHP worker and why does it matter?
A worker is a process that handles requests. Many environments reuse it to respond to successive visitors. The application should leave the correct state between one request and another, and the engine must clean up temporary references. If something is left pointing to freed memory, a phenomenon called use-after-free can occur.
How was it discovered and who does the report correspond to?
The investigation was presented by Wiz Research and the PHP team, along with the other October 2026 CVE. The researchers examined how certain execution errors could interrupt the cleanup of internal data and leave a dangerously reusable state. Coordinated disclosure allows the public to learn about the flaw along with the fixed versions.
How can it be exploited?
The general scenario involves driving request processing toward errors that leave internal state inconsistent. A subsequent operation may use references to already freed memory. Under conditions favorable to an attacker, this could facilitate code execution or exposure of process data. Exploitation varies according to mod_php, PHP-FPM, application type, and its configuration. A reusable procedure for compromising servers should not be disseminated; for defense, what matters is the patch and exposure conditions.
Why is it a critical problem?
A PHP process may have access to files, connection secrets, and internal application operations. Executing code with those permissions may be enough to cause significant damage. But the critical rating does not imply that all installations can be exploited in the same way: there are configuration dependencies and server characteristics.
Which versions need to be updated?
The PHP project patches are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Branches 8.1 and earlier do not receive regular patches from the project; consult extended maintenance providers or plan migration. Some Linux distributions may carry backported fixes under a version number that appears earlier, so check the installed package bulletin.
What temporary mitigations did PHP publish?
The team recommended disabling session.upload_progress.enabled before request processing and restarting all workers to block confirmed routes related to sessions. In PHP 8.5 it also mentioned fatal_error_backtraces=0 as a measure for another known route. They are partial and conditional defenses: the vendor itself warns that they do not replace installing the patch. In the October 23 announcement it also described a very unusual scenario of dynamic session serializer changes related to a subsequent investigation, reminding that configurations matter.
How to review an application?
Inventory PHP version, server type, session configuration, upload usage, and processes that were not restarted after applying changes. If exploitation is suspected, review logs and processes, web user privileges, file changes, and credentials that may have been left accessible. Preserve evidence before performing indiscriminate cleanup.
Quick questions
Does it affect WordPress? It can affect a WordPress served by a vulnerable PHP: it is a runtime defect, not of the theme.
Does changing the password fix this? No, although it may be part of an incident response.
What do I do today? Update all runtimes serving traffic, restart workers, and verify running versions.
Sources: PHP Advisories October 2026 · UK NCSC Bulletin · Red Hat CVE · CVE Registry.
Where is the information updated and how to request guidance?
At ArduMaker — CVE and support we maintain information to review incidents and channel inquiries, especially in WordPress and the technologies that run it. To evaluate a specific case, provide technology, version, operating system, deployment mode, and relevant error messages without publishing credentials. An announced CVE does not mean that all systems are compromised.
Editorial review: October 27, 2026. Recommendations may change with new vendor publications.
Practical example: checking PHP session configuration
Situation: a PHP website uses sessions and file uploads, with PHP-FPM handling multiple requests per process. CVE-2026-109619 relates to internal references that improperly survive between requests.
First identify the effective service configuration, not just the console. As initial guidance:
php --ini
php -i | grep -E 'session.upload_progress.enabled|PHP Version'
Note: CLI configuration may differ from Apache and PHP-FPM. The PHP bulletin describes disabling session.upload_progress.enabled and restarting workers as a temporary measure for known paths. Do not consider it a complete patch.
Before: an isolated change in php.ini that was never applied to the workers and a vulnerable version. After: fixed version, FPM configuration verified, service restarted, and login/file upload tests performed.
Example impact: if a worker reuses invalid internal state, a subsequent request could interact with freed memory. That is a runtime error, not a user cookie "badly written".
