PHP2Shell: what it is, and what to do on your WordPress site

PHP2Shell is a pair of critical security flaws in PHP, the software that runs WordPress on your server. Updating WordPress or your plugins won’t fix it. Your host has to update PHP, and you should check that they did.

Last updated: 21 October 2026, 22:21 UTC. We keep this page and its timeline updated until most sites and hosting services are patched.

What is PHP2Shell?

Almost every WordPress site runs on PHP. On 21 October 2026, the PHP team fixed two flaws in it (CVE-2026-109618 and CVE-2026-109619), both rated 9.2 out of 10. They let a stranger send a specially crafted request to your site and run their own code on your server, without any password. The researchers who found them showed the attack working on a standard WordPress install. Details leaked a day before the fix was ready, and attack attempts started the same day.

It is not a WordPress bug, so a WordPress update, a security plugin or a firewall plugin can’t fix it. The fix lives one level below, on the server.

You may also have seen WP2Shell in the news. The names are close, but that is a different set of flaws, in WordPress itself, and a normal WordPress update fixes it.

Is my site affected?

Until your server gets the fixed PHP, assume yes. In wp-admin, go to Tools → Site Health → Info, open Server, and look at PHP version:

Your PHP version	Fixed from
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 and older	Only if your host adds the fix (and you should upgrade anyway)

If your number is lower, don’t panic yet: some hosts and Linux systems add the fix without changing the version number. Your host is the only one who can tell you for sure, which is the next step.

What do I need to do?

If a hosting company runs your server (shared hosting, managed WordPress hosting), updating PHP is their job, and most of them are working on it right now. Your part is to ask and get a clear answer. You can copy this:

Hi, my site runs PHP [your version]. Has the PHP fix for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) been installed on my server? If not, when will it be? Thank you!

“We added firewall protection” is good to hear, but it is not the same as “PHP is updated”. Ask until you get the second answer.

If you run your own server (a VPS, a cloud server, Docker), it’s on you. Install the fixed PHP packages from your Linux distribution or PHP’s repository, then restart PHP-FPM or Apache, because PHP keeps running the old code until it restarts. Some distributions already ship fixed packages with an older-looking number (Ubuntu 24.04’s fix is 8.3.6-0ubuntu0.24.04.13, for example), so trust your distribution’s security notice rather than the version number alone. With Docker, pull the fixed image and recreate the containers. A pull alone changes nothing.

If you’re on PHP 8.1 or older, this is the moment to move to PHP 8.3 or 8.4. Most hosts let you switch in their dashboard. Take a backup first, update your plugins and themes, then switch and click through your important pages (home, contact form, checkout). If something breaks, the PHP error log tells you which plugin.

What hosts are saying

What the hosts themselves have announced, with the date (times in UTC). “Mitigations” means protection in front of PHP while the real fix is rolled out. If your host isn’t listed, ask them directly.

• Cloudways (21 October, 22:19): temporary protections in place across all servers, and the official fix is rolling out in phases. Cloudways status
• DreamHost (21 October, 20:43): rolling out the fixed PHP across all servers, expected to finish soon; fixes for PHP 8.1 and older within a day. DreamHost status
• Flywheel (21 October): patched. The fix is deployed on the whole platform, nothing to do for customers. Flywheel status
• GoDaddy (20 October): VPS customers need to update PHP themselves (GoDaddy offers to do it as a paid service). GoDaddy
• InMotion Hosting (21 October, 14:40): dedicated servers are done, VPS in progress, shared hosting protected while waiting for the patch. InMotion status
• Kinsta (21 October): temporary protections are rolling out, and patched PHP will follow once validated. No action needed from customers, who will get an email once the patch is applied. Kinsta community. On our own Kinsta sites, the fixed PHP 8.5.12 was live by 21 October, 16:38, and the fixed PHP 8.3.36 by 19:53.
• Liquid Web (21 October, 17:57): customers on cPanel/WHM can install the fix themselves with a cPanel update and a yum update; Liquid Web is planning the rest of its rollout. Liquid Web status
• Namecheap (21 October, 16:50): all public services are protected and the final patches are being installed. Customers with their own VPS or dedicated server need to update themselves. Namecheap status
• OVHcloud web hosting (21 October, 17:53): patched on all clusters, for PHP 7.4 to 8.5. OVHcloud status
• Pantheon (21 October, 19:49): patched on all live sites running PHP 8.2 to 8.5. Older PHP versions are waiting for fixes from its vendors. Pantheon status
• Pressable (21 October): says every PHP version it offers is protected against both flaws. Pressable status
• Rocket.net (21 October, 22:06): the fixed PHP is being deployed across its servers in rolling waves. Rocket.net status
• SiteGround (21 October, 11:30): server-level protection on all its servers, with the affected PHP features turned off. Nothing for customers to do. SiteGround blog
• WP Engine (21 October, 21:52): still deploying the fix, with protections in place meanwhile; every PHP version it runs (7.4, 8.2, 8.4, 8.5) will be updated. WP Engine status

Running your own server or a control panel? Fixed packages are out for cPanel (EasyApache 4, including fixes for PHP 7.4, 8.0 and 8.1), Plesk on Linux (PHP 8.2 to 8.5; older versions and Windows still to come), Ubuntu and Debian 13. CloudLinux is rolling out its alt-php builds. Debian 12 and Red Hat had no fix yet on 21 October.

