PHP2Shell (CVE-2026-109618 and CVE-2026-109619): What Companies Running PHP Should Do Now

A technician with a laptop working on a server rack

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two vulnerabilities that "can allow unauthenticated remote code execution". Put plainly: anyone who can send an HTTP request to your website may be able to run their own code on your server. They need no password, and on some setups the attack works before your application has run a single line. The pair has been named PHP2Shell, and PHP rates both 9.2 (CVSS 4.0, on a scale of 10).

This guide is for the people who have to act on it: owners of PHP websites and online shops, IT managers, and anyone who has a supplier running PHP for them. It was written on 22 October 2026, the day after the release, from the PHP project's own advisories, the guidance of national cyber security agencies and the figures vendors have published. Where the sources disagree, we say so.

The Short Version

Update PHP itself, then restart it. Updating WordPress, Drupal, Laravel or a plugin does not fix this. The flaw is in PHP, underneath your application.
Every PHP installation that serves web requests is in scope, according to PHP: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates Apache with mod_php as the highest risk.
Nearly half of PHP websites run a branch the PHP project no longer releases (our reading of W3Techs data, below). For those, there is no official package to install.
Settings and firewalls buy time, not safety. PHP lists interim measures and says they "do not make an installation safe".
If you cannot patch today, the US, UK and EU agencies give the same advice: take the system off the internet until you can.

What Happened, in Order

19 August 2026. Researchers at Wiz find the first of the flaws, according to their disclosure, and report them to the PHP security team on 24 August. Researchers from several other firms are credited in PHP's advisories as well.
20 October. The CVE numbers leak online two days before the planned disclosure. PHP brings its release forward by a day, to 21 October at 14:00 UTC, and tells everyone to prepare.
21 October, 03:02 UTC. Cloudflare switches on firewall rules for every customer with its WAF, the free plan included. It later reports that it "observed attack traffic targeting our customers" and saw attackers "mutating the attack payload to try to bypass our protections".
21 October, around 14:00 UTC. PHP publishes the fixes and its advisory. The same day, CISA in the US, the UK's NCSC, CERT-EU and a joint statement by the European Commission, ENISA, CERT-EU, Europol and the EU's national CSIRTs all tell organisations to patch immediately.

How Serious Is It?

Three things set this apart from the usual monthly patch.

The attacker needs nothing but a request. No login, and nobody has to click a link. PHP's advisory describes a demonstrated exploit against Apache with mod_php "where an unauthenticated request can trigger the attack before any application code runs". Wiz demonstrated attacks on current WordPress, Drupal and Joomla, and notes that "even a simple 'Hello World' application running on an affected PHP version can be vulnerable". Code run this way has the rights of the web server account, which on most sites can read the application's configuration: the database password, API keys, mail and payment credentials. For the second flaw, CVE-2026-109619, PHP also confirms memory disclosure: data from the server's memory leaking out, even without full code execution.

The installed base is enormous. According to W3Techs, PHP runs 69.3% of the websites whose server-side language is known (figures of 22 October 2026). Palo Alto Networks' Unit 42 counts over 22.6 million exposed instances that are potentially vulnerable, from its own internet scanning, and reports that at least one European government took its website offline as a precaution.

Exploit work is moving fast. CERT-EU reports that initial proofs of concept "have begun to circulate". The security firm watchTowr says its honeypots have recorded exploitation since 21 October. Cloudflare reports attack traffic. And Wiz says its researchers used AI models throughout, so that one researcher did in a week what "would have taken a world-class team months". Attackers adapting an exploit to your PHP version have the same tools.

To be fair to the other side: when CISA published its alert on 21 October, it had not observed exploitation, and neither flaw was yet in its Known Exploited Vulnerabilities catalogue. Red Hat rates the issue "Important" rather than critical, because a standard Red Hat Enterprise Linux server runs PHP-FPM, where exploitation is harder. Harder is not impossible: PHP confirms that one route for the second flaw works on PHP-FPM too. None of this changes what you should do. It only changes how much warning you will get.

Which Version Are You On? The Numbers

W3Techs also publishes which PHP versions websites run, counting the sites that reveal their version. Putting its two tables of 22 October 2026 together:

PHP branch	Share of PHP websites	Fix from the PHP project
8.3, 8.4, 8.5	about 34%	Yes: 8.3.36, 8.4.27, 8.5.12
8.2	about 18%	Yes: 8.2.35. But 8.2 itself reaches end of life on 31 December 2026
8.0, 8.1	about 14%	No release. 8.0 and 8.1: source backport only
7.x	26.9%	No release. 7.4: source backport only; 7.3 and older: nothing
5.x and older	7.8%	Nothing

So about 48% of PHP websites run a branch for which the PHP project publishes no fixed release, and another 18% get their fix now and lose support in ten weeks.

