The PHP vulnerability and your WordPress site (CVE-2026-109618, CVE-2026-109619)

On 21 October 2026 the PHP project shipped an emergency release for two flaws in PHP itself. Each lets someone with no account run code on a web server. WordPress runs on PHP, so this reaches every WordPress site until its host updates PHP.

The short version: find out which PHP your site runs, compare it with the table below, and if it is older, send your host the message further down. No plugin can do this part for you. The rest of this page is the detail behind each step.

What happened

The PHP project gave advance notice on 20 October and released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October. The two flaws are CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10 on CVSS 4.0, and both allow unauthenticated remote code execution. In the advisory's words, all PHP installations serving web requests are at risk, and the risk is highest for Apache with mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

The response was unusual. CERT-EU advised that organisations "should consider isolating internet-facing applications from public networks until a fix is available." Government services in the Netherlands, Finland, France and Australia were taken offline for a while, and Pinboard, parts of Wikipedia, 4chan and Something Awful went offline to wait for the patch, according to NBC News and The National. OpenAI said it helped find the flaws and reported them to PHP.

Whether attacks are already happening depends on who you ask. CISA said it had not observed exploitation at the time of its statement. Cloudflare's CTO wrote: "We are seeing early attacks emerging and are updating mitigations as new vectors show up." Patchstack said there were reports of active exploitation. With a public fix, the safe assumption is that the details will be reverse engineered quickly.

WordPress.org published its own notice the same day. It says the flaws affect any server running PHP, not only WordPress, that no WordPress update is required or planned, and that hosts may already be updating PHP and adding web application firewall rules. Its advice to site owners is the same as this page's: check with your host and update PHP as soon as possible.

The fixed PHP for your branch

Compare your site against the fixed release for its own branch. A site on 8.2.35 is fixed. A site on 8.4.26 is not, even though the number is higher.

PHP branch	First fixed release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 and older	No fix from the PHP project

PHP 8.1 and older no longer receive updates from the PHP project. Given the severity, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux distributions and long-term support vendors ship their own fixed builds. For a site on one of those versions, the realistic answer is to ask the host to move it to a supported PHP, 8.3.36 or 8.4.27 or newer, after testing the site on it. PHP 8.2 itself stops receiving security fixes on 31 December 2026. Before a jump of several versions, check that your WordPress version supports the PHP you are moving to in the PHP compatibility table.

If you run your own server on an older PHP and cannot upgrade right away, WordPress.org points to the advice of several national cyber security agencies: consider taking the server offline while you upgrade. The UK National Cyber Security Centre puts it as "organisations should consider taking the system offline until it can be fully mitigated."

Check your site in two minutes

1. In WordPress, open Tools, then Site Health, then the Info tab.
2. Expand Server. The PHP version is listed there, along with the server software.
3. Compare the version with the table above.

If the version has extra text after the number, such as 8.1.2-1ubuntu2.14 or 8.2.29-1~deb12u1, it is a Linux distribution build. Distributions received the patches in advance and ship them under their own version numbers, so the number alone cannot tell you whether the fix is in. Ask your host.

It also helps to know how PHP runs on your server. Under Apache mod_php the demonstrated exploit needs nothing from WordPress at all. Under PHP-FPM, which many managed WordPress hosts use, the advisory describes the server as susceptible, though no complete FPM exploit has been demonstrated. If you are not sure which one your site uses, ask your host in the same message.

Many managed WordPress hosts update PHP for every site themselves. Check your host's status page or announcements before assuming either way.

The message to send your host

Replace the version in brackets with the one Site Health shows:

Hello,

On 21 October 2026 the PHP project released a security update for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which allow remote code execution with no login. My site currently reports PHP [your version]. Please update it to the fixed release for its branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35) or newer.

If the server uses a distribution or long-term support build of PHP, please confirm that build includes these fixes. If the update cannot happen today, please let me know which of the interim settings in the advisory are in place.

Advisory: https://www.php.net/archive/2026.php#2026-10-21-5

Could you confirm once it is done? Thank you.

If your host cannot update today

php.net lists settings that reduce exposure to the known attack paths. In its words, they "do not make an installation safe." They are all server settings, so they are for whoever runs the server:

• An unlimited memory limit, memory_limit=-1, set where applications cannot override it, such as php_admin_value in the PHP-FPM pool or Apache configuration. WordPress core never lowers an unlimited limit, but any plugin can call ini_set, and php_admin_value is the form it cannot change. Use a container or cgroup limit as the safety net instead, never RLIMIT_AS or RLIMIT_DATA, which trigger the very failure the first bug needs.
• A low post_max_size: 8M for sites without uploads, 32M with them, with upload_max_filesize below it. On WordPress this caps the size of media uploads, so pick it with that in mind.
• session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, then a restart of every PHP worker. php.net says not to rely on ini_set() or .user.ini for this.
• On PHP 8.5, fatal_error_backtraces=0, then a restart of every worker.

None of these can be set from inside WordPress, and a setting changed from WordPress is not a mitigation. Updating PHP is the only complete fix.

The two bugs, in more detail