What if PHP can’t be updated today?

• Put Cloudflare in front of your site. Cloudflare added protection for PHP2Shell to every plan with its firewall turned on, the free plan included. It only helps if your visitors actually go through Cloudflare.
• Ask your host for the temporary settings. PHP’s own advisories list a few server settings that block the known attacks, like turning off session.upload_progress. Only whoever runs the server can apply them, and they are partial.
• Don’t count on a maintenance-mode plugin. The attack can happen before WordPress even loads, so a plugin can’t stop it.
• If your host won’t give you a date, it’s a good moment to look for a better one. Our guide on choosing a WordPress host can help.

All of these buy time. None of them replaces the PHP update.

What could happen if my site gets hacked?

Whoever gets in can do anything WordPress can do, and usually more. With this kind of access, attackers typically:

• create a hidden administrator account, so they can come back later,
• leave a small “backdoor” file on the server, which survives even after the hole is fixed,
• redirect your visitors to scam or spam sites, often only visitors coming from Google or on mobile, so you never see it yourself,
• add thousands of spam pages that Google indexes under your name,
• steal your database: customers, emails, orders,
• on shops, slip in a card skimmer at checkout,
• use your server to send spam or attack others, which can get it blocked.

This is also why patching later isn’t enough on its own: a backdoor planted before the fix stays after it.

How would I know if I was hacked?

Most hacks are quiet, so look rather than wait for symptoms. Five minutes is enough:

• Users: in wp-admin, open Users and filter by Administrator. Anyone you don’t know?
• Plugins: anything installed that you didn’t install?
• Google: search site:yourdomain.com and look for pages you never wrote (casino, pharmacy, foreign-language spam).
• Search Console: if you use Google Search Console, check Security issues.
• Uploads folder: a .php file inside wp-content/uploads is a red flag. That folder is for images and documents.
• Your host: a warning email about malware, spam or high resource use.

If anything looks wrong, ask your host to scan the server and to restore a backup from before it appeared. Then change all your passwords (WordPress, hosting, database), since the attacker may have seen them.

Quick answers

Should I take my site offline? Usually no. If your host says the fix or temporary protections are in place, keep your site running and keep an eye on it. If you run your own server and can’t patch it or protect it at all, taking it offline for a day is a reasonable choice. Either way, make sure you have a recent backup stored somewhere other than the server.

Will WordPress show me an update button? No. PHP isn’t updated from wp-admin. On shared and managed hosting, your host installs the fixed PHP on the server, and you don’t need to click anything. The PHP version menu in cPanel or your host’s dashboard only switches between versions; it doesn’t install the fix.

Will my security plugin protect me? No. The attack happens inside PHP, before WordPress and its plugins even start, so security and firewall plugins never see it. A firewall in front of your server (like Cloudflare) can help, a plugin can’t.

My site is on WordPress.com (or another fully managed service). Do I need to do anything? Not on the server side: the company running it updates PHP for you. You can still do the five-minute check below for signs of a hack.

I’m stuck on PHP 7.4 (old theme, old plugins). What now? Ask your host first: some hosts and control panels offer fixed builds of 7.4, 8.0 and 8.1. That buys you time, not a future. Plan the move to 8.3 or 8.4, starting with updating or replacing the plugins that hold you back.

I look after many client sites. Where do I start? Make a list of every site and who hosts it. Ask each host the question above, starting with sites on your own servers or on old PHP versions, since those are the ones nobody else will fix for you.

Timeline

Times are in UTC. We keep adding to it until most sites and hosting services are patched.

• 19 August: researchers at Wiz find the two flaws, with the help of AI tools, and report them privately to the PHP team.
• 20 October: details of the two flaws leak online, a day before the planned fix. The PHP team confirms a release for the next day at 14:00.
• 21 October, 03:02: Cloudflare turns on protection for every plan with its firewall, the free plan included.
• 21 October, 07:43: Cloudflare reports the first attack attempts against its customers.
• 21 October, 14:00: PHP releases the fixes: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus source-only fixes for the retired 7.4, 8.0 and 8.1.
• 21 October, afternoon: Linux distributions start shipping fixed packages (Ubuntu among the first). Large managed hosts announce firewall protection while they test and roll out the new PHP.
• 21 October, evening: the first big hosts finish. Pantheon has patched every live site on PHP 8.2 to 8.5, and Kinsta sites on PHP 8.3 and 8.5 now run the fixed versions.

The short version

1. Check your PHP version in Tools → Site Health → Info → Server.
2. Ask your host if the PHP2Shell fix is installed, or install it yourself and restart PHP.
3. On PHP 8.1 or older, back up and move to 8.3 or 8.4.
4. Take five minutes to check for signs of a hack.

Sources: the official PHP announcement, PHP’s advisories for CVE-2026-109618 and CVE-2026-109619, and Cloudflare’s report. Our own plugins (AI Engine, SEO Engine, Media Cleaner and the others) run on PHP 8.1 to 8.5, so they won’t hold back your upgrade.

Questions, or something to share about your host? Come talk about it on our Discord. Stay safe 🙂