PHP2Shell and Joomla: What Site Owners Need to Do

As of 23 October 2026, the PHP project has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The Joomla project has not published a PHP2Shell statement in its security centre or announcements. Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a flaw in PHP, the language and runtime that Joomla runs on. It is not a Joomla bug, so no Joomla update fixes it. A Joomla site is exposed if the PHP build serving it is unpatched, whatever Joomla version it runs. The fix is a patched PHP build on the server and a restart of every PHP worker.

This guide covers what researchers showed against Joomla, which PHP versions each Joomla series supports, why Joomla 3 and Joomla 4 sites need extra care, and the steps to take today. For the overview, read what PHP2Shell is and who it affects.

Is Joomla Vulnerable to PHP2Shell?

Joomla is exposed through PHP, not through its own code. PHP's description of CVE-2026-109618 is that "out-of-memory handling can interrupt PHP while internal request data is only partially initialized." CVE-2026-109619 is described as "request-owned internal state can survive after its backing memory has been freed," so that "a later request handled by the same worker may use that stale state." Both happen inside PHP's request handling. Joomla core, templates and extensions are not where the bug lives.

That is why there is nothing to download from joomla.org for this. As of 23 October 2026, the Joomla security centre lists no PHP2Shell item. Its newest entries are Joomla core issues fixed on 25 September 2026 in Joomla 6.1.4 and 5.4.9. Those are separate issues and worth installing on their own merits. Don't read the lack of a Joomla statement as "Joomla is safe." The PHP project's own advisory on php.net is the authority here.

What Researchers Showed Against Joomla

• Wiz reported that it could "execute code remotely without authentication on deployments of WordPress (wordpress:latest), Drupal (drupal:latest), and Joomla (joomla:latest), using their latest container images at the time of testing." Per Wiz's write-up, Joomla was hit through the upload-progress chain, which worked against all three CMSs.
• Calif, which reported the first bug to PHP, lists Joomla 6.1.4 among the applications it confirmed.

"Without authentication" means the attacker needs no Joomla account. "Remote code execution" means running commands on the server with the web server account's permissions. Wiz adds that these CMSs "are representative targets - exploitation does not require one of these CMSs." In other words, Joomla wasn't singled out. It was a convenient, realistic test.

The upload-progress path matters for Joomla owners because PHP's advisory says "Session upload progress is enabled by default, and no application call to session_start() is required." A default Joomla install on default PHP settings is enough. For the details of the first CVE, see CVE-2026-109618 explained.

Joomla PHP Requirements by Version

Joomla publishes its requirements in the Joomla developer manual. Here is what each series allows, as of 23 October 2026, next to what that means for PHP2Shell.

The PHP project's fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP says "PHP 8.1 and older no longer receive updates from the PHP project." It did publish minimal source-only backports for 7.4, 8.0 and 8.1, but those help only people who compile PHP themselves. Most site owners need a patched build from their host or Linux distribution instead. The full list, including distribution packages, is in PHP2Shell fixed versions.

If you are on PHP 8.2, update to 8.2.35 now and plan the next move: PHP 8.2's security support ends on 31 December 2026. Joomla 6 doesn't run on 8.2 anyway, so moving to PHP 8.3 or 8.4 also clears the way to Joomla 6.

Joomla 3 and Joomla 4 Sites on Old PHP

Joomla 3 lost official support from the Joomla volunteer community on 17 August 2023, according to the Joomla project's announcement. Many Joomla 3 sites still run, often on PHP versions that the PHP project stopped supporting years ago. Joomla 4 allows PHP as old as 7.2.5, so a Joomla 4 site can also sit on an end-of-life PHP branch while meeting Joomla's minimum.

For these sites, the order of work is:

