PHP releases emergency patches for two critical vulnerabilities

When a browser asks for a page, PHP loads the information it needs into memory and works on it. Think of memory as a desk where work is spread out for a while, and a worker as the person handling that job. The same worker can finish request A and then take on request B, so A’s temporary information should be cleared when its request ends.

What matters here is not a stored article file but the temporary data PHP uses while running, and the reference to it: a kind of address label saying where to read. If only the label remains and the spot it points to has already been cleared, the next task may read the wrong information. Official description of stale state

PHP needs memory, a temporary workspace, to handle a request. A per-request limit keeps one task from using too much, and stopping when that limit is reached is itself a protective behavior. But what happens if internal data is only half built at the moment it stops?

In the first flaw, CVE-2026-109618, an out-of-memory interruption could make execution leave the operation abruptly, after which cleanup could treat half-built data as if it were valid. It is like handing an unfinished order form to the next person, who assumes it is complete. Unlike a website merely slowing down, the program handles invalid memory in a way that can affect what it executes. Official cause

The fix records that execution must stop and halts it at a safe execution point. A separate emergency path immediately ends the worker process if consumption first reaches a higher final limit. The figure simplifies the 8.5 fix, which neither removes the memory limit nor switches off the whole computer.

The second flaw, CVE-2026-109619, is about two things whose lifetimes fall out of step: the data, and a note recording where the data is. A PHP worker could finish visitor A’s request and free its temporary memory while part of the state pointing into that memory survived. When the same worker took the next request, B, there was a path that touched that old state before the new initialization had finished. Official explanation

Imagine shredding a document but keeping a note that says “the document is in slot 3.” Open slot 3 later and there is no guarantee the same document is there. The analogy shows what it means to keep trusting a location that is no longer valid. The real flaw is in PHP’s internal memory; it is not a matter of a previous visitor’s post simply staying on screen.

The fix clears leftover references and state when a request ends, and also deals with information that reappears during shutdown and with access paths before the next initialization. Rather than counting on the next customer’s arrival to tidy up, it makes sure the next task cannot pick up invalid information once the current one ends.

PHP 7.4 is a branch whose normal support from the PHP project has ended. Given the severity, minimal fixes adapted for older branches were specially provided this time; these are called backports. Even after the code is published, a host still has to package it, distribute it and install it on your server. Official guidance · End-of-life record

The 7.4 fix is a minimal response built separately from 8.5. When a dangerous memory error occurs it ends the worker, clears freed location information and blocks the identified session upload-progress path. It does not block ordinary file uploads as a whole. The code appendix shows the actual differences.

Here is a fictional example, “Hosting A.” The company and situation are illustrative; the PHP release numbers are real. If Hosting A’s panel shows PHP 8.3.35, don’t stop at “it’s the 8.3 branch, so we’re fine”; ask whether 8.3.36 or a package backporting both fixes has been supplied and installed. If it shows 7.4.33, rather than waiting for a new official 7.4 release number, ask about the host’s extended-support fixes and the route to a supported branch.

WordPress is an application that runs on PHP. Updating WordPress core and plugins and fixing the PHP the server runs are jobs on different layers. PHP’s announcement urges updates for every installation serving web requests and considers the risk highest for mod_php, citing a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code runs. PHP announcement · WordPress PHP guidance

mod_php runs PHP inside the Apache web server; PHP-FPM uses separate PHP worker processes that receive requests on their own. The first advisory notes a limitation on a particular FPM startup path, but that cannot be read as FPM being safe overall: the second advisory records a validated FPM path under its stated conditions. Conditions for the first flaw · Conditions for the second flaw

On the morning of October 22, I switched PHP for one live application at Cloudways, which I use for a personal WordPress deployment. This was done on the production app without a separate staging clone. The site name, domain, account and server identifiers are not published.

First, I secured a file and database restore point at 06:57:52 JST on October 22. The newest branch selectable under this app’s Application Settings → PHP Settings was 8.4. I used the per-application selector, so the change applies to that app and did not alter every PHP environment on the server. Cloudways per-application instructions

