Move your cursor - the loader tilts with you.

PHP2Shell: the flaw no plugin update can fix

On 21 October 2026 the PHP project shipped emergency patches for two critical flaws in PHP itself. They are not WordPress bugs or plugin bugs, which is exactly why they are worth understanding. Here is what happened, what it does and does not prove about CMS-based sites, and what to do this week.

What happened

PHP2Shell is the name given to two vulnerabilities in the PHP language runtime, tracked as CVE-2026-109618 and CVE-2026-109619. PHP announced a critical security release on 20 October 2026 and shipped the fixes on 21 October. Both flaws are rated 9.2 out of 10 on the CVSS 4.0 scale. The worst case is remote code execution: someone on the internet, with no login, sends a crafted web request and ends up running their own code on your server.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The vulnerable code goes back a long way: PHP says the flaws affect PHP 5.4 and later. Branches the PHP project no longer supports, which means 8.1 and everything older, get no upstream fix.

Both bugs share one root weakness, in how PHP behaves when a request goes badly wrong. When PHP runs out of memory, or hits another fatal condition, partway through a request, it is supposed to stop and tidy up after itself. In these cases it leaves its internal state in a condition that a carefully built request can abuse. That makes it a memory-safety problem in the engine, not a mistake in anyone's website code. We are deliberately not describing the mechanics any further; the detail is in the vendor advisories listed at the end, for the people who need it to defend systems.

Who found it: researchers at the security firm Calif, using AI tooling from OpenAI, reported the flaws, and the cloud security company Wiz found them independently.

First, a correction: this is not a plugin flaw

It is tempting to read PHP2Shell as proof that plugins are the weak point. The facts do not say that. The flaws live in the PHP engine, underneath WordPress, Drupal, Joomla, Magento and every other PHP application. Researchers demonstrated unauthenticated code execution against current versions of WordPress, Drupal, Joomla and Magento 2.4.9, but that is because they all run on PHP, not because any of them contains the bug.

Three things follow. Updating WordPress core or your plugins does not close it; reporting says WordPress.org confirmed that no WordPress release is needed. A hand-written PHP site, or one built on a framework such as Laravel, is exposed in exactly the same way. And the application's own code can be perfectly clean while the site is still vulnerable. On Apache with mod_php, which PHP rates as the highest-risk setup, researchers showed code running before the application had even started.

Which server setups are affected: PHP's advisory covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. One analysis says no complete attack against PHP-FPM has been shown for one of the two flaws. Do not read that as safe. Patch regardless.

What it does say about CMS and plugin-based sites

You do not control the layer that brokeOn shared hosting or a managed WordPress plan, the host decides when PHP is patched. You can update every plugin you own and still be exposed until a company you pay by the month does its part. Do you know which PHP version your site runs on today?
A security plugin cannot save you from thisA security plugin is PHP code. It runs inside the engine that is broken, after the engine has already read the request. Filtering in front of the site can help: Cloudflare and Vercel both added rules for known attack patterns. But PHP's own position is that no configuration change fully mitigates the flaws, and that patching is the fix.
Old PHP and old plugins can trap each otherAnything on PHP 8.1 or older gets no fix from the PHP project. If a plugin or theme you depend on does not support a newer PHP version, you are choosing between running unsupported PHP and losing the plugin. Some distribution and third-party vendors publish back-ported fixes for older versions. That is a stopgap, not a plan.
Every layer has a different owner and patch calendarA typical CMS site stacks a host, an operating system, PHP, the CMS core, a theme and however many plugins have accumulated. PHP2Shell sat in the bottom layer. The April 2026 EssentialPlugin compromise covered on our custom code vs WordPress page sat in the top one. Different layers, same lesson: you inherit risk from code you did not write and cannot audit.

What PHP2Shell does not prove

Here is the other half, because it would be easy to overclaim. Custom code is not automatically safe. A bespoke PHP site is exposed to PHP2Shell exactly as much as a WordPress one. And the stack we build on has had its own moment: in December 2025 a maximum-severity remote code execution flaw in React Server Components, known as React2Shell (CVE-2025-55182), affected React and Next.js and was being exploited in the wild within days.

What owning the stack changes is not whether flaws exist. It is who can act when one lands. When a flaw is in your own repository's dependencies, your team can upgrade, test and ship the same day, and you can see exactly what the site depends on. When it is in a layer owned by a host, a theme author and a dozen plugin vendors, you wait on all of them. That is the real argument for fewer layers, and it is a smaller claim than “plugins are insecure”.

