PHP2Shell: what UK businesses should check after the October 2026 PHP fixes

Last updated: 29 October 2026. Facts checked against php.net, the National Cyber Security Centre (NCSC), CISA and WordPress.org on 29 October 2026. We will update this page as the advisories change.

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, which "can allow unauthenticated remote code execution" [1]. Put simply, a request from anyone on the internet could, in the right conditions, run its own code on a server that hosts a PHP website. Five days later the US Cybersecurity and Infrastructure Security Agency (CISA) added both to its Known Exploited Vulnerabilities catalogue, its list of flaws that attackers are already using [2][3].

The fix is an update, and many hosting providers will already have applied it. The work this week is to confirm that with evidence, and to recognise when a patch is not the end of the job. It is the practical side of who owns patching for software you self-host or inherit.

What PHP2Shell is, and which versions fix it

PHP2Shell is the name for two flaws in the PHP runtime, the engine underneath WordPress and every other PHP application. One, CVE-2026-109618, lies in how PHP handles running out of memory; the other, CVE-2026-109619, lets internal state from one request survive into a later request on the same worker [1]. The PHP project rated both 9.2 under version 4.0 of the Common Vulnerability Scoring System (CVSS) [4].

The name came from the security firm Wiz, not the PHP project. Its researchers explain that "php2shell is the name we gave the combined exploit script" used to demonstrate remote code execution on WordPress, Drupal and Joomla [5], and CISA now uses the name too [3].

The PHP advisory says who is exposed: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php" [1]. The fixed releases, and how long each branch receives security fixes, are below [1][6][7].

PHP branch	First fixed release	Security support ends
8.5	8.5.12	31 December 2029
8.4	8.4.27	31 December 2028
8.3	8.3.36	31 December 2027
8.2	8.2.35	31 December 2026
8.1 and older	No official release	Already ended (8.1 on 31 December 2025)

For PHP 8.1 and older, the PHP project published "minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1" for people who build PHP themselves, and pointed everyone else to their operating system vendor or a supported version [1]. On Windows, php.net reissued its builds on 26 October with a -1 suffix, such as 8.3.36-1, to fix a separate flaw in a bundled library [8].

Exploitation of PHP2Shell began early. The Delft Threat Intelligence Lab at TU Delft logged its first PHP2Shell-like request on its research sensors at 08:37 UTC on 21 October [9], more than five hours before the fixes were published at 14:00 UTC [4]. That is attack traffic, not a count of compromised businesses, but it is why a site left unpatched for even a few days deserves a closer look.

How to check which PHP version your site runs

The PHP version that matters is the one serving your website. There are three reliable ways to find it.

1. Your hosting control panel. WordPress.org notes that "Many web hosts provide this information in your web hosting administration panel" [10].
2. WordPress Site Health. In the WordPress dashboard, go to Tools > Site Health > Info and expand the Server section [10][11].
3. A temporary check file. A developer can upload a one-line file calling PHP's phpversion() function, which "Returns a string containing the version of the currently running PHP parser" [12]. Delete it straight afterwards, because version and configuration details should not be left publicly readable.

Running php -v in a server terminal reports the command-line PHP, and the PHP manual notes "There are quite a few differences between the CLI SAPI and other SAPIs" [13]. In our experience servers often have more than one PHP version installed, so check what the web server runs, not what the shell runs.

On Linux, the version number is not the whole answer either. Distributions backport security fixes into their own packages, which is why Red Hat warns that "just looking at the version number of a package will not tell them if they are vulnerable or not" [14]. Ubuntu 22.04, for example, fixed CVE-2026-109618 in its PHP 8.1 package as version 8.1.2-1ubuntu2.28 [15], a number that looks old but carries the fix. Check the vendor's security notice, or ask your host.

What to ask your hosting provider

Ownership of the PHP runtime decides who has to act. On shared or managed hosting, the provider runs PHP and should already be patching. On a virtual private server or cloud instance that you or a developer manage, nobody will update PHP unless you arrange it. WordPress.org's advice is to "check for updates from your web host and, if necessary, update PHP as soon as possible" [10].

Ask your host these questions, and ask for the answers in writing:

1. Do you manage the PHP runtime for our site, or do we?
2. Has the fix for CVE-2026-109618 and CVE-2026-109619 been applied to the PHP serving our site, and when? Please share the version or package build as evidence.
3. Were the PHP processes restarted after the update?
4. Does every site on our account run a patched version, including staging copies and old subdomains?
5. Are you relying on a firewall rule, and is it in addition to the update or instead of it?
6. Have you seen any signs of exploitation on our server since 20 October?

The restart matters because, in our experience, an updated package does nothing for PHP processes still running the old code. The firewall question matters because hosts may "put web application firewall (WAF) rules in place" [10], while the PHP project says its interim measures "reduce exposure to specific attack paths but do not make an installation safe" [1].