Cloudways displayed a “PHP version updated successfully” notification. When I then freshly loaded WordPress Tools → Site Health → Info → Server, web-facing PHP had changed from 7.4.33 to 8.4.26, and the server API was fpm-fcgi, meaning PHP-FPM. These are actual screens from the same operation, not product images redrawn by AI.

At 07:19 JST on October 22, Cloudways announced that interim configuration mitigations recommended by the PHP Group had been deployed across its fleet and official patches were rolling out in phases. Its 10:02 JST update then reported patches applied to all customer applications on Autonomous, with rollout continuing on Flexible. Autonomous and Flexible are different Cloudways hosting products; the application in this case uses Flexible. Cloudways incident

Freshly loading the same app’s WordPress server information at 14:03 JST on October 22 showed web PHP 8.4.27 and fpm-fcgi. PHP’s official 8.4.27 ChangeLog lists fixes for both security advisories. This establishes that the PHP actually serving web requests for this app now reports the official fixed version. No version change or settings save was performed during this recheck; the exact package replacement time is unknown. Official 8.4.27 ChangeLog

At 19:11 JST on October 22, Cloudways announced that its PHP security patch rollout was complete and all active servers had been updated. It repeated the announcement at 19:20 JST, adding that support was contacting a small subset of customers whose environments needed further assistance. At 19:22 JST, it said it was continuing to monitor for further issues; the incident status at that time was monitoring. Cloudways completion notice

The last direct observation of this app remains web PHP 8.4.27 / fpm-fcgi at 14:03 JST. The authenticated app session was inaccessible in the evening, so a further runtime recheck could not be completed. The provider’s fleet announcement and the afternoon app observation retain their own timestamps; they do not establish the state of CLI, scheduled jobs or every plugin function.

The table above and warning screenshot below record the 07:08 JST morning observation. At 14:03 JST, the page instead showed max_input_vars 10000, post_max_size 100M, upload limit 30M, memory limit -1, and execution time 300 seconds. -1 means no PHP memory limit for this setting; none of these values was changed during this review. The page does not show who changed them, when or why, so the morning 10M warning and the provider’s interim measures cannot be assumed to remain in the same state.

Switching versions can change settings too, and here two input-related limits appeared different. A changed input limit doesn’t mean the site is broken, but features that save large settings pages or menus are worth testing. This review covered the read functions above; every plugin feature, post saving, file uploads and scheduled jobs have not been tested yet.

During the morning review, I did not restore the request limit to 100M just to clear the warning. PHP’s official guidance also recommends smaller request limits as an interim measure to reduce exposure to some attack paths. Whether the morning 10M and input-field limits came from those measures was unverified; the reason for the afternoon’s changed values is also unknown. This record is not a recommendation to raise limits or remove memory restrictions. No settings were saved during this additional review. PHP interim measures and limits

Whatever you do about 7.4 right now, plan a move to a supported branch as well. Cloudways’ current Flexible instructions have you choose the version under My Applications → application → Application Settings → PHP Settings → PHP Version. Paths and what is offered can vary with the account, operating system and interface; its documentation, for example, says PHP 8.4 requires Debian 11 or 12. Cloudways upgrade instructions

• First, have current file and database backups and a way to restore them.
• Find out whether WordPress, the theme and plugins work with the target PHP, and try the switch on a cloned staging site first.
• Ask the supplier whether the final fixed package for that branch is available before changing production, and look at how far the change reaches other applications on the same server.
• After applying it, test the functions actually in use: article pages, administrator login, search, enquiries, bookings or payments. Recheck web PHP under WordPress Tools → Site Health → Info → Server, and for a backport, record it together with the supplier’s fix history.

PHP’s guidance also lists interim settings that reduce exposure to particular paths, while stating that only an update is a complete solution. Settings such as removing the memory limit outright are not a fix a beginner should copy as is. Official measures and limitations · Site Health documentation