Critical PHP vulnerability (PHP2Shell): a step-by-step checklist for small businesses.

What has happened

PHP2Shell is the nickname for two critical flaws in PHP, the language that runs most small business websites. Details leaked on 20 October 2026, before the planned disclosure, and fixed PHP versions were released on 21 October. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and the PHP security team rates both Critical, CVSS v4.0 9.2.

• Who is affected: Wiz Research, via Patchstack, found every PHP version from 5.4 onwards is affected. The NCSC says: "Organisations using any version of PHP are affected."
• What an attacker can do: an unauthenticated web request can lead to remote code execution on the server. Wiz demonstrated it against the latest WordPress, Drupal and Joomla, and showed that memory holding passwords, tokens and API keys could be read even without code execution.
• What fixes it: only updating PHP. Updating WordPress, plugins or your theme does not. It applies to every common set-up: PHP-FPM, Apache mod_php (the highest risk), php-cgi, FrankenPHP and LiteSpeed.
• Is it being used? Cloudflare reported early exploitation attempts on 21 October. Patchstack's timeline noted probing that afternoon, with no hard evidence of breaches yet, and said it expected that to change.

In plain English: one flaw lets an out-of-memory error interrupt PHP while it is still setting up a request's data, so the clean-up treats invalid data as valid. The other lets data from one request survive after its memory is freed, so a later request handled by the same PHP worker may use it.

Step 1: check your PHP version

You need the exact version number, such as 8.4.27, not just "8.4".

• WordPress: go to Tools, then Site Health, open the Info tab and expand Server. The PHP version is listed there.
• Plesk: Websites & Domains, then the domain, then PHP Settings (or PHP version).
• cPanel: "Select PHP Version" or "MultiPHP Manager".
• Anything else: ask your host. A host should be able to confirm the exact version for each site.

Then compare it with this table:

Some Linux distributions and long-term support vendors ship backported fixes for older versions, and the PHP team published minimal backports for 7.4, 8.0 and 8.1 for people who build PHP from source. Check every site on your account, because different domains can run different versions.

Step 2: ask your host (email to copy)

On most shared and managed hosting, the host controls the PHP version. Ask them in writing and keep the reply. Copy and paste this, filling in the parts in square brackets:

Subject: PHP2Shell (CVE-2026-109618 and CVE-2026-109619): please confirm our PHP version

Hello,

Following the NCSC alert of 21 October 2026 about critical PHP vulnerabilities, please can you confirm the following for [your domain] and any other sites on our account:

1. The exact PHP version each site runs (for example 8.4.27, not just 8.4), for the website and for the command line used by scheduled tasks.
2. Whether it has been updated to a fixed release (8.5.12, 8.4.27, 8.3.36 or 8.2.35, or later), and when. If not yet, when it will be.
3. If we are on PHP 8.1 or older, whether you have applied a vendor-patched build or a mitigation such as Hosted Power's open-source php_uploadprogress_guard extension, and whether our site sits behind Cloudflare's proxy.
4. Whether you have applied the PHP team's temporary mitigations or any firewall rules while the update is pending.
5. Whether you have seen signs of attack on our account, such as repeated 500 errors, memory-limit errors or unexplained PHP worker restarts.

Thank you.

[Your name], [business name], [phone number]

A host should be able to give you an exact version number. If the answer is vague, or they can neither fix nor protect your PHP version, we can check, update or protect the site for you.

Step 3: if you are staying on PHP 8.1 or older

You do not have to move off older PHP, but there is no official fixed release for 8.1, 8.0, 7.x or 5.6, so you are relying on mitigations. Be clear that is what they are. The main options:

• A vendor-patched build from a Linux distribution or long-term support vendor, or the PHP team's minimal backports for 7.4, 8.0 and 8.1 for people who build PHP from source.
• php_uploadprogress_guard, an open-source (MIT) extension from Hosted Power. It closes the multipart upload path of both flaws on unpatched PHP 5.6 through 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. Its own README says the patched release is the only complete mitigation, and it does not cover application-level out-of-memory errors or per-site overrides set in .htaccess or PHP_VALUE.
• Cloudflare's proxy in front of the site (see below).