CVE-2026-109618, remote code execution through out-of-memory corruption. When PHP runs out of memory it jumps out of whatever it was doing. In a few places, memory for the request is reachable before it is fully set up, and a jump at that moment leaves it half initialised. The cleanup at the end of the request then trusts it. Attackers can reach the memory limit on purpose with crafted multipart form requests: a body without a usable length, a part with a huge number of headers, or many empty file fields with nested names. Apache mod_php runs the cleanup even when request startup failed, which is why the attack works there before any application code runs. PHP-FPM exits the worker in that case instead, which removes that path but not every path.

CVE-2026-109619, remote code execution through stale global state. A PHP worker handles many requests one after another. Some internal state from one request can survive after the memory behind it is freed, for example when a fatal error interrupts an operation before it resets that state. If the next request on the same worker touches that state before PHP initialises it again, it uses freed memory, and a carefully shaped request turns that into code execution. The confirmed triggers include a warning raised while PHP applies settings early in a request: under mod_php, that includes php_value lines in .htaccess; under FPM, settings a web server passes in with PHP_VALUE. Hiding warnings with display_errors or @ does not help, because the damage happens before PHP decides whether to show anything.

The full technical write-ups are the two GitHub advisories linked under Sources.

What to check after the update

Updating PHP closes the door and undoes nothing that happened before it. Code that ran on the server ran as the web server's user, which can usually write to wp-content. So the useful checks are the traces a break-in leaves:

• PHP files where none belong: the uploads folder, cache folders and mu-plugins.
• Changed WordPress core files, compared against the official checksums.
• Administrators created or promoted since 20 October. Confirm each one with whoever runs the site, and never decide from a name or a date that an account is fine, or that it is not.
• Application Passwords nobody recognises. A PHP update does not revoke them.
• Plugins hidden from the plugin list, and rewrite rules that answer for your pages.

If something turns up, restoring from a backup taken before 20 October beats cleaning by hand, and the passwords and keys stored on the site should be changed afterwards. WordPress.org keeps a checklist for exactly this: FAQ: My site was hacked.

What Respira can and cannot do

Respira cannot update your PHP. No WordPress plugin can: PHP is part of the server, and the request is parsed before WordPress starts. I would rather say that plainly than sell a plugin as a fix.

What Respira does today:

• The free WordPress vulnerability scanner checks a site's plugins, themes and core against known vulnerabilities from the outside, with no account.
• With Respira connected, the security audit runs from inside the site and looks for the traces listed above: core files against the official checksums, PHP files in uploads, cache and mu-plugins, administrators and Application Passwords, plugins that hide from the plugin list, and rewrite rules that take over pages. Findings come back as evidence to confirm, never as an automatic verdict.

Since Respira 9.2.18, released the same evening, that audit also reads PHP itself: the exact version, whether it carries the 21 October fix, how PHP runs on the server, and the interim settings. A version below its fix is flagged as critical, and the dashboard fills in this host message for each site. For one site, Site Health gives you the version. For twenty client sites, that is the part that tends not to get done.

Scan a WordPress site for free

Questions

Is WordPress itself vulnerable?

No. The flaws are in PHP, the language WordPress runs on, not in WordPress code. Every WordPress site runs on PHP, so every WordPress site is exposed until the server it runs on has the fixed PHP. Updating WordPress, a theme or a plugin does not change that, and WordPress.org says no WordPress update is required or planned.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Compare your site against the fixed release for its own branch. PHP 8.1 and older get no fix from the PHP project; some Linux distributions and long-term support vendors ship their own backported builds.

How do I check which PHP version my WordPress site runs?

In WordPress, open Tools, then Site Health, then the Info tab, and expand Server. The PHP version is listed there. Your hosting control panel usually shows it too. A version with extra text after the number, such as 8.1.2-1ubuntu2.14, is a distribution build: ask your host whether it carries the fix.

Can a WordPress security plugin protect me?

Not from this. PHP reads and parses the incoming request before WordPress or any plugin loads, and under Apache mod_php the demonstrated exploit fires before any application code runs. Only updating PHP fixes it, and that is your host's job, or yours if you run the server.

My host updated PHP. Am I clear?

The hole is closed. Whether anyone came through before the update is a separate question the version number cannot answer. Check for PHP files in the uploads folder, administrators and Application Passwords nobody recognises, and changed WordPress core files.

What if my host cannot update today?

php.net lists interim settings that reduce exposure without making a server safe: an unlimited memory_limit enforced by the server, a low post_max_size, and session.upload_progress.enabled set to 0 in php.ini or the PHP-FPM pool, followed by a restart of every PHP worker. These are server settings. They cannot be set from WordPress.

Sources

• php.net: Security advisory, critical remote code execution vulnerabilities, 21 October 2026
• GHSA-w8hw-w9fx-j79w: CVE-2026-109618, RCE via OOM corruption
• GHSA-6wmf-4rv5-p3rp: CVE-2026-109619, RCE via stale global state
• PHP 8 changelog
• WordPress.org: Critical PHP security release
• UK NCSC: Critical security issue affecting PHP
• WordPress.org: Update PHP
• NBC News: Critical vulnerabilities in PHP spark rush to update systems
• The National: Websites go offline amid critical security update

Checked on 21 October 2026. If a version here stops matching the php.net advisory, the advisory is right and this page is stale.