The October 2026 PHP security release: a WordPress developer's checklist
Contents8
On 21 October 2026 the PHP project shipped fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 and both can allow unauthenticated remote code execution: someone with no account on your site can run their own code on your server.
Most write-ups stop at "update PHP". That's the right answer, but it leaves out the questions I get from people who run WordPress sites: how do I check, what do I ask my host, what if I look after twenty sites, and do plugin developers need to change anything? This post covers those, in the order I'd work through them.
What happened, briefly
The PHP team released patched versions of every supported branch:
| Branch | Fixed version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 (end of life on 31 Dec 2026) |
The two flaws are different:
- CVE-2026-109618 comes from how PHP handles running out of memory. If memory runs out at the wrong moment, request data can be left half set up, and the cleanup code then treats it as valid. PHP's advisory rates this highest on Apache with mod_php, where the attack can happen before any application code runs.
- CVE-2026-109619 is about internal state that outlives the request that created it. A later request handled by the same PHP worker can pick up that stale state before it is reset.
The advisory says every PHP install that serves web requests is affected: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. Details leaked a day early, and attacks started before the fix was out, so this isn't one to leave for next week.
Why updating WordPress won't fix it
The bug is in PHP itself, one level below WordPress, your theme and your plugins. WordPress.org says it plainly: no WordPress update is required or planned for this.
So "all my plugins are up to date" tells you nothing here. What matters is the PHP build your server is running, and on most sites that belongs to your host, not to you.
Step 1: check your PHP version
In the WordPress admin, go to Tools > Site Health > Info > Server. The PHP version is listed there. Most hosting control panels show it too.
Compare it with the table above. You're fine if you're on that version or newer for your branch. For example, 8.3.36 is patched and 8.3.35 is not.
If you're on PHP 8.1 or older, the PHP project no longer ships fixes for it. Some hosts and Linux distributions backport security patches to old versions, so the version number alone won't tell you. Ask your host directly, and treat this as the push to move to a supported version.
Step 2: what to ask your host
If your host manages PHP for you, which is most shared and managed WordPress hosting, send them one short message:
Is my site running a PHP build patched for CVE-2026-109618 and CVE-2026-109619? If not, when will it be, and are WAF rules in place until then?
Many large hosts patched or added firewall rules within a day, and several posted updates on their status pages. If yours hasn't said anything, ask. A clear answer is better than assuming.
If you run your own server (a VPS, a droplet, your own Docker image), patching is your job. Update PHP, then restart every PHP worker so the old code isn't still sitting in memory. WordPress.org's advice for self-managed servers on unpatched versions is to consider taking the server offline until you can update.
Step 3: if you can't update today
PHP's advisory lists workarounds. It's clear that they reduce the risk without making a server safe, so use them to buy time, not to skip the update.
For the stale-state flaw (CVE-2026-109619):
; php.ini or the FPM pool, then restart every worker
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; PHP 8.5 only
This has to be set in php.ini, the FPM pool, or the server config. The advisory specifically says not to rely on ini_set() or a .user.ini file, because those apply too late.
For the out-of-memory flaw (CVE-2026-109618), the advisory suggests removing the memory limit at server level and keeping request sizes small:
; FPM pool: use php_admin_value so applications can't change it
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M ; 32M if you need uploads
php_admin_value[upload_max_filesize] = 2M ; keep below post_max_size
One WordPress-specific catch: WordPress raises its own memory limit with ini_set() (that's what WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT do). The advisory says to confirm nothing at the application level puts a finite limit back. Setting the values with php_admin_value handles that, because ini_set() can't override them.
Don't put a cap back with RLIMIT_AS or RLIMIT_DATA either. The advisory warns that those can trigger the exact allocation failure the attack relies on. Use a container or cgroup memory limit instead.
These settings also change how your site behaves. A tiny upload limit breaks media uploads and plugin installs, and an unlimited memory limit means one bad request can use a lot of RAM. That's the trade-off you accept for a day or two, not a setup to keep.
If you look after many sites
Agencies and freelancers with a list of client sites should work by risk, not alphabetically:
- Self-managed servers first. Nobody else will patch them.
- Anything on PHP 8.1 or older, especially on hosts that haven't confirmed a backport.
- Apache with mod_php, which the advisory rates highest.
- Managed hosts that haven't confirmed a patch. Send them the question from step 2.
- Managed hosts that have confirmed. Check the version in Site Health and note it down.
Keep a simple record for each site: PHP version before, version after, the date you checked, and who confirmed it. When a client asks "were we affected?", you can answer in one line.
What plugin developers should take from this
Updating PHP is the fix, and no plugin code change will patch these bugs. But the advisory's own workaround list says something worth reading if you write plugins: it asks people to fix fatal errors and execution timeouts that an attacker can reach, including in callbacks, upload and import processing, and cleanup code.
That's a good habit anyway. In practice, for a WordPress plugin:
- Validate input before doing heavy work. Check sizes, counts and types before you parse an uploaded CSV, unzip a file, or loop over a request array. A request that makes your code allocate huge amounts of memory is exactly the kind of fatal error the advisory is talking about.
- Don't let public endpoints run unbounded jobs. AJAX handlers and REST routes that anyone can call should do a small, bounded amount of work, with batching for anything big.
- Don't fix memory problems by raising limits in code. Calling
ini_set('memory_limit', ...)inside a plugin hides the real problem, and during an incident like this one it gets in the way of what the host is trying to do. - Test what happens on failure, not only the happy path. What does your import do halfway through a timeout? Does your cleanup code assume earlier steps finished?
None of this would have stopped this vulnerability. But code that fails in a predictable, bounded way gives attackers less to work with next time.
The short version
- Check Tools > Site Health > Info > Server for your PHP version.
- You need 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer on your branch.
- Updating WordPress or plugins won't fix it. Ask your host, or patch and restart PHP yourself.
- Workarounds buy time. They don't replace the update.
- If you're still on PHP 8.1 or older, this is the reminder to move.
If you'd rather not have to think about this next time, keeping PHP, WordPress and plugins updated and tested is exactly what I do on monthly care.
Sources: PHP security release announcement, GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, and WordPress.org's notice.