PHP2Shell: how we patched 375 servers and hundreds of client sites in 12 hours

What is PHP2Shell, and is my site affected?

On 21 October 2026 the US Cybersecurity and Infrastructure Security Agency (CISA) asked organisations to patch two critical PHP flaws immediately: CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell. Both are rated 9.2 under CVSS v4.0 and allow remote code execution without logging in. CISA’s alert says they “affect all PHP installations serving web requests”, and the PHP project, as summarised by Qualys, says every installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

If your website runs on WordPress, WooCommerce, Magento, Drupal, Laravel or any other PHP application, assume it is affected until you have checked. That includes sites on shared hosting and hosting control panels, where PHP is installed for you.

The two flaws, in plain terms:

• CVE-2026-109618: when PHP runs out of memory part way through setting up a request, its clean-up code can treat half-built data as valid.
• CVE-2026-109619: data that belongs to one request can survive after its memory is freed, and a later request handled by the same worker can use it.

Apache with mod_php is the most exposed: the PHP project reports an exploit that fires before any application code runs. PHP-FPM blocks one of the paths, but the PHP project has shown code execution against it under the right application conditions, so it needs the update too. Researchers also showed that the memory of a PHP worker, which can hold passwords, tokens and API keys, can be read without logging in.

How big is the impact?

Large, because PHP sits under so much of the web. According to W3Techs, PHP runs on 69.3% of websites whose server-side language is known (October 2026), and that includes every WordPress, WooCommerce and Magento site.

What an attacker gets is just as serious:

• Full control of the site. Running code on the server means pages can be changed, malware or spam links planted, and customer data read or deleted.
• Your secrets. The leaked worker memory can hold database passwords, payment and API keys and session tokens, so the damage can reach systems beyond the website.
• No warning signs for visitors. The attack needs no login and, on mod_php, fires before your application runs, so a site can look normal while it is compromised.

Is PHP2Shell being exploited?

Reports differ, so plan for the worse case. CISA said it had not seen exploitation when it published its alert. Amazon Threat Intelligence logged an attempt in its honeypot network on 17 October, four days before disclosure, as Help Net Security reported, and Cloudflare and Patchstack have since reported attack activity. A working exploit exists.

Which PHP versions fix it?

Upgrade to one of these upstream releases:

PHP 8.1 and older are outside upstream support. The PHP security team published minimal source patches for 7.4, 8.0 and 8.1, mainly for people who build PHP themselves. If a site is still on one of those versions, treat this as the deadline for the upgrade that has been waiting.

Why does php -v say 8.3.6 on a patched server?

Linux distributions usually fix their own PHP packages instead of moving to a new upstream version. The version number stays the same; only the package revision changes.

We saw this on our own servers. On an Ubuntu 24.04 machine patched on 22 October, php -v still reports PHP 8.3.6, not 8.3.36. The fix is in the package 8.3.6-0ubuntu0.24.04.13, which Ubuntu’s CVE tracker lists as the patched version for 24.04. A checklist that only compares the number php -v prints with the table above would flag that server as unpatched, and it could pass an unpatched one whose number happens to look newer.

So check two things:

1. The package, against your distribution’s advisory. For example dpkg -l 'php*-fpm' on Debian and Ubuntu, or rpm -q php-fpm on Red Hat systems, compared with the fixed version your distribution publishes.
2. The PHP that actually serves requests. php -v on the command line can come from a different install than the one your web server uses, so check the PHP-FPM pool or web server module itself.

How do you patch PHP in hours, not weeks?

Within 12 hours of the fixed releases, we patched 55 dedicated servers, 320 cloud instances and hundreds of customer websites. Speed like that comes from doing the steps in the right order rather than from effort alone. These are the steps that matter:

1. Know where PHP runs. List every server, container image, hosting-panel install and bundled copy of PHP, including staging sites and forgotten microsites. CISA’s advice starts here, because PHP often sits inside other software.
2. Patch what faces the internet first. Public websites, checkouts and admin panels come before internal tools.
3. Use the right source for each install. Your distribution’s package or your vendor’s backport for system PHP, a rebuilt image on a fixed base for containers, and the host’s update for managed hosting.
4. Restart the workers. PHP-FPM pools, Apache and application servers keep running the old code until they restart. The update is not done until they have.
5. Confirm the running version. Check the package and the runtime that serves requests, as described above.
6. Test each site. The home page, a form or product page, checkout or sign-in, and the admin. Point releases rarely break a site, but a site that goes down is a second incident.
7. Look for signs of compromise. PHP workers starting shells or downloading tools, new admin users, files changed outside a deployment. If you find any, rotate the passwords, API keys and tokens the site holds.

What if you cannot patch today?

In the PHP project’s words, “Updating is the only complete fix.” If a system cannot be updated straight away, the PHP project and CISA suggest these stopgaps, which lower the risk but do not remove it:

• Restrict public access to the site, or take it offline until it is patched. CISA recommends taking unsupported PHP systems offline.
• Put a web application firewall in front of it. Cloudflare has released rules for the known exploit paths, including on its free plan.
• Set session.upload_progress.enabled=0 in php.ini or the PHP-FPM pool, then restart the workers. Setting it from application code or .user.ini is not enough.
• Set conservative request limits such as post_max_size, and lower max_input_nesting_level.

Write down who owns each unpatched system and the date it will be fixed. A stopgap without a deadline tends to become permanent.

How do you make the next PHP emergency smaller?

PHP2Shell will not be the last critical flaw in a language runtime. The useful question is how much of your estate is exposed when the next one lands.

• Serve visitors static files where you can. In a headless set-up, WordPress or another CMS manages the content and the public site is generated as static pages, so visitors never reach PHP. This website works that way: the page you are reading is a static file, and WordPress runs only as the editing back end, with its admin behind an extra sign-in. The back end still needs patching, but the public site has no PHP to attack.
• Move dynamic pieces to managed or serverless runtimes. Forms, search and checkout logic can run as serverless functions or on managed platforms where the provider patches the runtime. You trade some control and portability for a smaller patching job.
• Build servers from images, not by hand. When servers and containers are built from a versioned image, a fix is a rebuild and redeploy that works the same way every time.
• Keep the inventory current. A list of every site, its PHP version and its owner turns a security alert from a search into a checklist.
• Stay on supported versions. Sites on PHP 8.1 or older are left with source patches or paid extended support. Upgrading on a schedule costs less than upgrading in an emergency.

Not every site should go headless. A WooCommerce or Magento store with heavy personalisation may stay on PHP, and that is fine if it is patched quickly and watched. The aim is to choose where PHP runs, not to inherit it everywhere.

How can PixelCrayons help?

If you run PHP websites and are not sure they are patched, we can check and patch them for you: the inventory, the update, the worker restarts, the checks and a written record of what changed on each site. For agencies, we do the same under your brand across your clients’ sites.

We also plan the longer moves: upgrading sites still on PHP 8.1 or older, and moving content sites to a static or headless front end where it makes sense.

• Ask us to check and patch your sites
• WordPress development, WooCommerce development and Magento development
• White-label WordPress for agencies
• Website replatforming guide, if a move off an old platform is due
• How we work with security and compliance

Sources

• W3Techs: Usage statistics of PHP for websites (October 2026)
• CISA: Critical vulnerabilities in PHP require immediate patching (21 October 2026)
• Qualys: PHP announces critical security release for two vulnerabilities
• Ubuntu: CVE-2026-109618
• Help Net Security: PHP2Shell vulnerabilities patched