If your host cannot offer any of this, dijihost, dijitul's managed UK hosting, still offers PHP 5.6, 7.x, 8.0 and 8.1 and protects them in layers: Cloudflare's WAF, a security extension that closes the known attack path, hardened PHP settings, isolation of each site and monitoring. On end-of-life PHP these are mitigations, not an official fix.

Upgrading to 8.2 or later is still the best long-term option if you want it. Our guide to PHP end of life explains how to test an upgrade without breaking the site.

What the NCSC advises

The NCSC published an alert about the critical PHP security issue on 21 October 2026. In summary, it advises organisations to:

1. Find every PHP install, internet-facing ones 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. 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.

For a small business, "every PHP install" means more than the main website. Think of old microsites, a staging copy, a booking system, an intranet, or a forgotten site still running on the same hosting account.

Temporary mitigations (for hosts and developers)

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; setting post_max_size to 8M (no uploads) or 32M (with uploads), with upload_max_filesize below it and request size limits at the web server or proxy; turning off session.upload_progress.enabled at server or pool level, then restarting all PHP workers; and on PHP 8.5, setting fatal_error_backtraces to 0. The PHP team is clear that these "do not make an installation safe". They buy time. Updating PHP is the fix.

What about Cloudflare?

Cloudflare deployed emergency WAF rules at 03:02 UTC on 21 October, on all plans with the WAF, including Free. Its CTO called them "a stopgap only", and Cloudflare says customers should patch PHP even with the WAF in place. The rules only protect traffic that goes through Cloudflare's proxy (the orange cloud). A site whose DNS is on Cloudflare but not proxied, or that can be reached directly at its server IP address, is not shielded.

Signs your site may have been targeted

Watch for these in your server logs, or ask your host to check. None of them proves an attack either way, but each is worth looking into:

• Unusual multipart requests (the kind used for form uploads) followed by memory-limit errors or repeated HTTP 500 errors.
• Oversized or malformed PHPSESSID cookies.
• Unexplained PHP worker restarts.

Avoid unofficial "fix" plugins and code snippets copied from forums or social media. A plugin runs on top of PHP and cannot fix a flaw in PHP itself. Only updating PHP does.

If you think the site was compromised

1. Treat the server as possibly compromised. Do not wait for proof.
2. Take a full copy of files, database and logs before changing anything. It is evidence, and a fallback.
3. Update PHP to a fixed release or, on older PHP, make sure a patched build or mitigation is in place.
4. Check for backdoors: recently changed files, PHP files in upload folders, administrator accounts you did not create, and scheduled tasks you did not set up. Restoring an old backup is not enough on its own if a backdoor came with it.
5. Rotate every secret the server holds: database password, admin and hosting logins, SFTP, API keys, payment gateway and email (SMTP) credentials, and WordPress salts. Wiz showed that memory holding these could be read even without code execution.
6. Consider your data duties. If personal data may have been exposed, UK GDPR may require you to report it to the ICO within 72 hours of becoming aware.

Our hacked website repair page explains how we clean a site, and the guide to signs your website has been hacked covers the wider warning signs.

Getting help from dijitul

If you would rather hand it over, dijitul support checks your exact PHP version, updates or protects it, checks the site works on the new version, looks for signs of tampering and rotates credentials where needed. We work on sites hosted with any provider, at £45 an hour + VAT, or from the included hours on our Business and Complete support plans. See PHP2Shell check and PHP update or get in touch.

Sources

• NCSC: alert of 21 October 2026
• Cloudflare: PHP vulnerabilities and WAF protection
• Patchstack: PHP vulnerability alert and timeline
• Hosted Power: php_uploadprogress_guard on GitHub

Related