PHP2Shell: what the critical PHP vulnerabilities mean for your organisation

On 21 October 2026 the PHP project released emergency updates for two critical vulnerabilities in PHP itself. Researchers have named the pair "PHP2Shell". Both allow an attacker with no login to run their own code on a server, both are rated 9.2 out of 10, and within days CISA, the US cyber agency, confirmed they were being exploited. PHP runs a large share of the web, including WordPress, Drupal, Magento, Moodle and many internal tools, so most organisations will have it somewhere, even if their main website moved off it years ago.

This guide explains what the vulnerabilities are, which systems are affected, why the configuration workarounds circulating online are not enough, and what to do this week.

In short: PHP2Shell is two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 (CVSS v4.0) and each able to give an attacker with no login control of a web server. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, and CISA confirmed active exploitation on 26 October. No configuration change fully protects an unpatched server. Update PHP, restart every PHP worker, and check that hosting providers and suppliers have done the same. Facts in this article are correct as of 27 October 2026.

What are CVE-2026-109618 and CVE-2026-109619?

They are two memory-handling flaws in the PHP runtime, the engine that executes PHP code on a web server. Neither is a bug in a website's own code or in a particular plugin, which is why updating your CMS does not fix them.

• •CVE-2026-109618 (out-of-memory corruption). When PHP runs out of memory while setting up a request, it can abandon processing with request data only partly built. The cleanup that follows then treats that half-built data as valid. A specially crafted multipart request can trigger this even when it looks small enough to be accepted.
• •CVE-2026-109619 (stale state between requests). Data belonging to one request can survive after its memory has been freed, and a later request handled by the same PHP worker can read it. Session upload progress, which is switched on by default, is one route an attacker can use, without the application ever starting a session.

Both carry a CVSS v4.0 score of 9.2 (critical) and, in the right conditions, lead to unauthenticated remote code execution: an attacker takes control of the web server.

Is PHP2Shell being exploited?

Yes. watchTowr reports seeing exploitation in its honeypot network from 21 October, the day the fixes were published. On 26 October CISA added both CVEs to its Known Exploited Vulnerabilities catalogue, which is reserved for flaws with evidence of active exploitation. The PHP project itself says a working exploit against Apache mod_php was demonstrated during its research.

As of 22 October, Rapid7 found that the public proof-of-concept code it reviewed worked only against specific combinations of operating system, PHP version and web server, and none appeared broadly reliable. Do not wait for that to change. Exploits improve quickly once the patches can be compared with the vulnerable code, and the absence of entries in your logs does not prove a server was not targeted.

Which systems are affected?

Every PHP installation that serves web requests and has not been updated to a fixed release. That includes Apache with mod_php, PHP-FPM (typically behind Nginx), php-cgi, LiteSpeed and FrankenPHP. The PHP project rates Apache mod_php as the highest risk, because exploitation can happen before any application code runs.

The fixed releases, all published on 21 October 2026, are:

• •PHP 8.5: update to 8.5.12.
• •PHP 8.4: update to 8.4.27.
• •PHP 8.3: update to 8.3.36.
• •PHP 8.2: update to 8.2.35. Note that 8.2 reaches end of life on 31 December 2026, so plan the next upgrade now.
• •PHP 8.1 and older: no release from the PHP project, which no longer supports these branches. Some Linux distributions and long-term support vendors still maintain them and have shipped backported fixes, so check with your vendor. The PHP project has also published minimal source backports for 7.4, 8.0 and 8.1.

watchTowr reports that older branches, including PHP 5, are also affected. If a system runs a PHP version that neither the PHP project nor your operating system vendor still supports, there is no fix to apply, and moving it to a supported version should now come first.

Where is PHP likely to be running in your organisation?

PHP is often present in systems nobody thinks of as "PHP". These widely used applications are written in PHP, so if you run any of them on your own servers, the server's PHP needs the 21 October update:

1. •Websites and content management: WordPress, Drupal, Joomla and MediaWiki.
2. •E-commerce: Magento (Adobe Commerce) and WooCommerce.
3. •Learning platforms: Moodle, widely used in education and corporate training.
4. •File sharing and collaboration: Nextcloud.
5. •Webmail: Roundcube.
6. •Helpdesk and IT asset management: GLPI.
7. •CRM and marketing: SuiteCRM and Mautic.
8. •Monitoring and analytics: the Zabbix web interface and Matomo.
9. •Database administration: phpMyAdmin, which should never be exposed to the internet in any case.
10. •Hosting control panels and appliances that bundle their own copy of PHP, which may only be updated through the vendor's own release.

Where one of these is provided as a hosted service, the provider is responsible for updating PHP, but you should still ask for confirmation (step 4 below).