Two caveats. W3Techs sees only the sites that show their version. And a Linux distribution may have patched an old branch itself: Ubuntu has, as you will see below. The version number alone does not tell you whether you are protected. The version of your vendor's package does.

Step 1: Find Every PHP You Run

You cannot patch what you have not listed, and PHP hides well. The UK's NCSC asks organisations to find every PHP system, internet-facing ones first, and adds: "do not limit discovery to outdated PHP versions". The EU joint statement warns that some products "may be affected by these vulnerabilities even if they do not appear to use PHP directly".

Where to look:

Websites and shops: WordPress and WooCommerce, Drupal, Joomla, Magento and Adobe Commerce, Shopware, PrestaShop, TYPO3, and anything built on Laravel or Symfony.
The forgotten ones: campaign microsites, an old language version, staging and test servers reachable from the internet, the webmail or helpdesk someone installed years ago.
Containers: every image built from a php base image carries its own PHP. Updating the host does nothing for it.
Hosting control panels: cPanel, Plesk and similar panels ship their own PHP builds next to the system's. Each version enabled in the panel is a separate thing to update.
Products with PHP inside: appliances, monitoring tools, CRMs, helpdesks and vendor admin interfaces. The Dutch NCSC keeps a public list of such products with their status, supplier by supplier.
Suppliers: your hosting company, your agency, any service where you know PHP is underneath. Ask them in writing which PHP versions run your systems and when they will be patched.

For each one, write down the PHP version, how PHP runs (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, a container), whether it is reachable from the internet, and who is able to patch it.

Step 2: Patch, in the Right Order

Start with whatever is reachable from the internet, and within that, with Apache mod_php setups.

On a supported branch (8.2 to 8.5). Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's package that contains the fix. PHP says Linux distributions received the patches in advance. Confirmed so far:

Ubuntu: fixed packages for every release from 14.04 to 26.10. On 22.04 and later they arrive with normal updates; on 20.04 and older they need an Ubuntu Pro subscription, which is free for up to five machines (Canonical's notice).
Debian: php8.4 8.4.27 for Debian 13 (DSA-6574-1) and php8.2 8.2.35 for Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: Red Hat's security bulletin RHSB-2026-013 lists the packages per release.
The Remi repository, widely used for newer PHP on Red Hat family systems: on 21 October CERT-EU noted it had no release-day packages and advised switching to distribution packages or building from source. Check whether it has caught up before you rely on it.

On PHP 7.4, 8.0 or 8.1. The PHP project publishes no release for these. Its security team made minimal source backports for the three branches, which help if you compile PHP yourself. Otherwise the fix has to come from your vendor (Ubuntu Pro covers PHP 7.4 on Ubuntu 20.04, for example) or from upgrading PHP. CISA's advice for anyone on 8.1 or older who cannot update is blunt: take the system offline until it is patched or upgraded.

On PHP 7.3 or older. Nothing comes from the PHP project. Unless a vendor still patches your build, the choice is an upgrade or taking the system offline.

Restart after updating. Installing a package does not replace the PHP that is already running. Ubuntu's notice puts it plainly: the application "would likely need to be restarted". Restart PHP-FPM, Apache, LiteSpeed or the container on every server. Then check the version the web server actually runs, not only php -v on the command line, which can be a different build.

Containers: rebuild your images from a patched base image and deploy them again. A patched host running an old image is still exposed.

Managed hosting: ask your provider for the date and the version, then check for yourself.

Step 3: If You Cannot Patch Today

PHP's advisory lists interim measures and introduces them with a warning: they "reduce exposure to specific attack paths but do not make an installation safe". In short, for whoever runs your servers:

For CVE-2026-109618: set memory_limit=-1 so the application cannot override it (for example with php_admin_value in the PHP-FPM pool or the Apache configuration); set a low post_max_size (PHP suggests 8M without file uploads, 32M with them); limit request size, field count and multipart parts at the web server or proxy; and use a container or cgroup memory limit, never RLIMIT_AS or RLIMIT_DATA.
For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or the server configuration (not with ini_set() or a .user.ini file) and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0.

Two warnings. The session setting that spread widely on 20 October closes paths of the second flaw only, as a member of PHP's security team pointed out; it does nothing against the first. And memory_limit=-1 removes PHP's own memory cap, so a single heavy request can now exhaust the server. Pair it with the container or cgroup limit.

A web application firewall helps, a little. Cloudflare's rules are on by default for every plan with its WAF, the free one included, and Palo Alto Networks and other vendors have published their own protections. Cloudflare still tells customers to patch PHP "even with WAF protections", and it watched attackers change their payloads to slip past its rules. A WAF also protects only the traffic that passes through it. If your server answers on its own IP address, an attacker can go around it.

If none of this can be done quickly, CISA, CERT-EU, the NCSC and the EU joint statement all point the same way: take the system off the public internet until it is fixed. A maintenance page for a day costs less than a rebuilt server.

Step 4: Check Whether You Were Already Hit

The window opened on 20 October, when the leak began, and attack traffic was reported the next morning. If a system was reachable and unpatched in that window, patching closes the door but does not tell you whether someone came in first. The NCSC asks anyone who could not patch immediately to check for signs of compromise and backdoors.

What to look for, from the published guidance and from ordinary incident practice:

PHP processes doing things PHP never does, such as starting a shell or downloading tools (CISA).
Unusual multipart requests followed by memory limit errors or repeated HTTP 500 responses, PHP workers restarting for no clear reason, and unusually large or malformed PHPSESSID cookies in responses (Wiz).
New or changed PHP files in upload folders, cache folders or the web root, new administrator accounts in your CMS, and scheduled tasks nobody created.

Clean logs are not proof. PHP's advisory for the second flaw warns about exactly that, and Wiz notes that application logs may hold little context.

If you find something, treat it as an incident, not a patching job. Isolate the server, keep the evidence, bring in an incident response provider, and change every secret the web server could read: database passwords, API keys, payment and mail credentials, signing keys. Because the second flaw can disclose memory, consider rotating the most sensitive of those secrets on any server that was exposed and unpatched for days, even without signs of intrusion.

Step 5: What You May Have to Report

A vulnerability on its own is not a reportable incident. An exploited one may be.

NIS2: if your organisation is covered and a compromise is a significant incident, the early warning to your national CSIRT is due within 24 hours. See our NIS2 guide.
GDPR: if personal data was accessed, the supervisory authority must be notified within 72 hours of you becoming aware of the breach, unless it is unlikely to put people at risk. See our GDPR guide.
Cyber Resilience Act: if you sell software or a device with PHP inside, you are its manufacturer under the CRA. Since 11 September 2026, manufacturers have had to report actively exploited vulnerabilities in their products through the CRA Single Reporting Platform, as the EU joint statement reminds. See our CRA guide.
Your customers: if you host or run PHP for clients, they will ask. A short written note (what you run, when it was patched, what you checked) answers most of them, and it is the same note an auditor or a cyber insurer will want to see.

After the Emergency: What to Change

On most well-run servers PHP2Shell will be patched within days. What it revealed about your setup will still be true afterwards.

Know how long a patch takes you. From the advisory to every server restarted: hours, days or weeks? If the honest answer is "we would have to ask the agency", fix that before the next one. When researchers say AI cut their exploit work from months to a week, assume attackers can move at that pace too.
Keep the inventory you just built. It was the hardest part of the response, and it goes stale the moment nobody owns it.
Get off end-of-life PHP. A site on 7.4 or 8.1 needed a vendor or a source backport this time; next time there may be neither. PHP 8.2 reaches end of life on 31 December 2026, so a site leaving 8.1 should go straight to 8.3 or later. Moving PHP often means updating the application as well: our article on Drupal, Umbraco and Kentico end of life shows what that involves for one CMS.
Prefer PHP-FPM to mod_php where you can. It was the lower-risk setup this time.
Leave upload progress off if you do not use it. PHP's advisory suggests keeping session.upload_progress.enabled off even after patching when the application does not need it.
Write patch times into your contracts. Ask your hosting provider and your agency how quickly they apply critical PHP fixes, and get the answer in writing.

A Checklist for This Week

List every PHP installation, including containers, control panels, vendor products and staging servers.
Patch internet-facing systems first, starting with Apache mod_php.
Restart every PHP process and check the version the web server reports.
Rebuild and redeploy container images.
Where you cannot patch today, apply PHP's interim settings, route traffic through a WAF, or take the system offline.
Ask suppliers and hosting providers for their PHP version and patch date, in writing.
Review logs and file changes on anything that was exposed and unpatched since 20 October.
Decide whether a reporting obligation (NIS2, GDPR, CRA) applies.
Plan the move off PHP 8.1 and older, and off 8.2 before 31 December.

Where We Can Help

Most companies do not lack the will to patch. What they lack is a clear picture of what they run, or the people to do the work this week. That is the part we take on:

Inventory and patching, in days. We find your PHP installations across servers, containers, hosting panels and suppliers, patch them, restart and verify, and leave you a written record of what was done and when. That record is also your answer to customers and auditors.
Getting off old PHP. Applications stuck on PHP 7.x, 8.0 or 8.1 because the code will not run on anything newer: we port them to a supported version under our legacy system maintenance service.
Hardening and a patch routine, so the next advisory is a scheduled job instead of an emergency.

If you find signs of a break-in, call an incident response provider first. We can take on the rebuild and the upgrade alongside them.

Write to office@c9group.dev with what you run, and we will reply with what we would do first.

Sources

Checked on 22 October 2026. The situation is still moving: exploitation status and vendor packages in particular may have changed since.

PHP project

Agencies

Researchers, vendors and data