PHP2Shell: The Critical PHP Flaw Every Website Owner Needs to Patch Now
by Prince Radebe, Technical Director
On 21 October 2026, the PHP project released emergency security updates for two critical vulnerabilities, now widely known as PHP2Shell. If your website, online shop, client portal or internal business system runs on PHP, it is almost certainly affected, and it needs to be patched this week, not next quarter.
PHP is the language behind WordPress, WooCommerce, Joomla, Drupal, Magento and countless custom-built Laravel and PHP applications. That makes PHP2Shell one of the most far-reaching web security issues in years. This guide explains what it means for your business in plain language, and exactly what to ask your hosting provider or developer.
What is PHP2Shell?
PHP2Shell is the name given to two flaws in PHP itself: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 for severity.
In simple terms, they allow an attacker to send a specially crafted request to your website and run commands on your web server. They do not need a username, a password or any access to your systems first. The "shell" in the name refers to that outcome: command-line control of the server your website runs on.
Once an attacker has that foothold, they can typically:
- Read or steal data your website can reach, including customer details, orders and login records
- Plant hidden malware or "back doors" to get back in later, even after you patch
- Deface your website or redirect your visitors to scam pages
- Use your server to send spam or attack other organisations, which can get your domain blacklisted
Importantly, this is not a WordPress bug or a plugin bug. It sits in PHP, the engine underneath. Keeping WordPress and your plugins up to date is still essential, but it does not fix this.
Why this one is urgent
Three things make PHP2Shell more serious than the usual monthly security update:
- It affects almost every PHP version. Every release from PHP 5.4 up to the versions fixed on 21 October is vulnerable. That covers more than a decade of PHP releases.
- Attacks started before the fix. Details of the flaws leaked the day before the planned announcement, and security firms including Cloudflare and Amazon reported attempts to exploit PHP2Shell that began before the official patches were available.
- Settings alone cannot fully protect you. The PHP project has been clear that configuration changes can reduce exposure to some attack paths but do not make an installation safe. Updating is the only complete fix.
Are you affected?
You are affected if both of these are true:
- Your website or web application runs on PHP, and
- The PHP version it uses was released before the fixed versions below.
These are the fixed versions, released on 21 October 2026. Anything older than the version shown is vulnerable:
| Your PHP version | Safe from |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 and older | No official fix (see below) |
How to find your PHP version:
- WordPress: go to Tools, then Site Health, then the Info tab, and open the Server section.
- cPanel or a similar hosting dashboard: look for a section called Select PHP Version or MultiPHP Manager.
- Custom systems: ask your developer or IT team. It is a two-minute question for them.
One caution: some Linux providers apply security fixes without changing the version number. If your server reports an older number, ask your host or IT team to confirm whether the PHP2Shell fix has been applied, rather than assuming either way.
What to do, depending on how your site is hosted
If you use shared or managed hosting
On shared hosting, you cannot patch PHP yourself. Your hosting company has to install the fixed version on its servers. Many large hosts started rolling out fixes on 21 October, but rollouts take time and not every provider moves at the same speed.
Changing the PHP version in your cPanel or hosting dashboard only switches between the versions your host has installed. It does not install the security fix. Contact your host today and ask the questions at the end of this article.
If you run your own server, VPS or cloud environment
Whoever manages the server needs to:
- Install the patched PHP packages from your operating system vendor, or upgrade to a fixed PHP version
- Restart PHP-FPM, Apache and any long-running PHP workers, because the fix does not take effect until the old processes stop
- Rebuild and redeploy any Docker containers or application images that bundle their own copy of PHP
- Check every server and environment, including staging sites, old marketing microsites and internal tools that are reachable from the internet
If you are still on PHP 8.1 or older
The PHP project no longer issues official releases for PHP 8.1 and older. Some hosting control panels and Linux vendors have backported the fix to these versions, but you are now relying entirely on them to protect you.
If your system has been stuck on an old PHP version because "it still works", PHP2Shell is the clearest possible signal that it is time to plan an upgrade. This is common with older custom-built systems, and it is exactly the kind of legacy modernisation project that pays for itself the first time a crisis like this hits.
If you cannot patch immediately
A web application firewall (WAF), such as the protections some security and hosting providers have deployed for PHP2Shell, can block many known attack patterns while you arrange the update. Your technical team may also apply temporary PHP settings recommended by security researchers.
Treat these as a seatbelt, not a fix. They buy you time; they do not close the hole.
After you patch: check whether anyone got in first
Because attacks began before the patches were released, patching closes the door but does not tell you whether someone already walked through it. Once you are updated, ask your developer or IT team to check for warning signs, such as:
- New administrator accounts, plugins or files that nobody on your team recognises
- The web server starting command-line programs it would not normally run
- Unusual crashes or "memory exhausted" errors in your server logs in the days before you patched
- Unexpected spikes in outgoing traffic or email from your server
- Warnings from Google, your bank or your customers about your website
If you find signs of compromise, do not simply delete the suspicious files and move on. Attackers often leave more than one way back in. Bring in someone who can investigate properly and clean the system.
A note on POPIA
If your website stores personal information, such as customer names, contact details, ID numbers or order history, a compromise is not only a technical problem. Under section 22 of the Protection of Personal Information Act (POPIA), if there are reasonable grounds to believe that personal information has been accessed by an unauthorised person, you must notify the Information Regulator and the affected people as soon as reasonably possible. Patching quickly and documenting what you did is your best protection, both for your customers and for your organisation.
Questions to ask your host or developer this week
Copy these into an email today:
- Is our website (and any other system we run) built on PHP, and which PHP version does it use?
- Has the PHP2Shell fix (CVE-2026-109618 and CVE-2026-109619) been applied to every server and environment we use?
- Have the PHP and web server processes been restarted since the fix was installed?
- Are any of our systems on PHP 8.1 or older, and if so, who is providing the fix and what is the plan to upgrade?
- Have you checked our servers for signs that they were attacked before the fix was applied?
- Do we have a web application firewall in front of our website?
If the answers are vague, slow or "we will look into it", treat that as useful information about your current level of protection.
The bigger lesson
PHP2Shell is a textbook case for an emergency fix: an actively targeted security flaw in software that runs on live production systems. As we explained in What Is a Hotfix?, the organisations that handle moments like this calmly are the ones that already know what they run, can deploy updates quickly and safely, and have someone watching their systems around the clock.
If you are not sure whether your PHP systems are safe, or you need help patching, checking for compromise or upgrading an older application, get in touch with our team. We offer security audits, penetration testing and 24/7 monitoring for South African businesses, so the next critical flaw is a routine update rather than a crisis.