1. Find out exactly which PHP build serves the site. See the next section.
2. Ask your host whether that build is vendor-patched. Some vendors have shipped fixes for old branches. For example, cPanel says its EasyApache 4 release fixes ea-php74 through ea-php85, Plesk's support article lists fixed builds for PHP 7.4 to 8.1, and Ubuntu lists fixed packages for PHP 7.4 on 20.04 and PHP 8.1 on 22.04 LTS.
3. If no patched build exists, move the site to supported PHP. On Joomla 3 that usually means upgrading Joomla first, which is a migration project rather than a quick update.
4. If you can't do either soon, take the site offline. CISA says organizations that "continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." Use a maintenance page or network restriction, not a disabled PHP handler: Beazley warns that disabling the handler "can expose application source code and credentials."

Our Joomla security guide covers the wider risks of running an unsupported Joomla series.

How to Check Your PHP Version in Joomla

1. Log in to the Joomla administrator.
2. Open the System dashboard, and in the Information panel choose System Information.
3. Read the PHP Version line. The PHP Information tab shows the full PHP configuration.

Two cautions. First, Linux distributions backport fixes without changing the version string. AlmaLinux says "Don't rely on php -v: our fixes are backported, so the upstream PHP version number doesn't change," and Ubuntu's fixed package for 24.04 LTS still reports PHP 8.3.6. A number below the upstream fix doesn't prove you're vulnerable, and a number at or above it doesn't prove the workers were restarted. Second, the PHP on the command line can be a different build from the one serving your pages. Our guide on how to check your PHP version explains how to confirm with your host.

Who Patches PHP for Your Joomla Site

If you manage the server, these are generic examples for Debian or Ubuntu with PHP-FPM; replace 8.3 with your version:

sudo apt update
sudo apt upgrade
sudo systemctl restart php8.3-fpm

On RHEL-family systems, sudo dnf upgrade installs the fixed packages. If Apache runs PHP as mod_php, restart Apache (for example sudo systemctl restart apache2 on Debian or Ubuntu). PHP's advisory and every major vendor say the same thing: restart every PHP worker, or the old code keeps running.

Interim Settings While You Wait for a Patch

PHP's advisory lists settings that reduce exposure if you can't update today. PHP says plainly that "only an update is a complete solution" and that these measures "do not make an installation safe."

• session.upload_progress.enabled=0, set in php.ini, the FPM pool or server configuration, then restart every worker. Don't rely on ini_set() or .user.ini for this. PHP recommends keeping it off until the next regular PHP release even after patching, because a separate, unlikely issue (CVE-2026-115560) also affects patched builds.
• A lower post_max_size: PHP suggests 8M if the site doesn't take uploads and 32M if it does. Test media uploads, extension installs and backup restores in the Joomla administrator afterward, since those can need larger requests.

A web application firewall in front of the site can also filter known attack requests. Cloudflare says its free and paid WAF customers have been protected by default since 21 October 2026, 03:02 UTC, but rules are partial and don't replace patching. Every setting and its side effects are in PHP2Shell interim mitigations.

Why Joomla Extensions and Updates Can't Fix It

Keeping Joomla and its extensions current is still important. Our guide to security patching and update best practices covers how to do it safely. But Cloudflare's advice on PHP2Shell is clear: "updating website code or a plugin(s) alone does not fix these vulnerabilities." Bitdefender adds that "on mod_php, CMS updates, plugin hygiene and application hardening do not change exposure."

Security extensions are PHP code and run inside PHP. They can't patch the PHP engine. For CVE-2026-109618 on mod_php, PHP's advisory says the problem "happens entirely before any application-specific code begins execution," so no Joomla extension gets to run first.

After patching, check for signs that someone got in before you did, starting no later than 17 October 2026. Our guide on checking whether your site was hacked through PHP2Shell lists what to look for.

Conclusion

As of 23 October 2026, PHP2Shell reaches Joomla sites only through the PHP they run on, and the Joomla project has issued no statement because there is nothing for Joomla to patch. Confirm your PHP build is patched and restarted, move any site on PHP 8.1 or older to a supported branch, and treat Joomla 3 and older Joomla 4 sites as urgent. If you need a server patched quickly, see our emergency PHP patching service. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions