CVE-2026-109619: a PHP worker remembers someone else's request

CVE-2026-109619 shipped the same day as the out-of-memory bug, and the two get collapsed into one headline. They are different failures. Here PHP is not dying on a memory cap. It frees the request memory and leaves pointers to it in globals. The next HTTP request on that same worker starts on someone else's data, before the interpreter reinitializes.

In plain language

Think of a waiter who leaves the previous bill on the table and hands it to the next guest. The guest can write anything on it. A PHP worker serves requests one after another. If a fatal error leaves a "bill" in the globals, the new request picks it up. Code execution without a login is confirmed: on mod_php via a fatal-error backtrace path, and on mod_php and FPM via the session lifecycle. PHP scored it 9.2.

What actually broke

Some request state lives in process globals, not in memory that is guaranteed to reset between requests. After the free, that memory no longer belongs to the request, but the pointer is still there. It is a use-after-free, at the level of PHP's own bookkeeping rather than your site code. "We do not call dangerous functions" is not a defense: execution never reaches your project.

The fix is in the same builds: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Until the worker restarts, it keeps running the old code. PHP 8.1 and older again have no release. A separate point: even after this patch, CVE-2026-115560 remains if session upload progress is enabled. The 21 October update does not close it.

What to do

• Install the 21 October build and confirm php-fpm or Apache actually reloaded. The package date and php -v should agree.
• Turn session.upload_progress.enabled off until the third bug has its own fix. That is PHP's own advice, not a forum workaround.
• If odd files or processes were already there before the upgrade, the patch does not delete them. That is incident work, not a version bump.