Featured Security

PHP2Shell: Is Your Joomla Site Safe? What to Do Today

Oct 21, 2026 · · 9 min read

Short version: two critical security holes were found in PHP, the language Joomla runs on. They are nicknamed PHP2Shell. Joomla itself is not broken, but every Joomla site running on an unpatched PHP version is at risk. The fix is to update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or newer). Do it today.

What happened?

On 21 October 2026 the PHP team released emergency updates for two flaws, CVE-2026-109618 and CVE-2026-109619, both rated critical (9.2 out of 10). Details leaked online a day before the planned announcement, so attackers learned about the problem at the same time as everyone else. Security companies such as watchTowr and Cloudflare report that the first attack attempts have already started.

Think of your Joomla site as a house. Joomla's login, permissions and security extensions are the front door. PHP2Shell lets an attacker get in through the foundations, before the front door is even reached. The attacker doesn't need a username, a password or a vulnerable extension. A specially crafted request to any page can be enough to run their own code on your server. The researchers at Wiz demonstrated exactly this against a default Joomla installation, as well as WordPress and Drupal.

That is why updating Joomla or your extensions does not fix this. Only an updated PHP does.

Is my Joomla site affected?

If your site runs on a PHP version older than the ones below, yes. Almost every PHP version from the last ten years is affected.

Check your PHP version in 30 seconds

Log in to your Joomla administrator.
Go to System → System Information.
On the System Information tab, look at PHP Version.

Compare it with this list:

PHP 8.5.x → safe from 8.5.12
PHP 8.4.x → safe from 8.4.27
PHP 8.3.x → safe from 8.3.36
PHP 8.2.x → safe from 8.2.35
PHP 7.4, 8.0, 8.1 → no official PHP release. You are only safe if your host installed a patched build (Plesk, cPanel and CloudLinux are shipping these, see below). These builds often keep the same version number (for example 8.1.34 on Plesk), so ask your host or check the build date. Plan a move to PHP 8.3 or newer.
PHP 7.3 or older → no fix exists. Upgrade PHP now.

Good news for Joomla 5 and 6 users: they already require PHP 8.1 or newer, so you are usually one PHP update away from being safe.

What hosting providers did

Linux distributions and the big hosting control panels received the fix before the public release, so most of them reacted quickly:

Plesk confirmed that all PHP versions it ships were affected and has released patched builds: PHP 8.2–8.5 on Linux and Windows, plus rebuilt copies of the older 7.4, 8.0 and 8.1 versions on Linux. The PHP that runs the Plesk panel itself gets its fix in Plesk 18.0.80 update #11 and 18.0.81 update #4. For PHP 5.6, 7.2 and 7.3, Plesk points to paid TuxCare extended support.
cPanel / WHM is rolling out patched EasyApache 4 PHP packages (ea-php). Run the system update in WHM and confirm the PHP version afterwards; on CloudLinux servers the ea-php fixes arrive through CloudLinux.
CloudLinux shipped three Imunify360 firewall rule sets on 21 October (8.83, 8.84 and 8.85) that block the public exploit tool and its variants, and gives scanning IP addresses a CAPTCHA. Patched alt-php and ea-php packages, including old versions such as 7.4, 8.0 and 8.1, are being released system by system; follow the CloudLinux status page for your OS.
DirectAdmin servers need PHP rebuilt through CustomBuild.
Cloudflare added firewall rules for the known attack patterns on all plans, including the free plan.

On shared hosting? Your host manages PHP for you. Check their status page or open a ticket and ask: "Is PHP on my account patched against CVE-2026-109618 and CVE-2026-109619?" Then confirm the version yourself in Joomla's System Information.

What we did at NextSoftware

Our sites run on a VPS with Plesk, and for us the fix was simple: we updated the Plesk components and everything went smoothly. Plesk had already published patched packages for every PHP version on the server, including the older ones, and it also added extra security rules on top. Our website also sits behind Cloudflare, whose firewall now blocks the known attack patterns, which gives us a second layer of protection.

Step by step: update PHP on Plesk

