Correct as of 15:00 BST, 22 October 2026.
If you run a WordPress website, here’s the short version. Two critical security flaws, known together as PHP2Shell, have been found in PHP, the programming language that runs underneath WordPress. They are not in WordPress itself, so updating WordPress, your theme or your plugins won’t fix them. The fix is a PHP update applied on the server, usually by your hosting provider. Fixed versions are out and attacks are being attempted, so today’s job is to confirm with whoever runs your hosting that the PHP version serving your site has been patched.
What’s happened?
On 20 October the PHP security team gave advance notice of two critical vulnerabilities, both scored 9.2 out of 10 under version 4 of the Common Vulnerability Scoring System (CVSS). The fixes followed on 21 October, with an advisory confirming that CVE-2026-109618 and CVE-2026-109619 can allow unauthenticated remote code execution. In plain English, an attacker without a login could run their own code on a vulnerable web server.
PHP says every PHP installation serving web requests is at risk, and it rates servers running PHP as an Apache module (mod_php) as the highest risk. Both flaws come down to how PHP tidies up when a request goes wrong, leaving behind half-built or stale data that a later request can misuse.
The UK’s National Cyber Security Centre (NCSC), CERT-EU and NHS England have all issued guidance with a consistent message: update now, and if you can’t, consider taking affected systems offline until you can.
Is anyone exploiting it?
Reports vary. Amazon’s threat intelligence team says it saw an exploitation attempt against its honeypot sensors on 17 October, four days before public disclosure, and now describes it as broadly exploited in the wild. watchTowr and Cloudflare have also reported attack attempts, and researchers including Sansec have demonstrated working attacks against popular PHP applications, WordPress among them.
We haven’t seen confirmed data on how many sites have been compromised; Amazon says it’s unclear whether the attempts it saw would have succeeded. So the fair position is this: attacks are being attempted, working exploits exist, and an unpatched server should be treated as at real risk.
Why updating WordPress won’t fix this
Think about the laptop on your desk. Microsoft Word is where the real work happens, but it runs on Windows. If Microsoft finds a serious flaw in Windows, updating Word won’t fix it; the fix is a Windows update, and in most organisations your IT team applies it. WordPress and PHP work the same way. WordPress is what your site is built on and what your team works in every day, but it runs on PHP, and PHP2Shell is a flaw in that layer.
That’s why the WordPress Security Team has said no WordPress update is required or planned for these issues. The fix is a patched version of PHP running on the server. On managed WordPress hosting, that’s your host’s job; on servers your IT team or an agency runs, it’s theirs.
The fixed versions, and the older-version question
PHP has released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, one for each supported branch. Running one of those, or later, is the fix.
PHP 8.1 and earlier are end of life, so the PHP project isn’t shipping releases for them. Its security team has published minimal source code fixes for 7.4, 8.0 and 8.1, and some Linux distributions and hosts provide their own patched builds; WP Engine, for example, has patched its extended-support PHP 7.4. PHP’s advisory doesn’t spell out exactly which older versions are affected, but independent researchers such as Tenable trace the vulnerable code back to PHP 5.4.
A host-applied patch may protect an older version today, but it isn’t a long-term plan; PHP’s advice is to check with your vendor or upgrade. Note that PHP 8.2 itself reaches end of life on 31 December 2026.
Why checking the running version matters
A nerdy detail that matters more than it sounds: a server can have more than one PHP installed. As Exploitr, a South Wales security consultancy, points out, the version a command-line check reports isn’t necessarily the one serving your website. And a patched package protects nothing until the PHP processes behind your site have been restarted. “We’ve installed the update” and “your site is running the patched version” are different sentences.
To check, go to Tools, then Site Health, then Info in your WordPress dashboard, and open the Server section to see which PHP version WordPress runs on.
Firewall rules and configuration changes, which many hosts used while patches rolled out, reduce exposure but, as PHP makes clear, don’t make an installation safe. Only the update does that.
Five questions to ask your host or IT team
- Which PHP version is serving our website now, and is it a fixed release or vendor-patched build?
- When was it patched, and have the PHP processes been restarted?
- Does that cover every environment, including staging and development?
- If we’re on PHP 8.1 or older, what is protecting us today, and when are we moving to a supported version?
- Have you checked for signs of compromise from before the patch, given attempts were seen from 17 October?
What we’ve done for our clients
We’ve checked the PHP version running on every client site we look after and confirmed each one is on a patched build. All of them run supported PHP versions (8.2 or newer), so none are relying on end-of-life workarounds.
Most of the sites we look after are hosted on WP Engine, which we’ve partnered with for around a decade. WP Engine says it put protective measures in place before the fixes were published, and its status page shows patched PHP versions rolled out across its platform by the early hours of 22 October (UK time). We’ve also confirmed our clients’ position with WP Engine directly, worked with other hosts and IT teams to confirm the same, and been in touch with clients to let them know where they stand.
What WordPress.org, Automattic and other hosts have said
WordPress.org says no WordPress update is coming (or required) and site owners should check with their host and update PHP. Automattic says sites on WordPress.com, WordPress VIP, WP Cloud and Pressable are already protected, with nothing for customers to do.
Hostinger and Kinsta report patched PHP rolling out, and SiteGround reports server-level mitigations across all its servers, each saying no action is needed on managed plans. GoDaddy reports Managed Hosting for WordPress fully patched, with its Web Hosting and Windows Hosting relying on mitigations while it waits for patched packages. On a self-managed server or VPS, the update is yours to apply. Positions are changing by the hour, so check your host’s own status page.
Serious, but manageable
A 9.2-rated flaw that can be attacked without a login deserves action today, not next week. It isn’t a reason to panic. The fix exists, and for most WordPress sites on well-run managed hosting, it’s already in place. The job now is to make sure, not assume.
So, today: send those five questions to your host or IT team, check the PHP version in Site Health, and if you’re running anything older than PHP 8.2, start planning the move to a supported version.
