Critical PHP Vulnerabilities: What Your Business Needs to Do Now

If your business website runs on PHP, it needs a security update now. On 21 October 2026 the PHP project patched two critical flaws that can let an attacker take control of a web server without logging in. That covers WordPress, WooCommerce, Joomla, Drupal, Magento, Laravel and most other common website platforms.

The PHP team says there is no complete workaround: updating is the only real fix. Below, HEROTECH explains what has happened, how to tell if you’re exposed, and what to do this week.

What’s happened

Both flaws sit in the PHP engine itself, not in a plugin or theme. Each is rated 9.2 out of 10 (critical) under CVSS v4.0.

You may see these called “PHP2Shell” in the media. That nickname is unofficial.

Is your website affected?

Almost certainly, if it runs PHP and you haven’t updated since 21 October. The PHP team says every installation serving web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php is the most exposed, as a working attack there needs only one anonymous request.

The attack happens before your website’s own code runs. That means up-to-date plugins, strong passwords and WordPress security plugins do not protect you.

You are protected once you are on one of these versions or later:

If you’re on PHP 8.1 or older, the PHP project won’t ship you a fix. Some Linux distributions and long-term-support vendors provide their own patches. If yours doesn’t, you need to move to a supported version.

Why this can’t wait

• Attackers read patches too. Once a fix is public, the changed code shows exactly where the weakness was. Automated scanning for unpatched servers typically follows within days.
• No login is needed. Any server that answers web requests can be targeted, which is every website.
• The impact is total. With remote code execution, an attacker can deface your site, plant card-skimming code on checkout pages, send spam from your domain, or download your customer database.

For Australian businesses, a stolen customer database can also be a notifiable data breach under the Privacy Act. If it’s likely to cause serious harm, you must notify the OAIC and affected individuals. Patching now is far cheaper than responding to a breach later.

What to do now

1. Find out which PHP version your site uses

• cPanel: Software → MultiPHP Manager lists the PHP version for each domain.
• Plesk or DirectAdmin: check the domain’s PHP settings.
• WordPress: Tools → Site Health → Info → Server.
• SSH access: php -v shows the command-line version, which may differ from what the website uses. Check the PHP-FPM service as well.

On Debian, Ubuntu and Red Hat-based servers, the vendor may patch an older version number without changing it. Search the package changelog for the two CVE numbers to confirm.

2. Back up first

Take a full backup of your site files and database before changing anything. On a virtual server, a full snapshot is best. If you’re moving to a new PHP branch (for example from 7.4 or 8.1 to 8.3+), test on a staging copy first, as older plugins and themes may not be compatible. A patch within the same branch (such as 8.4.26 to 8.4.27) is low risk.

3. Apply the update

Shared hosting: your hosting provider applies PHP updates. Ask them to confirm they’ve deployed the patched versions. If your site is on PHP 8.1 or older, switch it to a supported version in your control panel.

Debian or Ubuntu server: run sudo apt update, then sudo apt full-upgrade (or upgrade just the PHP packages). Restart PHP-FPM or Apache afterwards.

Red Hat, AlmaLinux or Rocky Linux server: run sudo dnf update "php*", then restart php-fpm or httpd.

Remi repository users: the PHP team has warned the Remi repository won’t have same-day updates. Switch to your distribution’s packages or build from source.

Docker: pull the updated PHP base image, rebuild and redeploy. Update any pinned version tags.

4. Check everything still works

• Confirm the site reports the patched version (or a package that lists the CVE fixes).
• Compare installed PHP modules with your pre-update list.
• Test logins, contact forms, the shopping cart and payments.
• Check PHP and web server logs for new errors.

Can’t update today?

The PHP team has published settings that reduce exposure but do not make a server safe. Use them only to buy a few hours, and only if you control the server configuration (most shared hosting customers won’t).

• Disable session upload progress (session.upload_progress.enabled=0) in php.ini or the FPM pool, then restart all workers. Setting it in application code or .user.ini won’t work.
• Lower post_max_size to 8M if the site takes no file uploads, or 32M if it does.
• Remove the PHP memory limit (memory_limit=-1) in a way applications can’t override, but only with a container or cgroup memory cap in place.
• On PHP 8.5, set fatal_error_backtraces=0 and restart all workers.

Then schedule the real update as soon as possible.

How HEROTECH can help

HEROTECH managed services clients don’t need to do anything. We’re already reviewing and patching the PHP environments we manage, and we’ll contact you if a site needs a larger upgrade.

If you’re not a HEROTECH client, or you’re unsure whether your hosting provider has acted, we can help. We’ll:

• confirm which PHP version your site is actually running
• check whether your host has deployed the fix
• back up your site and apply the update
• test that your website, forms and online store work as before
• plan a safe move for sites still on unsupported PHP versions

Contact HEROTECH on 1300 437 536, email help@herotech.com.au, or visit herotech.com.au.

Sources

Vulnerability details come from the official PHP team announcement and advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. Support dates: php.net/supported-versions. Usage statistics: W3Techs. Checked on 21 October 2026. Reports of attacks in the wild come from third parties and are not confirmed in the official announcement.