Ask other suppliers too. The NCSC advises organisations to "Continuously monitor for security updates from third-party software vendors, including for appliances and services that may bundle PHP" [16].

Why a WordPress update alone may not patch PHP

WordPress is an application that runs on PHP, and it does not install or update PHP itself. Updating WordPress core, a theme or a plugin changes the application, while PHP2Shell sits in the runtime underneath. WordPress.org's own announcement says the vulnerabilities "are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues" [10].

A WordPress dashboard showing everything up to date therefore says nothing about PHP2Shell. The same is true of Drupal, Joomla and bespoke PHP applications: this fix arrives through the server, not the content management system. Site Health reports the PHP version separately from the WordPress version, which makes it the quickest check [11].

Signs of compromise mean incident response, not just patching

Updating PHP closes the vulnerability. It does not remove anything an attacker installed beforehand, such as a backdoor, a new administrator account or a modified file. The NCSC advises that if you cannot update immediately, you "should assess the system for any evidence of compromise prior to your upgrade or mitigation and look for backdoors installed by an attacker" [16]. Our view is that any server left exposed for several days after 21 October deserves the same check, given how early exploitation began.

Wiz lists investigation signals including "unexpectedly large or malformed PHPSESSID response cookies, unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, and unexplained PHP worker crashes or restarts" [5], and CISA adds "PHP worker processes launching shells or downloading tools" [3]. In our experience a business owner notices simpler signs first: administrator accounts nobody created, files nobody changed, unexpected redirects. Wiz is candid that these signals "do not establish exploitation on their own. Their absence does not establish that a system is unaffected" [5].

If you find anything suspicious, treat it as an incident rather than a maintenance task:

1. Preserve evidence before cleaning up. Keep logs and, where possible, a copy of the server, so you can establish what happened and when. Our write-up of a forensic incident timeline shows what a thorough investigation records.
2. Contain the system. Where a system cannot be updated or mitigated quickly, the NCSC says "you should consider taking the system offline until it can be fully mitigated" [16].
3. Get the right help. The NCSC points organisations without in-house skills to "an NCSC-assured Cyber Incident Response provider" [16], and its Small Business Guide to Response and Recovery covers restoring from backups and changing passwords [17].
4. Rotate what the server knew. Treat database passwords, API keys and other secrets held on the server as exposed, and rotate the machine credentials the server holds.
5. Restore with care. A backup is only safe if it predates the compromise, and the restored system must be patched before it goes back online.
6. Check your reporting duty. If personal data may have been accessed, the UK GDPR requires certain breaches to be reported to the Information Commissioner's Office (ICO) "within 72 hours of becoming aware of the breach, where feasible" [18].

PHP 8.2 reaches end of life on 31 December 2026

PHP 8.2.35 fixes PHP2Shell, but the 8.2 branch has two months of security support left. The PHP project states that "PHP 8.2 reaches end of life on 31 December 2026 and will receive no further security fixes after that date" [19]. After that, the next flaw of this kind would leave an 8.2 site where PHP 8.1 sites stand today.

Moving from PHP 8.2 to a newer branch is a migration, not a patch. The PHP manual publishes a migration guide for each branch, covering backward-incompatible changes and deprecations [20], and older plugins and custom code may need work. Choose the target after checking your dependencies, test it on a staging copy, and agree a release window before the end of December rather than in it. If your PHP comes from an operating system vendor, confirm the vendor's own support dates as well [1].

Plan for the pace, too. Wiz says its researchers used AI models "during discovery, exploit development and patch validation" [5]. In May the NCSC's chief technology officer warned that AI, in skilled hands, is "showing the ability to exploit this technical debt at scale and at pace", and that "patching alone will not always suffice" for technology that is out of support [21]. If nobody in your business owns the PHP version today, give your PHP runtime an owner before the next advisory.

What to check this week

1. List every PHP site and service you run, including staging copies, old subdomains and appliances that bundle PHP.
2. Confirm the version each one runs on the web server and compare it with the fixed releases above.
3. Get written confirmation from your host that the fix is applied and PHP restarted, or arrange the update if you manage the server.
4. Do not count a WordPress update or a firewall rule as the fix. Neither patches PHP.
5. Look for signs of compromise on any server exposed after 21 October, and treat a positive finding as an incident.
6. Put 31 December 2026 in the diary if anything still runs PHP 8.2.

Get a free PHP upgrade assessment

If you would rather an engineer confirmed this for you, our PHP upgrade service starts with a free initial assessment. We confirm who owns your hosting, which PHP versions are actually running, what your vendor has patched and whether anything points to an incident, then quote for any work. Please do not send passwords or server credentials through the form, and if you suspect a compromise, say so, because incident response is scoped separately.

