Security · 21 October 2026
Two critical PHP bugs, and the patch on our hosting by 4:00 PM
On 21 October 2026 the PHP project published two critical bugs that can let a stranger run code on a server that still has the old PHP. In the morning the fixed packages were not available through our hosting panel yet, so we put a temporary precaution in place. We then tested that the security release could be installed, installed it, and finished by 4:00 PM Pacific. After that we loaded the websites we host. They were running.
What PHP published
The announcement is on the PHP news archive for 21 October 2026. The same note covers four security releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Each release fixes the same two bugs. PHP’s wording is direct: every PHP installation that serves web requests is in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk highest for mod_php, where a demonstrated case reaches the bug before any application code runs. PHP-FPM, which is how most hosted sites run PHP, is in scope as well.
PHP 8.1 and older are outside the project’s normal security support. Some Linux vendors backport fixes for those lines. A site still on 8.1 or 7.x needs its vendor’s package, or a move onto a supported line. The changelog entries are listed under PHP 8.2.35 and the matching 8.3, 8.4 and 8.5 versions.
PHP also warned that the volunteer Remi RPM repository would not have the packages the same day, and asked people who depend on it to use distribution packages or build from source so they could update immediately. That matched the morning on our side: the hosting panel could not offer the security release yet.
The two bugs, in plain language
CVE-2026-109618 is an out-of-memory problem. PHP uses a hard jump out of the current work when a request runs out of memory. If that jump happens while internal request data is only partly set up, the shutdown routine can read or branch on data that is not valid. The failed allocation does not have to be the thing that left the data half-built. PHP’s advisory, GHSA-w8hw-w9fx-j79w, describes the result as remote code execution as the web worker account. The person sending the request does not need a password.
The patch stops using that hard jump for out-of-memory. PHP instead handles the failure at a safe point in the engine, and still keeps a hard stop if memory use climbs past a second, higher line. Shutdown no longer sees the broken state, and a normal memory limit still works.
CVE-2026-109619 is leftover state. A PHP worker, the process that answers request after request, keeps global fields for errors, sessions, objects and extensions. Those fields must be cleared before the memory of the last request is freed. Some work runs before the next request is fully initialized, and it can touch state that still points at freed memory. With the right heap layout, that becomes remote code execution. The advisory is GHSA-6wmf-4rv5-p3rp.
One confirmed way to reach that second bug on PHP-FPM is session upload progress. PHP can record how far a file upload has gone and store that progress in the session. That code runs early, before ordinary session setup on the next request, so it can consume session or decoder state left behind by an interrupted request. It does not require the application to call session_start(). Turning the feature off in the main PHP configuration, where a site cannot switch it back on with ini_set() or a per-directory file, blocks that confirmed path. PHP is explicit that other variants of the stale-state bug remain.
Why the morning setting was not the fix
PHP’s own sentence on the release notes is the one to keep: there are no complete mitigations, and updating is the only safe choice. The temporary settings reduce specific paths. They do not make an old PHP safe.
For the out-of-memory bug, PHP’s temporary advice is an administrative memory_limit of unlimited, plus tighter limits on how large and how complex a POST body can be. Unlimited memory is a real tradeoff: it removes one trigger and can hurt the server in a different way. For the stale-state bug, the session-upload-progress switch blocks the confirmed session path and leaves other variants open. On PHP 8.5 there is a separate fatal-error backtrace switch. Hiding warnings with error_reporting or display_errors does nothing for either bug.
So a responsible morning, when the packages are not in the panel yet, is a locked precaution plus a plan to install the release the same day. It is not a week of “we changed a setting, so we are done.”
What we did on 21 October
Morning. The security release was not available through the hosting panel yet. We turned off PHP session upload progress, locked the setting so a site could not turn it back on, and reloaded PHP. File uploads themselves stayed as they were. This is the confirmed PHP-FPM path for CVE-2026-109619. We treated it as a precaution, and we said so.
Then we tested the release. Before rolling the packages onto the hosting environment, we confirmed the security release could actually be installed on the stack we run. A panel that does not list the version in the morning is not the same thing as “this server cannot take the update.” The test was there to answer that question before the install.
By 4:00 PM Pacific, the patch was in. We installed the 21 October 2026 PHP security releases. That is the step PHP calls the complete fix. After the install we loaded the websites we host. They were running normally.
Alexey, founder of Metro Vancouver IT, did this work and reviewed this note. The byline on the article is the same person.
If your site is on another host
Ask one question: which PHP version answers web requests right now? You want 8.2.35 or newer on the 8.2 line, 8.3.36 or newer on 8.3, 8.4.27 or newer on 8.4, or 8.5.12 or newer on 8.5. A host that says “we disabled a setting” has done the morning step. The finished step is the version number.
If you cannot update today, the public precaution for PHP-FPM is session.upload_progress.enabled=0 in the main configuration, then a reload of every PHP worker. Keep it where the site cannot override it. Treat that as a few hours of reduced exposure, and keep the update at the top of the list. Unlimited memory and a smaller post_max_size are the matching public notes for the out-of-memory bug, with the tradeoff above. Details are in the two advisories linked earlier.
WordPress, Drupal, Magento and a custom PHP app are in the same boat. The bugs are in PHP, underneath the application. A current plugin set does not close them.
Frequently asked questions
What is CVE-2026-109618?
It is the out-of-memory bug. If PHP aborts a request because it ran out of memory while internal request data is only partly initialized, cleanup can treat that invalid data as real. The practical impact PHP reports is unauthenticated remote code execution as the web worker account. The fix is in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
What is CVE-2026-109619?
It is the stale-state bug. A worker can keep internal pointers from one request after that request’s memory has been freed. A later request on the same worker can use those pointers before normal startup clears them. On PHP-FPM, session upload progress is a confirmed way to reach that path, and it does not require the application to start a session itself.
Does turning off session upload progress fix the issue?
It blocks one confirmed path on PHP-FPM, the session upload progress consumer for CVE-2026-109619. PHP says other variants remain, and CVE-2026-109618 is a separate bug. The setting is what we used in the morning because the security release was not in the panel yet. The complete fix is the security release, which was installed on our hosting by 4:00 PM Pacific the same day.
Which PHP versions include the fix?
PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 and PHP 8.5.12, announced on 21 October 2026, and later versions on those lines. PHP 8.1 and older no longer receive these fixes from the PHP project. Some distributions backport them. Check the version your host is actually running, not the version a control panel advertises as available.
Do I need to do anything on Metro Vancouver IT hosting?
No action is needed for the sites we host. The security release is installed, and the websites were checked after the update and were running. If you also run PHP somewhere else, a laptop, another host, or an old app server, that copy needs the same release on its own.