PHP's Critical Security Release and Your Joomla or WordPress Site

On 20 October 2026 the PHP security team posted advance notice of a critical security release, with the details, the affected versions and the fixed versions held back. On 21 October, a little before the announced 14:00 UTC, the release went out: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two vulnerabilities rated CVSS v4.0 9.2 that PHP describes as able to “allow unauthenticated remote code execution”.

For anyone running Joomla or WordPress, there is a catch. On almost every hosting account the owner does not apply PHP updates, the host does, and the host only does it for PHP branches that still receive fixes. So beyond “patch now”, the useful question is whether your site is on a PHP branch that has this fix at all, and whether your host has actually applied it.

TL;DR

• PHP published 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026, fixing CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2, and PHP has confirmed both as unauthenticated remote code execution.
• CVE-2026-109618 is memory corruption triggered by pushing a request out of memory, mainly through multipart upload parsing. CVE-2026-109619 is stale request state left behind on a worker and reused by a later request.
• Every PHP setup that serves web requests is in scope. The risk is highest for Apache with mod_php, where an unauthenticated request can trigger the attack before any application code runs.
• PHP 8.1 and older get no official release. The PHP project published source-only backports for 7.4, 8.0 and 8.1, with no binaries, and some distributions and LTS vendors backport the fix into their own packages.
• You usually cannot apply it yourself. PHP is installed and updated by your host, and your control panel only offers what the host has installed.
• Across the live sites we monitor, 22.7% run PHP 8.1 or older. For those, no patched build is coming from PHP.
• Check which version every site you look after reports, chase the host where the fixed release is not on yet, and plan the version upgrade where there is no fixed release to wait for.

What the Two Flaws Are, in Plain English

PHP’s advisory puts both vulnerabilities at CVSS v4.0 9.2 and says they “can allow unauthenticated remote code execution”. Its risk assessment covers “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed”, and considers the risk highest for mod_php, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs”. For a Joomla or WordPress site, that last clause means nothing the CMS does is in the way.

CVE-2026-109618 is described as RCE via out-of-memory corruption. When PHP runs out of memory part way through setting up a request, its internal request data can be left only partially initialised, and the cleanup that follows may then treat invalid data as valid. The advisory says several multipart parsing behaviours can push a request into out-of-memory while staying within PHP’s apparent limits: requests with no usable Content-Length slipping past post_max_size, no cap on headers per multipart part, empty file fields not counting toward max_file_uploads, and nested field names. The result can be code execution as the web worker account. It is validated over HTTP against mod_php with default limits, and the advisory lists FrankenPHP as susceptible too. PHP-FPM is considered susceptible from source analysis, with no complete FPM exploit demonstrated.

CVE-2026-109619 is described as RCE via stale global state. State belonging to one request is still referenced after its memory is freed, and a later request on the same worker uses it before normal initialisation has happened, a use-after-free. Exploiting it takes a “producer” request that leaves the state behind and a “consumer” in a later request on the same worker. The advisory confirms two consumers: INI diagnostics applied before request initialisation (a deprecated or invalid php_value in a .htaccess file under mod_php, for example), and session upload progress handling. The session upload progress route to code execution is validated against both mod_php and PHP-FPM. The strongest case is fatal_error_backtraces on PHP 8.5 under mod_php, which produces the kind of stale state the bug needs, and it was on by default on the PHP 8.5 installs we checked.

One correction to the chatter from the days before the release: session upload progress is one confirmed path into CVE-2026-109619, not the whole bug, and it has nothing to do with CVE-2026-109618. The two flaws are separate, which is why PHP’s own wording is that “there are no complete mitigations, updating is the only safe choice”.

The patched builds went out as point releases on 8.2.x, 8.3.x, 8.4.x and 8.5.x. PHP 8.6 is still in release-candidate testing, no 8.6 line has the fix, and there is no 8.6.0RC4, so anyone running an 8.6 release candidate is unpatched.