Back up first: Tools & Settings → Backup Manager → Back Up.
Go to Tools & Settings → Updates (Plesk Installer) and install the available updates for the PHP components. From SSH you can run plesk installer update instead.
Check the result in Tools & Settings → PHP Settings. The version shows in each handler's name and should be the patched number (for example 8.3.36). From SSH: /opt/plesk/php/8.3/bin/php -v (change 8.3 to your version).
For the old PHP 7.4, 8.0 and 8.1, the number stays the same (7.4.33, 8.0.30, 8.1.34). Look at the build date in the php -v output instead: a build from 21 October 2026 or later includes the fix (see the Plesk advisory).
Check each Joomla site in System → System Information.

If your server isn't getting updates, check that it uses the official Plesk mirror. Some hosting companies run their own mirrors that update later.

Step by step: update PHP on cPanel / WHM

In WHM, run the system update (Home → Software → Update System Software), or from SSH run dnf update 'ea-php*' (yum on older systems).
Restart PHP and Apache: /scripts/restartsrv_apache_php_fpm and /scripts/restartsrv_httpd.
Confirm the version in MultiPHP Manager and in Joomla's System Information.

On CentOS 7, or with PHP 7.3 and older, the standard packages won't get a fix. Only paid extended support (CloudLinux alt-php or TuxCare) covers them, so the real answer is moving to a supported system and PHP version.

Can't update yet? Temporary protection

Important: these steps make an attack much harder, but they are not a fix. The PHP team is clear in its official advisories that updating is the only complete solution. Use them to buy a few hours or days, not as a permanent answer.

1. Turn off "session upload progress"

The public attack abuses a little-known PHP feature that reports upload progress. Joomla doesn't use it, so it's safe to switch off, and the PHP team recommends leaving it off even after patching. Add this line:

session.upload_progress.enabled = 0

Plesk: Websites & Domains → your domain → PHP Settings → Additional configuration directives, or server-wide in Tools & Settings → PHP Settings → choose the version → php.ini.
cPanel / WHM: MultiPHP INI Editor → Editor Mode.
Your own server: in php.ini, or in a new file in the conf.d / php.d folder.

It has to be set at server level. Setting it in .user.ini or from PHP code with ini_set() comes too late to help. Restart PHP afterwards (PHP-FPM or Apache), otherwise the running workers keep the old setting.

2. On PHP 8.5, also turn off error backtraces

fatal_error_backtraces = 0

This closes the most reliable attack path on PHP 8.5. Add it the same way as above and restart PHP.

3. Put a web firewall in front of your site

If your domain isn't on Cloudflare yet, the free plan now blocks the known attack patterns. If your server has Imunify360, make sure its rules are up to date (ruleset 8.85 or newer; force an update with imunify360-agent update --force modsec-rules). The rules only protect you when Imunify's web firewall (ModSecurity) is switched on, and on LiteSpeed servers the blocking rule only logs attempts. A firewall only stops attacks it recognises, so it is a safety net and not a fix.

4. Remove PHP settings from .htaccess

On servers running PHP as an Apache module (mod_php), php_value and php_flag lines in .htaccess can help the attack. Move these settings to the hosting panel's PHP settings and delete them from .htaccess.

5. Keep upload limits sensible

Very large request sizes make the attack easier. Don't leave post_max_size and upload_max_filesize at huge values "just in case". Set them to what your site actually needs.

6. Last resort: take the site offline

If the site runs on a very old PHP version that will never be patched, the UK's National Cyber Security Centre advises taking it offline until it's fixed. In Joomla, System → Global Configuration → Site Offline hides the front end. Keep in mind the PHP flaw sits below Joomla, so the safest option is blocking access at server or firewall level until you can upgrade.

After patching: a quick health check

Because attacks started before many servers were updated, spend ten minutes checking your site:

Look for administrator accounts you don't recognise in Users → Manage.
Look for unexpected .php files in folders that should only hold media, such as images/, media/ and tmp/.
Check System → Update → Extensions and install any pending updates while you're there.
If anything looks suspicious, change your admin and database passwords and restore from a clean backup.

Don't fall for fake "exploit" downloads

GitHub and social media are already full of projects claiming to be PHP2Shell "tests" or "exploits". Security researchers warn that some of them are malware that steals passwords from whoever runs them. Don't download or run unknown scripts to "check" your site. The version check above is all you need.

Need a hand?

Not sure which PHP version your site really uses, can't find the right setting in your hosting panel, or worried your site may already have been hit? We can help. Our Joomla Security & Performance service includes a security audit, site hardening, malware removal and recovery, and backup and disaster-recovery setup, so your Joomla site is patched, cleaned up if needed, and better protected against the next one.