You’ve heard about PHP2Shell, and now you’re wondering whether your website is at risk. If your site runs on WordPress, it almost certainly uses PHP, so it’s a fair question.
This post explains what PHP2Shell is, how to check your own site in a few minutes, and what to do if it needs fixing.

What is PHP2Shell, and does it matter for WordPress?
PHP is the programming language that runs behind WordPress. Every time someone opens a page, PHP helps build it.
PHP2Shell is the nickname for two serious flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. (A CVE is just a public ID number for a known security flaw.) Both allow remote code execution. In plain terms, someone on the internet can run commands on your web server without logging in.
Attackers started trying to exploit the flaws before the fix was public, and security researchers have since confirmed successful attacks. This one is not theoretical.
One point catches people out. The flaws are in PHP, not in WordPress. Updating WordPress, your theme or your plugins does not fix them. Only a newer version of PHP does.
Is my website affected by PHP2Shell?
If your site runs on PHP and hasn’t been updated since 21 October 2026, assume yes. Almost every PHP version in use was affected.
The fix arrived in four versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They’re listed in PHP’s official release notice. If your version number is lower than the one for your branch, assume you’re exposed until your host says otherwise.
PHP 8.1 and older are the harder case. The PHP team didn’t release a fix for them, and those versions are past their end-of-life date. That means they no longer get regular security updates.
There’s a catch. Some Linux vendors, including Ubuntu, Debian, Red Hat and cPanel, backported the fix into their own packages for certain older versions. A site on PHP 8.1 through one of those packages may already be protected, even though the version number didn’t change. Some vendors only offer this on a paid extended support plan, so it isn’t guaranteed.
So don’t guess from the number. Ask your host whether the fix has been applied to your exact setup. Even if the answer is yes, running end-of-life PHP is a short-term patch, not a plan. Upgrading to a supported version is the real fix.
Some sites aren’t in the firing line. If you’re on Shopify, Wix or Squarespace, the provider runs the servers and handles patching. The same goes for a static website, which is built from plain pre-made files and has no PHP at all.
How do I check my PHP version?
If you can log into WordPress, it takes about a minute.
- Go to Tools, then Site Health, then the Info tab.
- Open the Server section.
- Find the PHP version and compare it with the list above.
The number alone doesn’t settle it, because some hosts fix PHP without changing the version. If you’re unsure, ask your host directly.
What should you do now?
Work through this list in order:
- Check your PHP version using the steps above.
- Ask your host or developer in writing. Something like: “Has PHP on my site been updated to fix CVE-2026-109618 and CVE-2026-109619?” A clear yes should say what was updated and when.
- Book an upgrade if you’re on PHP 8.1 or older. WordPress’s guide to updating PHP covers what to check first, mainly that your theme and plugins work on the newer version.
- Ask about a stopgap if the update can’t happen today. Ask your host to set
session.upload_progress.enabledto0in PHP’s settings. WordPress doesn’t use that feature, so switching it off is safe. It closes one known attack route, but PHP itself says no stopgap fully protects you and updating is the only safe fix. Don’t switch off file uploads altogether, because that would break your media library. - Watch for warning signs. Look for admin users you don’t recognise, files you didn’t add, a sudden slowdown or warnings from your host. Ongoing website monitoring catches this kind of change quickly.
Don’t assume it’s been done. Ask.
What if my site was already attacked?
Updating PHP closes the door. It doesn’t tell you whether someone already walked through it.
If your site went unpatched for days after the news broke, treat it with some caution. Ask your host or developer to scan for unfamiliar files and new admin accounts. Change your WordPress, hosting and database passwords. Then check that you have a recent backup from before the 17th of October, which is when the first attacks were seen.
If anything looks wrong, don’t try to clean it up yourself. A site that’s been quietly altered can look perfectly normal while it sends spam or sends visitors somewhere else. A developer can check properly, and restore a clean copy if needed.
What did we do about PHP2Shell?
We patched the morning the news broke. Every site we host now runs a supported version of PHP with the fix applied.
Some of our sites are built as headless WordPress, where the public website and the WordPress editing area are kept apart. Visitors see fast, pre-built pages. WordPress sits behind its own login with two-factor authentication, so strangers can’t reach it at all. That’s an extra layer of protection, not a replacement for patching, so we patch anyway.
Keeping PHP current is a core part of WordPress website maintenance, and it’s one of the main reasons maintenance is worth paying for. If you’d rather not chase this yourself, our maintenance and support service covers it.
Not sure whether your site has been fixed? We’re happy to talk it through and point you in the right direction, no obligation, no pitch.