PHP2Shell: What to Do If Your Website Runs on PHP
On 21 October 2026 PHP released emergency updates for two flaws, known as PHP2Shell, that can let an attacker run code on a web server without logging in. Every PHP installation that serves web pages is at risk until it is updated, including WordPress, Drupal and Joomla sites. Find out which PHP version each site runs, update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, restart PHP, and plan an upgrade if you are on 8.1 or older.
What happened
On 21 October 2026 the PHP project published a security advisory headed “Critical remote code execution vulnerabilities, update now”, alongside four new releases: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. They fix two flaws, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. In plain English: someone on the internet can make your web server run their code, without a password.
The researchers who found them call the pair PHP2Shell. The PHP project’s own wording on who is at risk is broad: “all PHP installations serving web requests”, whichever way PHP is wired into the web server. Its advice is just as direct: “There are no complete mitigations, updating is the only safe choice.”
Why it matters for a business website
PHP sits underneath a very large share of the web. WordPress, Drupal and Joomla are all written in it, and so are a great many booking systems, client portals and online shops. Wiz Research, who found the flaws, demonstrated the attack against the standard WordPress, Drupal and Joomla installations, and say every PHP version released in the last decade is affected by at least one of the two flaws, back to version 5.4.
It was not a quiet disclosure, either. Qualys reports that Cloudflare had already seen attack traffic aimed at these flaws, including attempts to get round its protections. A site that is not updated should be treated as exposed.
What to do this week
- List every PHP site you have. Your main website, but also the booking system, the old campaign site, the staff portal, and anything a previous supplier set up and nobody has looked at since.
- Find out which PHP version each one really runs. On shared hosting it is a setting in the control panel, or a question for your host. On your own server, check what the web server reports, because the version on the command line can differ.
- Update to a fixed release. That means 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer. Then restart PHP, so the fixed version is the one actually serving pages and no old worker is left running the vulnerable code.
- If you are on PHP 8.1 or older, plan the move now. The PHP project no longer issues updates for those versions. Some Linux distributions and hosts maintain fixes of their own, so ask, but treat it as a stopgap. PHP 8.2 reaches end of life on 31 December 2026, so aim for 8.3 or newer.
- Follow PHP’s 23 October follow-up advice. A further advisory suggests setting
session.upload_progress.enabled=0until the next regular release, to close off an unlikely remaining route. - Put a web application firewall in front, if you do not have one. It is not a substitute for updating, but it blocks common attacks while you work through the list, and afterwards.
- Look for signs that someone got in first. Admin accounts you do not recognise, new files in upload folders, scheduled tasks nobody set up, visitors being redirected, or your host warning about spam sent from the site. If in doubt, restore from a backup taken before the problem, then update before you put the site back.
- Update the rest while you are there. WordPress itself, plugins and themes. Remove anything abandoned.
If you are on shared hosting
Your host patches the server itself, so the questions for them are simple: have you installed the fixed PHP releases, and which PHP version is my account set to use? If the answer to the second is 8.1 or older, change it to a supported version in the control panel, after checking the site still works on it.
Where Dacros comes in
This is the kind of work Dacros does: finding what your sites and servers actually run, patching and hardening them, putting a firewall and off-server backups in place, and cleaning up properly if something has already got in. The page on PHP and WordPress security sets out what that covers, and a free IT and security review is where a typical engagement starts. The review is yours to keep either way.
Sources
- PHP project: security advisory and release announcements, 21 and 23 October 2026
- Wiz Research: PHP2Shell
- Qualys: PHP2Shell: find, mitigate, and patch now
Frequently asked questions
How do I find out which PHP version my website uses?
On shared hosting, look in the control panel for a setting called PHP version, or ask your host. On your own server, the version the website uses can differ from the one on the command line, so check what the web server reports rather than relying on php -v alone.
Which versions fix PHP2Shell?
PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released on 21 October 2026, or anything newer. After updating, restart PHP so the fixed version is the one actually serving pages.
We are on PHP 8.1 or older. What now?
The PHP project no longer issues updates for 8.1 and older. Some Linux distributions and hosts maintain their own fixes for older versions, so check with yours, but the real answer is moving to a supported version. PHP 8.2 itself reaches end of life on 31 December 2026, so aim for 8.3 or newer.
Is a firewall enough on its own?
No. A web application firewall can block known attack patterns while you update, and it is worth having anyway, but PHP's own advice is that there are no complete mitigations. Updating is the fix.
Related guides
Want this handled for you?
Dacros runs IT and security for UK businesses. Book a free review and we will tell you what is worth doing: no jargon, no pressure, and the written picture is yours either way.