The Internet Was on Fire (Well, Social Media Was)

Between the notice and the release, the loudest thing about this one was everyone except PHP. The security team had reserved the right to release early if details became public or if exploitation was seen in the wild, both were claimed within hours, and the release still went out on the day PHP named, about 25 minutes ahead of 14:00 UTC rather than a day early.

A taste of what did the rounds. Kevin Beaumont noted that someone leaked the two CVE IDs before the patch was out. Sansec reported a screenshot of an exploit tool called “PHP2Shell”, with a banner claiming it works against every PHP release since 5.4.0, and predicted mass attacks within fifteen minutes of the release. A write-up claiming to describe the bug circulated with a proof of concept that may have been broken. Huntress, writing on 20 October, had seen no in-the-wild exploitation and knew of no public exploit code. CERT-EU’s advisory had the sober version: no technical details public, and the “all PHP versions from 5 onwards” line came from leaks.

Then Cloudflare’s CTO posted at 07:43 UTC on 21 October that they were “seeing early attacks emerging”, while calling their WAF rules “a STOPGAP only” and telling everyone to patch at 14:00. Whether anyone was really being exploited is still disputed as we publish: Hadrian claims exploitation “at scale”, Germany’s BSI says no attack has been confirmed, and none of them has published evidence. Mattias Geniar’s round-up keeps the confirmed and the unconfirmed apart. Now that the advisories are public, the leak’s upload-progress claim turns out to have been partly right: session upload progress is a confirmed path into one of the two bugs, not the mechanism of both.

On those Cloudflare rules, which went out on every plan including Free: a WAF in front of a site only helps if the server behind it rejects traffic that bypasses Cloudflare. A server that answers requests sent straight to its IP address is reachable without the WAF, and the rules are a stopgap by Cloudflare’s own description, not a substitute for the update.

Our view, and we cannot prove it, is that what has changed is how little time an attacker now needs. A pre-announcement like this used to buy defenders a comfortable head start, because turning “two critical bugs, details withheld” into a working exploit meant a skilled human reading code for days. Now an attacker can have a script ready, point a model at the pre-announcement post and the leaked chatter, then at the patch diff the moment it is published, and have a candidate flaw in minutes, maybe seconds. The gap between a fix going public and an exploit going public used to be measured in weeks. We no longer assume there is a gap at all.

A PHP Flaw Sits Under Every Joomla and WordPress Site

PHP is the engine every Joomla and WordPress page runs through. Every request a site serves, from a logged-out visitor loading the home page to an administrator saving an article, is executed by the PHP interpreter on the server. A flaw in the interpreter therefore sits underneath all of the normal traffic a site already handles, below the CMS, its plugins and extensions, and any security layer that lives in application code.

The release confirmed the worst reading of that. Under mod_php, PHP has a demonstrated exploit where an unauthenticated request triggers the attack before any application code runs, which means no WordPress security plugin, no Joomla access rule and no login screen is involved. CVE-2026-109618 is validated over HTTP against mod_php with default limits, and the session upload progress route into CVE-2026-109619 is validated against both mod_php and PHP-FPM. A pair of 9.2 vulnerabilities in the layer under every site you run, reachable without an account, is the case for treating the host’s update as urgent rather than routine. The Joomla project took the same view of its own servers and took joomla.org offline on 21 October, downloads and update services included; what the joomla.org outage means for your Joomla sites has its own post.

Which PHP Versions Got the Fix?

PHP 8.2, 8.3, 8.4 and 8.5 all received a fixed point release. PHP 8.1 and anything older did not get an official release. Critical security fixes go to both the actively supported branches and the security-only branches, which is why 8.2 and 8.3 are included even though their active support has ended. The supported versions timetable on php.net shows the exact dates for each branch, and the end-of-life page lists every branch that has fallen off it.