Why aren't the configuration workarounds enough?

Because each workaround closes only one known route to the flaws, and the PHP project is explicit that none of them make an installation safe. Several are circulating, most prominently disabling session.upload_progress. Here is what each one does and does not cover:

• •Disabling session upload progress blocks the confirmed session routes for CVE-2026-109619, but not other variants, and does nothing for the out-of-memory flaw. On PHP 8.5, turning off fatal_error_backtraces likewise blocks only one confirmed route.
• •Removing the memory limit at the server level reduces the out-of-memory path, but an underlying allocation failure can still reach the vulnerable code.
• •Lowering post_max_size and limiting request size at the web server or proxy narrows what an attacker can send, without closing the flaw.
• •Setting these values from within the application, through ini_set() or a .user.ini file, is too late to help at all. They must be set in php.ini or the server configuration, followed by a restart of every PHP worker.
• •Hiding errors with display_errors or error_reporting does nothing for this issue.

Treat workarounds as a way to buy a few days on a system you cannot update yet, not as a fix. A web application firewall may filter some attack traffic in the meantime, on the same terms.

What should we do this week?

Find every system that runs PHP, update it, and confirm nothing was compromised before the update. In practice that means five steps:

1. •Build an inventory of everything that runs PHP. Start with internet-facing systems: the public website, marketing microsites, client portals, webmail, helpdesk and booking tools, and any staging or legacy servers that are still reachable. Then cover internal tools and appliances that embed PHP. Forgotten hosting is the usual way in, so check DNS records for hosts nobody owns any more.
2. •Patch to a fixed release, then restart every PHP worker. Running workers keep the old, vulnerable code in memory until they restart. On Linux, use your distribution's packages, which may carry the fix under the original version number, so confirm against the vendor advisory. The PHP project also suggests keeping session.upload_progress.enabled=0 after patching, until its next regular release, to close a separate and much less likely issue (CVE-2026-115560) that depends on an unusual application setup.
3. •Take what you cannot patch offline, or restrict access to it. CISA's advice is to take unpatchable PHP systems offline until they are updated. Where that is not possible, limit access to known IP addresses or put the system behind a VPN while the upgrade is planned.
4. •Ask your hosting providers and suppliers for confirmation. If a provider runs PHP for you (managed WordPress, an agency-hosted site, a SaaS platform built on PHP), ask in writing whether they have applied the 21 October fixes and restarted their workers. A clear yes, with a date, is what you are looking for.
5. •Look for signs of prior compromise. Exploitation has been observed since the day of disclosure, so a system patched afterwards may already have been compromised. CISA advises watching for PHP worker processes launching shells or downloading tools. Unexpected files in web directories and new administrator accounts are also worth checking. If anything looks wrong, treat it as an incident rather than a patching task.

What does this mean for Cyber Essentials?

In-scope systems running PHP must be updated by 4 November 2026 to meet the Cyber Essentials patching rule. Cyber Essentials requires updates that fix vulnerabilities the vendor rates as critical or high risk, or that score 7 or above under CVSS v3, to be installed within 14 days of release. PHP rates both flaws as critical and the fixes were released on 21 October 2026, which sets that 14-day deadline. In-scope software must also be supported, so a PHP version that neither the PHP project nor your operating system vendor still maintains has to be upgraded, or removed from scope. If your certification is up for renewal, this is the kind of finding an assessor will look for. Our guide to why Cyber Essentials applications fail covers the patching rule in more detail.

Why systems nobody knows about are the biggest risk

With PHP2Shell, the fix was published and exploitation was observed on the same day. The organisations at most risk are not the ones that lack a patching process. They are the ones that do not know where PHP is running, because the system was set up by a former employee, an agency or a supplier and never entered an asset register. A patch cycle can only cover the assets it knows about.

This is the gap that managed security and continuous vulnerability management are designed to close: an accurate, current inventory, monitoring for exploitation, and a single point of accountability for making sure the update reaches every system. We covered why speed of remediation matters more than speed of detection in the 29-minute problem. Where you need independent confirmation that an exposed system is not exploitable, penetration testing provides evidence you can show your board and your auditors.

If you are not sure where PHP is running in your estate, or want a second opinion on your response, book a call and we will tell you the smallest sensible next step.

Further reading

• •Security advisory: critical remote code execution vulnerabilities, The PHP Group
• •Informational advisory: session upload progress, The PHP Group
• •Critical vulnerabilities in PHP require immediate patching, CISA
• •CVE-2026-109618 and CVE-2026-109619: technical analysis, Rapid7
• •PHP2Shell FAQ and exploitation observations, watchTowr
• •GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), php-src security advisories
• •Cyber Essentials: requirements for IT infrastructure v3.3, NCSC