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: 30 October 2026. Most hosts are patched now, so this page is no longer updated daily.
In 30 seconds
- Updating WordPress won’t fix it. The fix is in PHP, on your server.
- Ask your host if the PHP2Shell fix is installed. There’s a message to copy below. Running your own server? Install the fixed PHP and restart it.
- Still on PHP 8.1 or older? Back up and move to 8.3 or 8.4.
- Take five minutes to check for signs of a hack. Here’s how.
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 by PHP (CVSS 4.0). 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 Amazon later reported a first attack attempt on 17 October, four days before the fix.
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.
WordPress updates fix these
Your contentPosts, pages, images
Plugins & themesUpdated from your dashboard
WordPress coreUpdates itself, or one click
Only your host can fix this one
PHPThe language WordPress runs on
PHP2Shell is hereYou 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.
On Ubuntu, PHP keeps showing the old number (8.3.6 on 24.04, for example) even once it’s fixed. Check the package version instead (apt policy php8.3, or dpkg -l | grep php). These are fixed, according to Ubuntu ↗:
| Ubuntu | PHP | Fixed package |
|---|---|---|
| 26.10 | 8.5 | 8.5.9-0ubuntu2.1 |
| 26.04 | 8.5 | 8.5.4-0ubuntu1.5 |
| 24.04 | 8.3 | 8.3.6-0ubuntu0.24.04.13 |
| 22.04 | 8.1 | 8.1.2-1ubuntu2.28 |
| 20.04 (ESM) | 7.4 | 7.4.3-4ubuntu2.29+esm5 |
| 18.04 (ESM) | 7.2 | 7.2.24-0ubuntu0.18.04.17+esm14 |
| 16.04 (ESM) | 7.0 | 7.0.33-0ubuntu0.16.04.16+esm22 |
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.
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.
Even once PHP is fixed, PHP suggests one more setting until its next regular bugfix release: session.upload_progress.enabled=0. It closes an unlikely extra attack path (CVE-2026-115560). WordPress itself doesn’t use this feature, so it is safe to ask your host for it, or to set it yourself on your own server.
What hosts are saying
What the hosts themselves have announced (times in UTC). “Protected” means a shield in front of PHP while the real fix rolls out. If your host isn’t listed, ask them directly.
- CloudwaysPatched
The rollout is complete: all active servers run the fixed PHP, on Autonomous and Flexible. Support is contacting the few customers whose setup needs extra help.
22 October, 10:11Status page ↗ - DreamHostPatched
The PHP security updates are applied across its entire network. Nothing to do for customers.
22 October, 18:12Status page ↗ - FlywheelPatched
The fix is deployed on the whole platform. Nothing to do for customers.
21 OctoberStatus page ↗ - GoDaddyVPS: do it yourself
VPS customers need to update PHP themselves (GoDaddy offers to do it as a paid service).
20 OctoberAnnouncement ↗ - HostingerPatched
The fixed PHP is on all its managed hosting servers (Web, Agency and cPanel). Your site may still show an older-looking number like 8.5.11: the fix was added to the version you already use.
22 October, 06:44Status page ↗ - InMotion HostingRolling out
Shared and dedicated servers run the updated PHP; the VPS fleet is still being patched, with no estimate yet.
22 OctoberStatus page ↗ - KinstaPatched
Kinsta emailed customers that the patch is complete across its whole network, live and staging sites included. Its edge firewalls blocked exploit attempts in the meantime, and it reports no breaches.
23 OctoberCommunity post ↗ - Liquid WebRolling out
Fixed PHP builds are out for cPanel, CloudLinux and Plesk (Linux and Windows), and the deployment across its fleet is still ongoing. Not patched yet? Run a package update in your control panel; a phpinfo page shows your version.
24 October, 21:55Status page ↗ - NamecheapPatched
The fix is deployed on all its servers. Customers with their own VPS or dedicated server need to update themselves.
22 October, 16:50Status page ↗ - OVHcloudPatched
Web hosting is patched on all clusters, for PHP 7.4 to 8.5.
21 October, 17:53Status page ↗ - PantheonPatched
Every live site on PHP 8.2 to 8.5 is patched. Older PHP versions wait for fixes from its vendors.
21 October, 19:49Status page ↗ - PressableProtected
Says every PHP version it offers is protected against both flaws.
21 OctoberStatus page ↗ - Rocket.netPatched
Its PHP update is marked resolved, with fixes for every PHP version from 5.2 to 8.5. Your version number may not change: a phpinfo() build date of 21 October or later means the fix is in.
22 October, 10:36Status page ↗ - SiteGroundProtected
Server-level protection on all its servers, with the affected PHP features turned off. Nothing for customers to do.
21 October, 11:30Blog post ↗ - WP EnginePatched
The fix is deployed on the whole platform (PHP 7.4.33.17, 8.2.35, 8.4.27 and 8.5.12). Nothing to do for customers.
22 October, 01:19Status page ↗
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, Debian 12 and Debian 13. CloudLinux has released fixed alt-php and ea-php builds (they keep an older-looking number, like 8.4.26-2), and Red Hat has started shipping fixes for Red Hat Enterprise Linux, with more updates in progress.
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. My 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 go for:
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, at anything that changed since 17 October. 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.comand 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
.phpfile insidewp-content/uploadsis 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.
Already using AI Engine with Claude, ChatGPT or Codex? If your AI is connected to your site through AI Engine, it can run most of these checks for you: paste this prompt. It only asks the AI to look, never to change anything. It can’t see your server’s files or PHP version, so the uploads folder and the fix itself stay with your host. The database checks need AI Engine Pro with Database access turned on; without it, the AI will tell you what it skipped.
Check my WordPress site for signs of a hack. Read only: do not change, install, update or delete anything. 1. List every administrator account and, if you can query the database, when each one was created. Flag any created since 17 October 2026. 2. List all installed plugins and flag any that look unfamiliar to a normal site, or that have an update waiting. 3. If you can run read-only SQL, look for <script, <iframe, eval( or base64_decode in the options table and in posts or pages modified since 17 October 2026. 4. Sum up what looks suspicious, what looks fine, and what you couldn’t check.
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. CISA, the US cybersecurity agency, goes further for servers that can’t be updated yet or still run PHP 8.1 or older: take them offline until they can be.
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. Most hosts are patched now, so I no longer add to it every day.
- August Several research teams, including Wiz and OpenAI, find the two flaws with the help of AI tools and report them privately to the PHP team.
- 17 October Amazon’s honeypots log a first attack attempt, three days before the leak and four days before the fix. Whether it would have worked on a real server is unclear.
- 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.
- 21 October, late Red Hat starts releasing fixed PHP packages for Red Hat Enterprise Linux, with more on the way. Ubuntu and Debian (12 and 13) now have fixes for every supported release.
- 22 October, afternoon More big hosts finish: Cloudways and Namecheap now run the fixed PHP on all their servers, and CloudLinux, used by many shared hosts, ships its fixed PHP builds.
- 23 October Kinsta tells customers the fix is on every site in its network, and Rocket.net closes its PHP update. Seven of the fourteen hosts I follow now report the fix fully deployed.
- 23 October PHP suggests keeping
session.upload_progress.enabled=0until its next regular bugfix release, even on fixed versions, to close an unlikely extra attack path (CVE-2026-115560). - 24 October WP Engine’s status page confirms the fix has been on its whole platform since 22 October. Liquid Web and InMotion’s VPS servers are still being patched.
- 25 October, 03:50 Most hosts and distributions have now shipped the fix. If yours hasn’t, ask them, or consider moving.
Sources: the official PHP announcement (and its 23 October note), PHP’s advisories for CVE-2026-109618 and CVE-2026-109619, Amazon’s report, Cloudflare’s report, and CISA’s alert. 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.
Read next: PHP2Shell goes away once your host updates PHP. The other big risk is the services that hold keys to thousands of sites at once, and it already happened this week. The next big WordPress hack.
Questions, or something to share about your host? Come talk about it on our Discord. Stay safe 🙂
