PHP2Shell: what UK website owners need to do

What PHP2Shell is

PHP2Shell is the nickname for two flaws in PHP, the language that runs WordPress, Drupal, Joomla, most online shops and countless bespoke business systems. They are tracked as CVE-2026-109618 and CVE-2026-109619. The details leaked on 20 October 2026, before the planned disclosure, and the PHP security team rates both Critical, with a CVSS v4.0 score of 9.2.

In plain English:

• CVE-2026-109618: running out of memory can interrupt PHP while it is still setting up the data from a request, and the clean-up then treats half-built data as valid.
• CVE-2026-109619: data from one request can survive after its memory has been freed, and a later request handled by the same PHP worker may use it.

The result is serious. According to Wiz Research, an unauthenticated web request can lead to remote code execution, meaning someone with no login can run their own code on your server. Wiz demonstrated it against the latest WordPress, Drupal and Joomla, and showed that worker memory, which can hold passwords, tokens and API keys, could be read even without running code.

Cloudflare reported early exploitation attempts on 21 October. Patchstack's timeline says its telemetry at 13:57 UTC that day showed probing, with no hard evidence of breaches yet, and that it expected this to change.

Who is affected, and the fixed versions

Wiz Research, reported by Patchstack, found every PHP version from 5.4 onwards is affected. The NCSC puts it more simply: "Organisations using any version of PHP are affected." It applies to every common set-up, including PHP-FPM, Apache mod_php (the highest risk), php-cgi, FrankenPHP and LiteSpeed.

The fixed releases came out on 21 October 2026. For PHP 8.1 and older, some Linux distributions and long-term support vendors ship backported fixes, and the PHP team published minimal backports for 7.4, 8.0 and 8.1 for people who build PHP from source. Otherwise, old PHP relies on mitigations, covered below. Moving to a supported version is the complete fix, if and when that suits your site.

Updating WordPress, plugins, themes or your own code does not fix this. Cloudflare says updating website code or plugins alone does not fix these vulnerabilities. The fix happens on the server.

How to check your PHP version

• WordPress: Tools, then Site Health, then the Info tab, then Server. The PHP version is listed there.
• Plesk: Websites & Domains, then your domain, then PHP Settings (or PHP version).
• cPanel: look for "Select PHP Version" or "MultiPHP Manager".
• Or ask your host. They should be able to confirm the exact version, such as 8.4.27, not just "8.4". The last number is what tells you whether the fix is in.

If your site is on 8.1 or older, do not panic and switch it straight to the newest PHP. Older code often breaks on newer versions in the places you cannot see from the home page, such as forms, logins and checkouts. Read what an unsupported PHP version means first.

Old PHP: what the mitigations are

If your site runs on PHP 8.1 or older, there are still real protections available. None is an official fix, so they work best together:

• A web application firewall, such as Cloudflare's, with the site proxied through it.
• A security extension. Hosted Power's open-source php_uploadprogress_guard closes the multipart upload route used by both flaws on unpatched PHP 5.6 to 8.5. It detaches the session upload-progress callback, uses the patched multipart parser from the official fix, and stops oversized requests with a 413 error before PHP runs out of memory. On patched releases it steps aside. Its own documentation says a patched release is the only complete mitigation, and it does not cover out-of-memory errors inside the application or per-site PHP overrides.
• Hardened PHP settings. The PHP team's temporary mitigations, as reported by Patchstack, include setting memory_limit to -1 where applications cannot override it (with a container or cgroup memory limit instead), limiting post_max_size, upload_max_filesize and request sizes at the web server or proxy, and setting session.upload_progress.enabled to 0 at server or pool level, then restarting all PHP workers. The PHP team says these "do not make an installation safe" on their own.
• Isolation of each site, so one compromised site cannot reach the others.
• Monitoring for the signs listed further down.

Together these make old PHP far harder to attack. Our guide to keeping an old PHP website online safely covers the wider picture.

What to ask your host

Ask by email so the answer is in writing:

1. Which exact PHP version does my site run on right now?
2. If it is 8.2 or later, have you installed the fixed release for that branch?
3. If it is 8.1 or older, what protection is in place: a firewall, a security extension, hardened settings, isolation?
4. Is my site behind a web application firewall such as Cloudflare's, and can the server also be reached directly at its IP address?
5. Are you checking servers for signs of compromise, including backdoors?
6. Will you tell me if you find anything?

A host that answers all six plainly is taking it seriously. A link to a generic help article is an answer of a different kind, and it may be time to look at managed hosting where a person handles this for you.

What the NCSC says to do

The UK's National Cyber Security Centre published an alert on 21 October 2026: critical security issue affecting PHP. In summary, it advises organisations to:

1. Find every PHP install, internet-facing systems first, and not assume newer versions are safe.
2. Update to the latest PHP version, and keep watching for further updates.
3. Apply the PHP team's extra hardening.
4. If you cannot update, apply the PHP team's temporary mitigations, and if you cannot do that either, consider taking the system offline.
5. If a system was not updated straight away, check it for compromise, including backdoors, before or as you update.
6. Watch vendors' products that bundle PHP. NCSC-NL keeps an inventory.

Signs your site may have been targeted

None of these prove anything either way, but they are worth asking your host or developer to look for:

• unusual multipart requests followed by memory-limit errors or repeated HTTP 500 errors
• oversized or malformed PHPSESSID cookies
• PHP workers restarting for no clear reason

If any of these turn up, treat the server as possibly compromised: check for backdoors, and change the passwords, keys and tokens the site holds, such as database passwords, payment gateway keys and email logins. Our guide on what to do if your website has been hacked covers the next steps.

Avoid unofficial "fix" plugins and code snippets copied from forums. The fix and the mitigations happen on the server, not inside your website.

Why Cloudflare is only a stopgap

According to Cloudflare, it deployed emergency firewall rules at 03:02 UTC on 21 October, about nine hours before public disclosure, on all plans with its web application firewall, including the free plan. That is genuinely useful, and it is why sites behind Cloudflare had some cover from the start.

But Cloudflare's CTO called the rules "a stopgap only", and Cloudflare tells customers to patch PHP even with them in place. The rules also only apply to traffic that passes through Cloudflare's proxy, shown as the orange cloud in its dashboard. If your DNS is on Cloudflare but the record is not proxied, or your server can be reached directly at its IP address, an attacker can go round the rules. So a firewall is one layer, not the whole answer.

What dijihost is doing

We have used Cloudflare in front of hosted sites for over a decade, so sites proxied through it were behind Cloudflare's rules from 03:02 UTC on 21 October. On top of that, we are putting the official fixed releases on PHP 8.2 to 8.5, checking every hosted site is proxied through Cloudflare, and checking sites for signs of tampering.

We keep running older PHP (5.6, 7.x, 8.0 and 8.1) for the sites that need it, protected by Cloudflare's firewall, a security extension that closes the known attack path, hardened PHP settings, per-site isolation and monitoring, and a vendor-patched build where one exists. On end-of-life PHP those are mitigations rather than an official fix, and we say so. Upgrading stays an option for when you want it. The work is under way, and customers can ring 01623 650333 to ask about their own site.

See hosting for old PHP sites, protected against PHP2Shell. dijihost Complete Hosting is £1 a day + VAT, with free migration.

Related