PHP 8.2 users should notice how close to the edge they are. Its security window closes on 31 December 2026, so it got this fix but may not get the next one, and a site on 8.2 should already have a move to 8.3 or newer in the plan. How to prepare for the next PHP security release covers that planning.

PHP Is Not Out of the Woods Yet After PHP2ShellA researcher claims six more unpatched PHP flaws after PHP2Shell. Unconfirmed, and nothing to do today, but PHP is not out of the woods. What to prepare now.Read the full post

The end-of-life rows need explaining, because “source-only backport branch” is a new thing. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1, on branches named PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 and PHP-8.1-CVE-2026-109618-109619, described as a “minimal mitigation for EOL version”. They exist to help people who build PHP from source or have no LTS vendor. There are no tagged releases and no binaries, so nothing a shared host’s control panel can offer, and PHP’s advice for 8.1 and older is unchanged: “some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version”. Linux distributions and LTS vendors received the patches in advance, so a distribution package may well include the fix, but that is the vendor’s work and the vendor’s timetable. For a site on an end-of-life branch, the plan should still be the move to a supported one.

Being on the right branch is only half of it; the other half is the patch level within that branch, and a site on 8.4 that the host has not updated for a year can be further behind than a site on 8.3 that was patched last week. The full explanation of branches versus patch levels, and why the higher PHP number can be the more out-of-date one, is in its own post.

Why PHP 8.5.7 Shows Amber When PHP 8.4.24 Shows GreenPHP 8.5.7 shows amber while 8.4.24 shows green because the badge checks whether you are on the newest patch in your branch, not which branch you picked.Read the full post

What Our Monitoring Shows About PHP Right Now

The figures below come from live Joomla and WordPress sites under active management, measured on 20 October 2026: agencies run their clients’ production sites through mySites.guru, so this is what real hosting looks like today, not a public survey of people who chose to answer.

77.3% of the sites we monitor are on a branch between 8.2 and 8.5, so they get this fix once their host applies the patched release. Those owners have one job, which is to make sure the host does it.

The other 22.7% are on PHP 8.1 or older, which is end of life and gets no official release no matter what the host does. Within that group, 16.6% of all sites are still on PHP 7 or older, running an interpreter that upstream stopped fixing years ago. The split by CMS is not even.

Release day itself showed how a fix spreads. The first sites we monitor reported a fixed version string at 12:44 UTC on 21 October, about fifty minutes before the advisories went public, because packagers and hosts who were notified in advance released their builds first. By 13:52 UTC, with the advisories out, 0.08% of live sites under active management reported a fixed release. The rest were waiting on their host.

Why Do So Many WordPress Sites Run End-of-Life PHP?

Because WordPress lets them. The official WordPress requirements recommend PHP 8.3 or greater, but the current WordPress line still marks PHP 7.4 as compatible, and 7.4 has been end of life since November 2022. Recent WordPress versions kept compatibility all the way back to PHP 7.2, which reached end of life in November 2020. The Core PHP compatibility matrix shows this release by release.

WordPress does this on purpose, so that an update never fails because of the PHP underneath it. The side effect is that nothing ever forces a WordPress site off an abandoned interpreter: the CMS keeps updating, the plugins keep updating, and PHP stays wherever the host left it years ago.

Joomla takes a firmer line. Joomla 5 requires PHP 8.1 as a minimum and recommends 8.3, and Joomla 6 requires PHP 8.3 and recommends 8.4, with the full list in the Joomla technical requirements. For comparison, see the WordPress 7 requirements. A firmer floor pulls sites forward when they upgrade, but it cuts the other way too: an old Joomla site that cannot move to a newer major version is pinned to whatever PHP its version supports, which is part of why the Joomla figure above is the higher one.

Does Your Host Actually Apply PHP Patches?

