PHP2Shell: what to do about the critical PHP vulnerability
On 21 October 2026 the PHP project released emergency fixes for two critical flaws in PHP itself, together nicknamed PHP2Shell. They let an attacker run their own code on your server. If your website runs on PHP, here's how to tell whether you're affected and what to do.
What PHP2Shell is
PHP2Shell is the name given to two separate vulnerabilities in the PHP core, the software behind a large share of the world's websites, including most WordPress, Drupal, Joomla and Magento sites:
- CVE-2026-109619: a use-after-free flaw in PHP's file upload handling.
- CVE-2026-109618: a memory corruption flaw triggered under low-memory conditions.
Both are rated critical (around 9.2 out of 10, with one scored at the maximum 10.0). Either can lead to remote code execution, which means an attacker running commands on the server that hosts your site, without a password. Security firms have reported attacks against affected servers already happening.
A third, related flaw (CVE-2026-115560) was disclosed shortly afterwards. It depends on your server's configuration and does not yet have a full fix, only a temporary workaround.
Are you affected?
The flaws are in PHP itself, not in WordPress or any one plugin, so they affect sites across every PHP platform. The fixes were released on 21 October 2026. You are on a patched version if you are running at least:
| PHP branch | First patched version |
|---|---|
| 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 earlier | No fix: these branches are end of life and must be moved to a supported branch |
Always check the current advice on the official PHP site and with your hosting provider.
A word of caution on version numbers
You might be able to see a PHP version in your site's response headers, or on a status page. That number alone doesn't settle it, in either direction:
- It may understate how safe you are. Linux distributions such as Debian, Ubuntu and Red Hat often apply the security fix without changing the version number, so a server showing an older version may already be protected.
- It may overstate how safe you are. The version shown can be stale, cached or set by a proxy in front of the real server.
The only reliable way to know is to check the actual PHP build on the server, and its configuration, rather than trust the number on the outside.
What to do now
- Update PHP to the patched version for your branch, or apply your hosting provider's update. On managed hosting this may already have happened: confirm it, don't assume it.
- If you can't update immediately, apply the vendor's temporary mitigations, and treat it as urgent rather than a job for next month.
- Address the unpatched flaw (CVE-2026-115560) by applying the recommended configuration workaround until a full fix is available.
- Check for signs of compromise. Because these flaws have been exploited in the wild, a server that was running an affected version and exposed to the internet should be checked, not just patched.
- Update the rest of the stack while you're at it: the CMS, its plugins and themes are the usual way attackers reach PHP in the first place.
How I can help
I'm Michael McCoy, a Glasgow-based software developer with 30 years' experience building and looking after web applications. I work with businesses and organisations across Glasgow, the rest of Scotland and the UK, locally where it helps and remotely where it doesn't. If you're not sure whether your site is affected, or you don't have a developer to turn to, I can help in two steps:
- Identify whether you have the problem: I'll check the actual PHP version and configuration on your server, not just the version shown on the outside, and tell you plainly whether you're exposed.
- Fix it: update PHP and the rest of the stack to a supported, patched version, apply the mitigations for the flaw that isn't fully fixed yet, and check the site over. If it turns out your platform is too old to update cleanly, I'll give you a costed plan to bring it up to date.
Afterwards, a care plan keeps your site patched so the next critical vulnerability isn't a scramble.