For the record, PHP2Shell does not apply to the sites we build. Our own site runs on Next.js, not PHP, and the custom builds described on our custom code vs WordPress page are React and Next.js. That is not a claim of immunity. It only says this particular flaw is not one we have to deal with, and that we hold the patches that are ours to the same standard of urgency.

What is still disputed

This story is days old, and early reporting disagrees on several points. As of 24 October 2026:

Exploitation. watchTowr says it saw both flaws exploited through its honeypots from 21 October, and Hadrian reports exploitation at scale. Amazon's honeypots logged an attempt dated 17 October, four days before the patches. Cloudflare saw attack traffic against its customers but reported no compromises. CISA had not observed exploitation when it issued its alert and, as of 23 October, had not added either CVE to its Known Exploited Vulnerabilities catalogue. Huntress had not seen exploitation on its partners' systems.

How reliable the public exploits are. Sansec says the public exploits do not work against a default PHP installation, while others warn that a working attack path has been demonstrated, mostly against mod_php. “Does not work on defaults” is not a reason to wait.

Whether the patches are complete. One vendor, Abstract Security, claims it reproduced code execution on a fully patched 8.2.35 host through a path the fixes do not address. We found no other source that corroborates this, so treat it as unconfirmed and watch PHP's advisory for follow-up releases.

How many sites are exposed. Estimates depend on how exposure is counted. Wiz's headline figure is roughly 70% of the internet; Palo Alto Networks counted about 22.6 million exposed instances. We will update this page as the picture settles.

What to do this week

  1. Find out what you run. Ask your host, or check your hosting dashboard, for the PHP version and how PHP is served (mod_php, PHP-FPM and so on). If you manage your own server, php -v on the command line shows the version.
  2. Upgrade to a fixed release. That means PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your operating system vendor's patched package for the same fix. Several Linux distributions, AlmaLinux among them, published patched packages the same week. On PHP 8.1 or older there is no upstream fix: plan the move to a supported version, and ask your host or a back-porting vendor what they offer in the meantime.
  3. Restart the PHP processes. Upgrading the package on disk does not change code that running workers have already loaded, so restart PHP-FPM, Apache or whatever serves PHP. On managed hosting, ask them to confirm they did it.
  4. Add filtering as a stopgap, not a substitute. If your site sits behind Cloudflare or a similar service, check that the PHP2Shell rules are switched on. They block known attack patterns; they do not remove the flaw.
  5. Check for signs, and rotate secrets if you cannot rule it out. There is no agreed list of indicators yet, so this is judgement rather than a checklist: look for unexpected new files, unfamiliar admin users, changed core or config files, and bursts of out-of-memory or fatal errors in your logs from before the patches. Researchers have also shown memory disclosure that can expose passwords, tokens and API keys, so if you suspect your site was probed, change database passwords, API keys and your CMS secret keys.

Three questions for your host or agency

Which PHP version is my site on, and when was it patched?Get the answer in writing, with a version number. “We are on it” is not an answer.
What happens if a plugin blocks the upgrade?Someone has to decide whether to replace the plugin, drop it, or pay for back-ported fixes. Ask who that is before it happens.
Who watches for the next one?Somebody has to read the advisories and act within days, not at the next maintenance window. Ask who that is and what their target is. Security patches are part of what our monthly subscription covers; see the FAQ.

Common questions

Is PHP2Shell a WordPress vulnerability?No. PHP2Shell is two flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619). WordPress, Drupal, Joomla and Magento are exposed only because they run on PHP, and so is any hand-written PHP site. Updating WordPress or its plugins does not fix it; updating PHP does.
Which PHP versions fix PHP2Shell?PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. PHP 8.1 and older get no upstream fix, although some operating system and third-party vendors publish back-ported patches for older versions.
Can a security plugin or firewall plugin protect my site?Not reliably. A plugin is PHP code running inside the affected engine. Filtering in front of the site, such as Cloudflare's rules for known attack patterns, can help as a stopgap, but PHP's own position is that no configuration change fully mitigates the flaws. Patch PHP and restart the PHP processes.
Does a custom-built site avoid PHP2Shell?Only if it does not run on PHP. A custom PHP site is exactly as exposed as a CMS site. A site built on Next.js and Node, like ours, is not affected by this flaw, though it has its own patching duties.

Sources and further reading

Compiled on 24 October 2026 from vendor and press write-ups published between 20 and 24 October. PHP's own advisory is the authority on affected and fixed versions.

Not sure what is running under your site?

Send us your site's address and we will tell you what we can see it is built on, and walk through who is responsible for patching each layer. No pitch, no obligation.

Ask us to look