A PHP security release of this kind is a patch release inside a branch, for example 8.3.35 to 8.3.36. It is binary-compatible and a drop-in replacement, so a host can roll it out across its servers with nothing changing for the site owner, and well-run hosts apply these within days of publication. The release that can break things is the major or minor jump, say 8.1 to 8.3, because that can affect themes, plugins and extensions and needs the owner to test first. Do not confuse the two: a host telling you “PHP updates can break sites” as a reason not to apply a point release is describing the wrong kind of update.

The PHP selector in your hosting control panel only lists the versions the host has installed on that server, and so does the Switch button on a site’s cPanel pane in mySites.guru. If the patched release is not offered there, there is nothing you can set, and the useful move is a support ticket asking when it is coming. Check the version the site reports while serving a request rather than trusting php -v on the command line, because the CLI binary and the one serving your pages are often different builds; the amber and green post linked above explains why.

It helps to know where your host’s PHP comes from, because that decides how soon the fix can reach you. On release day the picture looked like this:

• cPanel EasyApache 4 had fixed ea-php82, ea-php83, ea-php84 and ea-php85 packages (8.2.35, 8.3.36, 8.4.27 and 8.5.12) available by about 13:45 UTC, within minutes of the advisories. ea-php81 has no fix, because 8.1 has no release to package.
• Ondřej Surý’s PPA (ppa:ondrej/php) had no fixed packages at 13:47 UTC. It will get the fix, with no ETA given, and it now builds only for Ubuntu 22.04 and 24.04. The PPA’s Release “Label” was also renamed, so apt will not refresh its package lists until you run apt-get update --allow-releaseinfo-change-label, and a server in that state sits on stale lists with no warning and never sees the fixed packages when they do arrive.
• Remi’s repository had no updates on release day, and php.net’s advice was to switch to distribution packages or build from source in the meantime.
• CloudLinux was preparing fixed alt-php packages after the release. Its Imunify360 ModSecurity ruleset 8.83 blocks the public exploit, which is a WAF rule, not a PHP fix. On cPanel, the widely shared ModSecurity mitigation for the upload-progress field also turns on request body inspection server-wide, which blocked WordPress and Joomla editor saves on our servers.
• Distribution packages on Ubuntu, Debian and Red Hat backport security fixes without changing the upstream version number, so Ubuntu 24.04 stays on an 8.3.6-0ubuntu... package even once it is patched. A version-number check cannot see that fix. Read the package changelog or the distribution’s advisory instead of trusting x.y.z.

What You Can Actually Do About It

1. Find the PHP version each site reports, and whether it is a fixed one. mySites.guru records the version the site reports while serving a request, and for this release the PHP version check goes red when a site is at or below the last vulnerable patch: 8.2.34, 8.3.35, 8.4.26 or 8.5.11. Sites on 8.1 and older are flagged end of life, with 8.3 as the suggested target. There is a banner for the release on the dashboard, and the version is also available through the API and MCP, so you can pull the list into whatever you already use. Package suffixes such as -nmm1 are stripped before comparison. A distribution package that backports the fix without changing the version string is still flagged as unpatched until you confirm it with the host and record the back-port for that build.
2. Supported branch, 8.2 to 8.5: ask the host when they will apply 8.2.35, 8.3.36, 8.4.27 or 8.5.12, and select it in the control panel as soon as it appears there.
3. End of life, 8.1 or older: no official release exists, so plan the version upgrade now. Check first whether the CMS or an extension pins the PHP version, because that upgrade moves before PHP can. A Joomla 3 site is the classic case, and what to do with Joomla 3 sites still on an agency retainer covers that conversation with the client.
4. Across many sites, do it from one list. Whether you manage multiple Joomla sites or manage multiple WordPress sites, the PHP version is one column across all of them, and the CMS-side moves can be run as a mass upgrade from one dashboard.

The affected and fixed versions are now public, so the question has narrowed to which of your sites are still on a vulnerable one and which hosts have not moved yet. Seeing every site’s PHP version in one place is what turns that into a short job rather than an afternoon of logging into control panels, and a free audit shows you that list in a few minutes.