PHP2Shell: patch PHP now. Your plugins can’t fix this one.

Most website security scares happen one layer up. A WordPress plugin has a hole, a Laravel package needs a bump, and you update the app and move on. This one is different. PHP2Shell sits in PHP, the engine underneath all of those apps, and in the worst case it is triggered before your app's code has even started running. No plugin update, theme update or WordPress release can fix it. The fix is a new PHP.

The two bugs, tracked as CVE-2026-109618 and CVE-2026-109619, were found by researchers at Calif, Wiz and OpenAI and reported to PHP's security team. Both are rated 9.2 out of 10 on the CVSS v4 scale, and PHP confirms both can lead to remote code execution by an attacker who never logs in.

What PHP2Shell actually is

Both bugs come down to PHP leaving its own memory in a bad state when a web request doesn't finish the way it should. PHP's advisory describes them in plain enough terms.

• CVE-2026-109618, out-of-memory corruption. If PHP runs out of memory partway through setting up a request, some of its internal data is left half built. The clean-up code that runs afterwards treats that half-built data as valid.
• CVE-2026-109619, stale global state. Some data that belongs to one request can outlive the memory it points to. A later request handled by the same PHP worker can then pick up the leftovers. As well as code execution, PHP lists memory disclosure as a confirmed impact. In other words, one visitor's request can leak pieces of another's, including passwords, tokens and keys.

That is the part that makes this serious. Most web attacks need a weakness in your code. This one needs only a PHP server that accepts requests from the internet, which describes most of the web.

A leak forced an early release

The plan was a quiet, coordinated fix on 22 October. Linux distributions and long-term support vendors had already received patches in advance so they could ship on the same day. Then the CVE numbers leaked.

Who is affected

The short answer is almost anyone running PHP that serves web pages. The PHP team's advisory names every common setup: PHP-FPM behind Nginx or Apache, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The longer answer depends on two things, which PHP branch you are on and how PHP is plugged into your web server.

By version

By server setup

How PHP is wired into the web server changes how much has been proven so far, but not whether you need to patch. One write-up put it bluntly: not having been demonstrated on FPM does not make it safe.

By what you run on top

Because the bug is in PHP rather than any one app, everything built on it inherits the exposure. Calif says it confirmed pre-login code execution against specific versions of WordPress, Drupal, Joomla and Magento, and Wiz demonstrated it against WordPress, Drupal and Joomla. The flaw isn't in those projects, which is why updating them won't help.

Nobody knows exactly how many servers are exposed, and the estimates show it. They measure different things, but even the lowest runs well past a million.

Is it being exploited?

The honest answer is that the reports conflict. Amazon says php2shell is now being broadly exploited and that its 21 October attempts point to several different attackers. Cloudflare's CTO said it was seeing early attacks before the patches shipped, and watchTowr says its honeypots have seen attempts against both bugs. On the other side, CISA said on 21 October that it had not seen exploitation, and as of 22 October neither bug was in its Known Exploited Vulnerabilities catalogue. Huntress hadn't seen any on its customers' systems, and no confirmed breach had been made public.

Attempts are not the same as successful break-ins, and some of what the honeypots catch is probing. But the direction of travel is clear. Proof-of-concept code is circulating, Calif and Wiz have published technical write-ups, and the UK's National Cyber Security Centre has told organisations to update immediately or take affected systems offline.

Check your version

Start with the PHP that actually serves your website, not just the one on your command line. They are often different builds, and sometimes different versions. On a server running PHP-FPM, run php-fpm8.4 -v (swap in your version). With Apache and mod_php, php -v only shows the command-line build, so check the installed Apache PHP package instead, for example with dpkg -l 'libapache2-mod-php*'. On WordPress, go to Tools → Site Health → Info → Server. Most hosting control panels show it too. Then paste it here.

What to do now

Updating PHP is the only complete fix. PHP's own advisory says no configuration change fully mitigates these flaws. What updating involves depends on who looks after your server.

Check you weren't hit

If a server was exposed before you patched, it is worth a look. Incident responders at Huntress suggest watching for the signs an attacker leaves when they get code running through a web server:

• PHP or web server processes (php-fpm, php-cgi, apache2, httpd) starting shells, scripting languages or download tools such as curl and wget.
• Reconnaissance commands like whoami, id or uname -a run from the web server account.
• New or changed PHP files in your web root that you didn't put there, plus new cron jobs, scheduled tasks or user accounts.

If anything looks wrong, take the server offline and keep the web server and PHP logs before you clean up. Because the stale-state bug can leak memory, also rotate the passwords, API keys and tokens that server could see.

What happens next

The fixed releases are the easy part. The hard part is the long tail. PHP runs on millions of servers that nobody logs into from one year to the next, from old company sites to appliances whose makers stopped shipping updates years ago. Seven affected branches get no fix at all from the PHP project. Forensics expert Hal Pomeranz expects exactly that: a long tail of servers that stay vulnerable for years.

Watch for two things in the coming days. The first is CISA's exploited-vulnerabilities catalogue. If PHP2Shell is added, US federal agencies get a hard deadline, and that usually means the attacks are confirmed. The second is vendor advisories for products that bundle PHP, which are slower to arrive and easier to miss. Palo Alto Networks, Fortinet and Cisco were all checking their products when the fixes shipped.

There is also a bigger story here. Wiz says frontier AI models substantially lowered the barrier to turning these long-standing weaknesses into a working exploit. Some of the same bugs may have sat in PHP since 2012. AI tools are making old flaws in widely used software faster to find and faster to weaponise, for researchers and attackers alike. That makes boring, quick patching more valuable than it has ever been.

For today, the job is simple. Find out which PHP serves your sites, get it to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor build with the fix, and restart it.