Request a free PHP upgrade assessment

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name given to two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, which the PHP project fixed on 21 October 2026. They can allow unauthenticated remote code execution on servers that run PHP websites. The security firm Wiz coined the name, and CISA lists both flaws as known to be exploited.

Which PHP versions fix PHP2Shell?

The first fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, published on 21 October 2026. PHP 8.1 and older received no official release, only source backports for people who build PHP themselves. Linux distributions often ship the fix under their own version numbers, so check your vendor's security notice as well.

How do I check what version of PHP my website uses?

Check your hosting control panel, or in WordPress go to Tools > Site Health > Info and expand the Server section. A developer can also call phpversion() from a temporary file and delete it afterwards. Running php -v in a terminal shows the command-line PHP, which can differ from the version your web server uses.

Does updating WordPress update PHP?

No. WordPress runs on PHP but does not update it. PHP is part of the server, managed by your host or by whoever runs the server. WordPress.org has confirmed that no WordPress update is required or planned for these vulnerabilities, so the fix has to come from a PHP update applied to the server itself.

How can I tell if my website has been compromised?

Look for administrator accounts nobody created, files nobody changed, unexpected redirects, repeated server errors and unexplained PHP crashes or restarts. The absence of these signs does not prove a site is clean, because these attacks can leave little trace in application logs. If anything looks wrong, preserve the logs and get incident response help before cleaning up.

Is PHP 8.2 still supported?

PHP 8.2 receives security fixes until 31 December 2026, and the PHP project has said it will receive no further security fixes after that date. Sites on 8.2 should apply 8.2.35 now, then plan a move to a newer supported branch, testing compatibility on a staging copy well before the end of the year.

Sources

1. PHP Group, "Security advisory: Critical remote code execution vulnerabilities, update now", 21 October 2026. https://www.php.net/archive/2026.php#2026-10-21-5
2. CISA, "Known Exploited Vulnerabilities Catalog", CVE-2026-109618 and CVE-2026-109619 added 26 October 2026 (accessed 29 October 2026). https://www.cisa.gov/known-exploited-vulnerabilities-catalog
3. CISA, "Critical Vulnerabilities in PHP Require Immediate Patching", 21 October 2026, revised 26 October 2026. https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
4. PHP Group, "Upcoming Critical PHP Security Release", 20 October 2026. https://www.php.net/archive/2026.php#2026-10-20-1
5. Wiz, "PHP2Shell: AI uncovers critical vulnerabilities in the backbone of the web" (accessed 29 October 2026). https://php2shell.com
6. PHP Group, "Supported Versions" (accessed 29 October 2026). https://www.php.net/supported-versions.php
7. PHP Group, "Unsupported Branches" (accessed 29 October 2026). https://www.php.net/eol.php
8. PHP Group, "Updated PHP Windows builds for Brotli security fix", 26 October 2026. https://www.php.net/archive/2026.php#2026-10-26-1
9. Delft Threat Intelligence Lab, TU Delft, "PHP2Shell in the Wild: live CVE-2026-109618 / CVE-2026-109619 exploitation data" (data as at 29 October 2026). https://php2shell.delftintellab.com/
10. WordPress.org News, "Critical PHP Security Release", 21 October 2026. https://wordpress.org/news/2026/10/critical-php-security-release/
11. WordPress.org, "Get a faster, more secure website: update your PHP today" (accessed 29 October 2026). https://wordpress.org/support/update-php/
12. PHP Manual, "phpversion" (accessed 29 October 2026). https://www.php.net/phpversion
13. PHP Manual, "Command line usage" (accessed 29 October 2026). https://www.php.net/manual/en/features.commandline.php
14. Red Hat, "Security Backporting Practice" (accessed 29 October 2026). https://access.redhat.com/security/updates/backporting
15. Ubuntu, "CVE-2026-109618" security notice (accessed 29 October 2026). https://ubuntu.com/security/CVE-2026-109618
16. National Cyber Security Centre, "Critical security issue affecting PHP", 21 October 2026. https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
17. National Cyber Security Centre, "Small Business Guide: Response & Recovery", Step 3: Resolve the incident (accessed 29 October 2026). https://www.ncsc.gov.uk/collection/small-business-guidance--response-and-recovery/step-3--resolve-the-incident
18. Information Commissioner's Office, "Personal data breaches: a guide" (accessed 29 October 2026). https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/
19. PHP Group, "PHP 8.2.35 Released!", 21 October 2026. https://www.php.net/archive/2026.php#2026-10-21-1
20. PHP Manual, "Migrating from PHP 8.2.x to PHP 8.3.x" (accessed 29 October 2026). https://www.php.net/manual/en/migration83.php
21. National Cyber Security Centre, Ollie Whitehouse, "Preparing for a 'vulnerability patch wave'", 1 May 2026. https://www.ncsc.gov.uk/blogs/prepare-for-vulnerability-patch-wave