At three o’clock UK time on Wednesday 21 October, the PHP project released fixes for two critical flaws now known as PHP2Shell. PHP is the language WordPress is written in, and WordPress runs 39.6% of all websites, according to W3Techs on 23 October. The UK’s National Cyber Security Centre (NCSC) warned the same day that the flaws “may allow attackers to execute commands on any web server running PHP”.
If you own a WordPress site, the first thing to know is that there is nothing to update inside WordPress. WordPress.org said so in its own post that day: “No WordPress update is required or planned for these issues.” The fix belongs to whoever runs the server your site sits on. The ten large hosts we checked said between 21 and 23 October that they had patched, or were patching, the servers they run. The sites at risk are the ones where nobody is sure whose job it is.
What PHP2Shell is, in plain English
Every time someone visits a WordPress page, the server runs PHP to build it. PHP2Shell is a pair of flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, rather than in WordPress, a theme or a plugin. The PHP project rated both 9.2 out of 10 for severity and said the risk covers all PHP installations serving web requests, highest on servers using Apache’s mod_php. Used successfully, they let an attacker run their own commands on the server.
The PHP project’s advice left no room for workarounds: “There are no complete mitigations, updating is the only safe choice.” Hosts can block known attack patterns with firewall rules while they update, and many did. Hostinger described those rules as “a safety net”. They are not the fix.
Attackers did not wait for the announcement. Amazon reported on 21 October that one of its decoy servers had recorded an attempt to use the flaws on 17 October, four days before public disclosure. It added that PHP2Shell “is now seeing broad exploitation attempts in the wild”, while saying it was “unclear if any of these attempts would have succeeded in real-world systems”.
Is your WordPress site affected?
That depends on which version of PHP your server runs, and whether your host has installed the fixed build of it.
| PHP version | Is there a fix? |
|---|---|
| 8.2, 8.3, 8.4, 8.5 | Yes. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, or anything later. |
| 7.4, 8.0, 8.1 | No finished release from the PHP project, only source backports. cPanel and CloudLinux built patched packages from them, so it depends on your host. |
| 7.3 and older | Nothing from the PHP project. CloudLinux patched its builds back to PHP 5.2. |
The older versions matter because so many WordPress sites still use them. WordPress.org’s own statistics, read on 24 October, show 34.7% of WordPress sites on PHP 8.1 or older, and 15.5% on PHP 7.4 alone. Its post was direct about what that means: “Versions of PHP prior to 8.2 no longer receive security updates from the PHP project.”
For those versions, the PHP project published “minimal source-backports” rather than finished releases. cPanel and CloudLinux, which make server software that many shared hosts run on, shipped patched PHP 7.4, 8.0 and 8.1 packages from 21 October. A host running either can install a fixed 7.4 build, and its notice will say whether it has.
How to check your PHP version
Log in to WordPress as an administrator and go to Tools, then Site Health, then the Info tab. Open the Server section, and the PHP version is listed there. The PHP settings in your hosting control panel show it too.
Reading the number needs one piece of care. If it shows 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, you have the fix. Any other number does not prove you are exposed, because a patched build can keep an older version number. GoDaddy warned its customers that “your site can still show a version like 8.5.11 while including the fix”, and Namecheap said the same. The way to know for certain is to ask your host.
Who fixes it depends on how your site is hosted
We read the notices of ten hosts, published between 21 and 23 October. The pattern is consistent. Where the host runs the server, the host fixed it. Where the customer runs the server, the customer has to.
| Host | What it said | Date |
|---|---|---|
| WP Engine | ”All customer sites are running fully patched versions of PHP.” | 22 Oct |
| Kinsta | ”We deployed security updates for PHP 7.4 through PHP 8.5.” | 23 Oct |
| WordPress.com (Automattic) | “There’s nothing you need to do to keep your site safe from these vulnerabilities.” | 21 Oct |
| SiteGround | Fixes applied on all servers. “There’s nothing you need to do.” | 21 Oct |
| GoDaddy | Managed WordPress and web hosting patched. “If you manage your own server or VPS, you’ll need to apply the PHP update yourself.” | 22 Oct |
| Hostinger | ”PHP’s fix is now installed on all Hostinger hosting servers except VPS.” | 22 Oct |
| Bluehost | ”The majority of these platforms are now up-to-date.” VPS and dedicated customers told to watch for emails. | 22 Oct |
| Namecheap | ”All PHP versions offered on our Shared Hosting servers are patched against these vulnerabilities.” | 22 Oct |
| Fasthosts | Rolling the updates out across its platforms, with no action needed. “Anyone running PHP themselves, for example on a VPS or Dedicated Server, should install the update.” | 22 Oct |
| 34SP.com | WordPress hosting on patched PHP. Business and Universal Hosting “now being upgraded to a patched version PHP 8.3”. | 23 Oct |
If your host is not listed, look for a notice on its blog or status page dated 21 October or later. Every host in the table published one within three days.
Managed WordPress hosting is the simplest case. The host runs the server and patches it. WP Engine, WordPress.com and SiteGround all told customers they had nothing to do.
Ordinary shared hosting, where you pay a monthly fee and log in to a control panel, works the same way. The shared hosts above patched within a day or two, old PHP versions included. Your part is to check the version and read your host’s notice.
A server your developer or agency set up is where sites get left behind. A virtual private server (VPS) hands control of the server to the customer, and with it the job of updating PHP. GoDaddy, Hostinger and Fasthosts all said so in their notices, and DigitalOcean told customers who installed PHP on their own servers to update it. If a developer built your site on one and has since moved on, nobody is updating PHP unless you arrange it. On a server still running Ubuntu 20.04, for example, the fixed PHP 7.4 package is only available through Ubuntu Pro, Canonical’s extended support subscription.
Website builders need nothing from you. If your site is on Wix, Squarespace or Shopify, the platform runs the servers and there is no PHP setting for you to change.
Why the speed of the fix matters
The attempt Amazon recorded four days before the fix fits a wider pattern. Google’s Mandiant, which investigates breaches for a living, estimated in its M-Trends 2026 report, published on 23 March 2026, that the mean time to exploit a vulnerability is now minus seven days. In its words, “exploitation is routinely occurring before a patch is even released.”
Few UK businesses check how quickly their suppliers act. The government’s Cyber Security Breaches Survey, published on 30 April 2026, found that 15% of UK businesses formally review the cyber risks from their immediate suppliers. Only 34% have a policy of applying security updates within 14 days, which is also the limit the NCSC recommends for fixes to critical or high-risk vulnerabilities in its guide to choosing a managed service provider. On 21 October, WordPress.com and SiteGround had the fix in place the same day.
Questions worth asking whoever runs your server
If you are not sure your site is covered, four questions will settle it. Your web host or developer should be able to answer them in a short email.
1. Who is responsible for updating PHP on our server? If the answer is that you are, it is better to know now than at the next flaw.
2. Has the PHP2Shell fix been installed, and when? For PHP 7.4, 8.0 or 8.1, ask specifically whether the patched build is in place, since a patched build can keep the old version number.
3. How quickly do you apply critical security fixes, and how will you tell us? A useful answer has a number of days and a named person in it.
4. If we are on PHP older than 8.2, what is the plan to move? WordPress recommends PHP 8.3 or later, and the PHP project no longer issues security fixes for versions before 8.2.
PHP2Shell was not the only security story this month to reach businesses through a supplier. Our overview of October’s supply chain attacks covers the others, including the ConnectWise backup breach, with five questions that work for any supplier. We have also written about who owns the accounts behind your website.
What to do now
Check your PHP version under Tools, then Site Health, then Info, then Server.
Read your host’s notice. Every host in our table published one between 21 and 23 October.
If your site is on a VPS, or you are not sure who runs the server, send the four questions to whoever built it.
Plan a move off PHP 7.4, 8.0 or 8.1 if your site is still on one. Test your plugins on a copy of the site first.
Frequently asked questions
Is my WordPress site affected by PHP2Shell?
WordPress runs on PHP, so the server it runs on needs the fix. WordPress itself does not need updating. The ten hosts we checked said between 21 and 23 October that they had patched, or were patching, the servers they run. If your site runs on a VPS or a server your developer manages, someone has to install it on that server.
Do I need to update WordPress or my plugins?
No. WordPress.org said: “No WordPress update is required or planned for these issues.” The flaws are in PHP, which runs underneath WordPress.
How do I check my PHP version in WordPress?
Log in as an administrator, go to Tools, then Site Health, then the Info tab, and open the Server section. A version of 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later includes the fix. Other numbers can still include it, as GoDaddy and Namecheap warned, so ask your host.
My site runs PHP 7.4. Is it safe?
That depends on your host. The PHP project issued only source backports for 7.4, not a finished release. Kinsta says it deployed security updates for PHP 7.4 through 8.5, and cPanel and CloudLinux shipped patched 7.4 packages for the hosts that use them, so ask yours which build it runs. PHP 7.4 stopped receiving security updates from the PHP project on 28 November 2022, so moving to PHP 8.3 is worth planning.
Is there a third PHP flaw?
On 23 October the PHP project published an informational advisory for a further flaw, CVE-2026-115560. It affects only an unusual setup, where a site switches PHP’s session serialiser at runtime while session upload progress is still enabled. PHP’s interim advice is to set session.upload_progress.enabled=0 until the next regular bugfix release, when it will publish a full advisory.
Flux Dynamics is a fractional CTO who builds. If your site runs on a server nobody is sure is theirs to update, tell us what you run and we will help you put a name against it.