Critical PHP security update: what it means for Joomla site owners
21 October 2026
If your Joomla site runs on PHP 8.2 or newer, your host needs to update PHP today. On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities that can let an attacker run their own code on your server without logging in.
This isn't a Joomla bug, and there's no Joomla update to install. The flaws sit in PHP itself, underneath Joomla, every extension and every template. That means a fully patched Joomla 6 site is just as exposed as an old one until the PHP underneath it is updated.
The PHP team's own advice is blunt: there is no complete workaround, and updating is the only safe option. Check your PHP version today and make sure your host has patched it.
What's been fixed
Both vulnerabilities are rated 9.2 out of 10 on the CVSS v4.0 scale, and both can lead to unauthenticated remote code execution (RCE). In plain terms, an attacker could take control of the server process running your site without needing a Joomla login.
Memory corruption on out-of-memory errors
When PHP runs out of memory part-way through setting up a request, it can be left holding half-built internal data. The clean-up code may then treat that broken data as valid, which an attacker can exploit.
Stale data between requests
Some internal state belonging to one request can outlive the memory behind it. The next request handled by the same PHP worker may pick up that leftover state before PHP resets it.
The PHP team says every installation that serves web requests is at risk. That covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, so between them, almost every Joomla host.
The highest risk is Apache with mod_php. There, a working exploit has been shown that triggers the attack before any application code runs. Joomla's own security features, admin protection and firewall extensions never get a chance to step in.
The PHP team gave a day's notice on 20 October and said it might release early if exploitation appeared in the wild. With the technical advisories now public, expect attackers to start probing for unpatched servers quickly.
Which PHP version you need
You don't need to change PHP branch to be safe. Stay on the branch you're on and move to its patched release.
| PHP branch | Patched release | Who's typically on it |
|---|---|---|
| PHP 8.5 | 8.5.12 | Newer hosting, early adopters |
| PHP 8.4 | 8.4.27 | Recommended for Joomla 6 |
| PHP 8.3 | 8.3.36 | Minimum for Joomla 6, recommended for Joomla 5 |
| PHP 8.2 | 8.2.35 | Joomla 5 sites (end of life 31 December 2026) |
| PHP 8.1 and older | No fix | Older Joomla 5, Joomla 4 and Joomla 3 sites |
For reference, Joomla 6 needs at least PHP 8.3 and recommends 8.4. Joomla 5 needs at least PHP 8.1 and recommends 8.3.
If your site is on Joomla 5 with PHP 8.1, this is the moment to move up. Joomla 5 runs on 8.2, 8.3 and 8.4, all of which have patched releases. Test on a staging copy first if you rely on older third-party extensions.
Linux distributions such as Ubuntu, Debian and Red Hat often apply security patches to their own PHP packages without changing the main version number. Your host may be fully patched while still showing something like 8.3.6. If the number looks low, ask your host directly whether CVE-2026-109618 and CVE-2026-109619 are fixed.
What to do now
Start by finding out exactly which PHP version your site runs. In the Joomla administrator, go to System → System Information. The PHP version is listed on the first tab.
What happens next depends on how your site is hosted.
Shared hosting
- Check your host's status page or email for an announcement about the PHP security release.
- Look in your control panel's PHP selector. Some hosts let you pick a specific point release; most update the branch for you.
- If there's no announcement by the end of the day, open a support ticket. Ask whether CVE-2026-109618 and CVE-2026-109619 are patched on your server, and when.
Managed hosting
- Your host should handle this for you, and many will already have done so. Distributions and long-term support vendors were given the patches ahead of the public release.
- Confirm it anyway. A one-line support ticket costs nothing.
Your own VPS or dedicated server
- Update PHP through your package manager, or rebuild from source if you compile your own.
- Restart every PHP-FPM pool, or Apache if you use mod_php, so no worker is left running the old code.
- If you're on mod_php, treat this as urgent. It's the setup with a demonstrated pre-application exploit.
- If you install PHP from the volunteer-run Remi repository (rpms.remirepo.net), note it won't have updates today. The PHP team recommends switching to your distribution's packages or building from source so you can patch immediately.
After any update, recheck System Information in Joomla to confirm the new version, then click through the front end and admin to make sure nothing has broken.
If you can't update today
The PHP team has published some stopgap measures, but it's clear that none of them make a server safe. They narrow specific attack paths while you arrange the real fix. Most of them need server-level access, so on shared hosting they're your host's job, not yours.
For anyone managing their own server, the main ones are:
- ●Turn off session upload progress. Set
session.upload_progress.enabled=0in php.ini or the FPM pool config, then restart every worker. Setting it withini_set()or a.user.inifile does not work, because it must apply before the request is parsed. - ●On PHP 8.5, turn off fatal error backtraces. Set
fatal_error_backtraces=0and restart workers. - ●Lower your POST size limit. The advisory suggests
post_max_size = 32Mwhere uploads are needed, or8Mwhere they aren't, withupload_max_filesizebelow it. Joomla sites that take large media uploads will need to weigh this. - ●Remove the PHP memory limit at server level. The advisory suggests
memory_limit=-1, set so the site can't override it, with a container or cgroup limit as the real ceiling. This changes how runaway scripts behave, so only do it if you understand the trade-off. - ●Tidy up PHP warnings. Invalid or deprecated per-request settings that throw diagnostics early can open the second flaw. Hiding errors doesn't help; fixing the setting does.
The full advisory has the complete list and the reasoning. Treat all of this as a few hours' cover, not a solution.
Older PHP, and the PHP 8.2 deadline
If your site runs PHP 8.1 or older, the PHP project won't release a fix. Some Linux distributions and paid long-term support vendors backport security patches, so ask your host whether that applies to you. Given how serious these flaws are, the PHP security team has also published minimal source patches for PHP 7.4, 8.0 and 8.1, but those are only useful to people who compile PHP themselves.
For most site owners, the honest answer is that it's time to upgrade. Sites still on PHP 7.x or 8.0 are usually also on Joomla 3 or Joomla 4, both of which are past end of life. That combination is now carrying a known, critical, unpatched hole.
PHP 8.2 is patched today, but after the end of the year it gets no more security fixes. If you're on 8.2, apply 8.2.35 now and plan your move to 8.3 or 8.4 before the new year. For Joomla 5 sites, PHP 8.3 is the recommended choice, and it also clears the way to Joomla 6 when you're ready.
Quick checklist
- ✓Check your PHP version under System → System Information
- ✓Confirm with your host that PHP is on 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or that the two CVEs are patched
- ✓If you run your own server, update PHP and restart every worker
- ✓If you're on PHP 8.1 or older, plan an upgrade now
- ✓If you're on PHP 8.2, plan a move to 8.3 or 8.4 before 31 December 2026
- ✓Look after more than one site? Check every one, including staging and forgotten old installs
Updates like this are easy to put off because nothing looks broken. But the vulnerability is in PHP, not in anything you control from the Joomla admin. A ten-minute check with your host today is the best protection your site will get this year.
Sources
- PHP security advisory: critical remote code execution vulnerabilities
- GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- Joomla technical requirements
Our SE AI Extension Cleaner finds unused extensions, orphaned tables and broken files first, so there's less to go wrong. It's one of our Joomla 5 and 6 extensions, all backed by fast support and a 7-day money-back guarantee.
