Most security news in the WordPress world is about a plugin. This PHP security update is not, and that changes who has to act. The two bugs live in PHP itself, the language every WordPress site runs on, so updating plugins does nothing. You need to know three things: which PHP version your site is really on, who is allowed to change it, and what to do while you wait. This guide covers all three, using the official PHP advisories rather than second-hand summaries.
What the October PHP security update fixes
The PHP project gave a day’s advance notice on 20 October, then published the PHP security update on 21 October 2026. It fixes two vulnerabilities that the project’s own advisory describes as allowing unauthenticated remote code execution. In plain terms, an attacker who never logs in could make your server run code of their choosing.
| CVE | Name in the advisory | What goes wrong | Score |
|---|---|---|---|
| CVE-2026-109618 | RCE via OOM corruption | An out-of-memory error can interrupt PHP while request data is half set up, and cleanup then treats that broken data as valid | CVSS v4.0 9.2 |
| CVE-2026-109619 | RCE via stale global state | Internal state can outlive the memory behind it, and a later request on the same worker can use it before it is reset | CVSS v4.0 9.2 |
Both are memory-safety bugs of the use-after-free family. What makes them serious for website owners is the timing. According to the advisory, the confirmed attack against Apache’s mod_php runs before any application code runs. WordPress never gets a chance to see the request, so no security plugin, firewall rule inside WordPress or login protection is in a position to stop it.
One honest caveat about the score. The CVSS vector marks attack complexity as high, and the advisory says exploit reliability depends on the build, extensions and memory layout. That does not make it safe to wait. It means a 9.2 here is “hard to weaponise reliably, catastrophic when it works”, which is exactly the profile that gets automated once someone publishes a working exploit.
Which PHP versions are affected, and which are fixed
Every supported branch received the PHP security update on the same day. If your version number is lower than the one in the fixed column, your server has not had the PHP security update yet.
| Branch | Vulnerable | Fixed in | Notes |
|---|---|---|---|
| PHP 8.5 | below 8.5.12 | 8.5.12 | Also has an extra confirmed path through fatal_error_backtraces |
| PHP 8.4 | below 8.4.27 | 8.4.27 | The most common branch on current hosting |
| PHP 8.3 | below 8.3.36 | 8.3.36 | Supported, security fixes only |
| PHP 8.2 | below 8.2.35 | 8.2.35 | Reaches end of life on 31 December 2026 |
| PHP 8.1 and older | all | no official release | Source backports published for 7.4, 8.0 and 8.1; distributions may ship their own |
The last row is the one that should worry people. The PHP team took the unusual step of publishing minimal source backports for 7.4, 8.0 and 8.1, which tells you how seriously they rate this. But a source branch on GitHub is not a package your host can install with one command. If your site still runs PHP 7.4, this PHP security update is the clearest argument you will get for finally moving, and the practical side of that move is covered in what to do when a PHP upgrade breaks WordPress.
Who is actually at risk
The PHP security update matters for every common way of running PHP for the web, and the advisory names them: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The level of confirmation differs, and it is worth knowing where your stack sits.
| How PHP runs | Status in the advisories | Typical hosting |
|---|---|---|
| Apache mod_php | Confirmed exploit for both bugs, highest risk | Older VPS builds, some self-managed servers |
| PHP-FPM | Confirmed for the session upload progress path of CVE-2026-109619; the OOM bug is suspected from source analysis | Most modern VPS and managed hosting |
| LiteSpeed (LSAPI) | Rated likely susceptible, application-specific exploits not validated | Many shared hosts |
| FrankenPHP | Rated likely susceptible from source analysis | Container and modern app deployments |
Do not read “likely” as “probably fine”. The PHP project’s own instruction is that all PHP users should apply the PHP security update immediately, and the patch costs far less than finding out which column you were really in.
Check which PHP version your site really runs
Before you chase anyone about a PHP security update, find out what you are on. This is less obvious than it sounds, because a server can run several PHP versions at once, and the one you see in a terminal is often not the one serving your pages.
Method 1: Site Health (the version your visitors hit)
In WordPress, go to Tools → Site Health → Info → Server and read the PHP version line. This is reported by PHP running inside a real web request, which makes it the number that matters. If you are unsure what else on that screen deserves attention, our guide to Site Health warnings separates the useful ones from the noise.
Method 2: the command line, with care
# What WP-CLI runs under. Often NOT the web version.
wp --info | grep -i 'php version'
# The default CLI binary. Again, may differ from the site.
php -v
# On cPanel/CloudLinux servers, list the installed alternatives
ls /opt/cpanel/ | grep ea-php
ls /opt/alt/ | grep phpIf the command line says 8.4.27 and Site Health says 8.4.26, the PHP security update has not reached your site yet. Believe Site Health. The web pool is what an attacker talks to, and it is common for the CLI to be patched first while the site sits on an older handler.
Method 3: the response header
curl -sI https://example.com/ | grep -i 'x-powered-by'If this prints something like X-Powered-By: PHP/8.4.26, your server is announcing its exact version to every scanner on the internet. That is worth fixing regardless, and we come back to it in the interim measures below. If it prints nothing, good: the header is hidden, and you will need Site Health instead.
A trap with Linux distribution packages. Debian, Ubuntu, Red Hat and similar vendors often backport security fixes without changing the upstream version number. A distribution package can report 8.2.something and still contain the PHP security update. If your server uses distribution PHP rather than a control-panel build, check the vendor’s security tracker for these two CVEs instead of relying on the version string alone.
Who applies the PHP security update on your hosting
This is where most site owners get stuck, and it is the part the news coverage skips. Whether you can apply the PHP security update yourself depends entirely on what level of access your hosting gives you.
| Hosting type | Who patches PHP | What you do |
|---|---|---|
| Shared hosting | The host, for every customer at once | Check the version, ask for a date if it has not moved |
| Managed WordPress hosting | The host | Same, and expect a fast answer |
| Reseller or WHM without root | The host, not you | Open a ticket; you cannot run EasyApache yourself |
| Managed VPS | Usually the host, sometimes shared | Ask explicitly who is responsible |
| Unmanaged VPS or dedicated | You | Update packages and restart PHP today |
The reseller row deserves a word, because we hit it ourselves this week. A client’s server was one patch behind, on 8.4.26, and our access was through WHM. It looked like full control. It was not: a reseller-level WHM shows account management, email and SSL tools, but not EasyApache, MultiPHP Manager, the terminal or the service manager. Those need root, and root sat with the hosting company. A WHM login is not proof you can apply a PHP security update, so check before you promise a client you will.
If you do have root
On a server where you control the packages, the PHP security update is a normal package update followed by a restart of every PHP process. The restart is the part people forget.
# cPanel / EasyApache 4 servers
yum update 'ea-php*' # or: dnf update 'ea-php*'
/scripts/restartsrv_apache_php_fpm
# Debian / Ubuntu with distribution packages
apt update && apt install --only-upgrade 'php8.4*'
systemctl restart php8.4-fpmThen confirm the web pool picked it up, not just the CLI, by reading the version in Site Health again.
Package names vary by vendor and by which PHP repository your server uses, so treat these as the shape of the job rather than a script to paste blind. The advisory also flags one specific repository: users of the volunteer-run remirepo were told it would have no packages on release day, and were urged to switch to distribution packages or build from source.
If you do not have root: the ticket
Do not send “is my server safe?”. It invites a vague reply. Give your host the CVE numbers, your current version and a direct question, so the only useful answer is a date.
Support ticket template
Subject: Urgent - PHP security patch (CVE-2026-109618 / CVE-2026-109619)
Hello,
Our account/server [name] is currently running PHP [8.4.26].
On 21 October 2026 PHP released fixes for two critical unauthenticated
remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619
(CVSS 9.2). The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Please confirm:
1. When the patched build will be applied to our server.
2. Whether any mitigation is in place in the meantime.
We do not have root access, so we cannot apply this ourselves.
Thank you.Raising the ticket the same day also gives you a written record that you asked promptly, which matters if you look after sites for clients. And if your host cannot give you a straight date for a PHP security update rated 9.2, that tells you something useful about the host. Our notes on when it is time to change WordPress hosting cover what to weigh up.
What to do while you wait for the PHP security update
The PHP team is unusually blunt here: “There are no complete mitigations, updating is the only safe choice.” The measures below reduce exposure to specific attack paths. They do not make a server safe, and most of them need server-level configuration, so on shared hosting they are also host requests rather than things you can set.
| Measure | Helps against | Catch |
|---|---|---|
session.upload_progress.enabled=0, then restart workers | The confirmed session path of CVE-2026-109619 | Must be set in php.ini or the pool, not with ini_set() or a .user.ini |
fatal_error_backtraces=0 (PHP 8.5 only) | The confirmed backtrace path of CVE-2026-109619 | Blocks that path only |
memory_limit=-1, enforced with php_admin_value | The controllable memory-limit failure in CVE-2026-109618 | Removes a safety net; an underlying allocation failure can still trigger the bug |
Low post_max_size (8M, or 32M with uploads) | Oversized multipart requests that cause the out-of-memory state | Can break large media uploads |
Hide the version header (expose_php = Off) | Being found by automated version scans | Does not fix anything; it only makes you harder to pick out |
The memory_limit=-1 row needs judgement. WordPress sites hit memory limits for ordinary reasons, and removing the limit trades one kind of failure for another: a runaway plugin can now eat the server’s memory instead of dying with an allowed memory size exhausted error. On a busy shared server, that is not your call to make, which is one more reason this belongs in the ticket.
Two things you can do yourself, today, whatever your access level and however long the PHP security update takes to arrive. First, confirm your backups are running and that one of them has actually been restored somewhere, because a backup you have never restored is a hope rather than a plan; our guide to testing a WordPress backup walks through it. Second, know what compromise looks like, so you would notice. The early signs are in signs your WordPress site is hacked.
After the PHP security update lands
When your host says the patch is applied, verify it rather than taking the email at face value. Hosts roll updates out in waves, and a ticket can be closed while your particular server is still waiting.
| When | Check |
|---|---|
| Immediately | Site Health shows the fixed version (or the vendor confirms the backport) |
| Same day | Home page, admin, a form and checkout all work |
| Same day | WP-CLI and cron run on a patched binary too: wp --info |
| Next morning | The nightly backup ran |
| This week | Look for files you did not create in wp-content and new admin users |
The last row is not paranoia. The PHP security update closes the door, but it cannot tell you whether anyone came in before it closed. If something looks wrong, our step-by-step guide to cleaning a hacked WordPress site covers the order to work in.
# PHP files modified in the last 7 days, outside the usual cache folders
find wp-content -name '*.php' -mtime -7 -not -path '*/cache/*' | head -50
# Administrators, newest first
wp user list --role=administrator --fields=ID,user_login,user_registered --orderby=registered --order=DESCWhere this goes wrong
| The mistake | What happens | Do this instead |
|---|---|---|
| Updating plugins and calling it done | The server stays vulnerable | Check the PHP version itself |
Trusting php -v over SSH | CLI patched, web pool not | Read the version in Site Health |
| Assuming WHM means root | A promise to a client you cannot keep | Check for EasyApache before you commit |
| Updating packages without a restart | Old PHP keeps serving requests | Restart every FPM pool and LiteSpeed process |
Setting mitigations in .user.ini | Too late in the request to help | php.ini or the pool configuration |
| Treating mitigations as the fix | A partially protected server forgotten for months | Keep the ticket open until the version moves |
| Staying on 7.4 because “it still works” | No official package for this bug or the next one | Plan the move to a supported branch |
The first row is the one we expect to see most. A site owner reads “critical PHP vulnerability”, logs into WordPress, clicks update on every plugin, and feels finished. Nothing in that dashboard touches the PHP binary. This PHP security update is a hosting job, and the only proof it happened is a version number in Site Health.
For the full advisory text, including the technical detail behind each bug, read the official PHP security announcement and the two linked GitHub advisories. Everything in this article is taken from those sources.
Frequently asked questions
Can a WordPress plugin install the PHP security update for me?
No. Plugins run inside PHP, so they cannot replace it. Some hosting dashboards show a PHP version picker, but that switches between versions the host has installed. It cannot install a patched build the host has not provided yet.
Is WordPress itself vulnerable?
WordPress is not the bug, but it is exposed because it runs on PHP. On mod_php the confirmed attack happens before WordPress code runs at all, so a fully updated WordPress install on a server without the PHP security update is still at risk.
My host has a web application firewall. Am I covered?
A firewall may block some known attack patterns once vendors write rules for them, and that is genuinely useful while you wait. It is not a substitute for the PHP security update, and the PHP team does not list it as a mitigation.
How fast should my host apply the PHP security update?
Linux distributions and long-term support vendors received the patches before public release, so packages were ready on day one for most platforms. A good host should be able to give you a date within a day or two. Days without an answer is a warning sign.
I am on PHP 8.2. Should I move up instead of patching?
Patch first, today. Then plan the move, because 8.2 reaches end of life on 31 December 2026 and after that you will not get the next fix. Our notes on upgrading WordPress to PHP 8.5 cover what to test.
Does hiding the X-Powered-By header protect me?
It only makes you harder to find in automated scans that look for specific version numbers. It is good hygiene and worth doing, but an attacker can simply try the exploit against every PHP site.
Do I need to restart anything after the PHP security update?
Yes. PHP-FPM pools, LiteSpeed PHP processes and Apache with mod_php all keep the old code in memory until they restart. On managed hosting the host handles this; on your own server it is part of the job.
How do I know if my site was attacked before the patch?
Look for PHP files you did not upload, administrators you did not create, and unexpected redirects or outbound email. None of those prove anything on their own, but together they are where a compromise usually shows first.
