PHP2Shell: CVE-2026-109618 and CVE-2026-109619 PHP RCE

If you run WordPress, you run PHP, and PHP is about to get an emergency patch for two critical remote code execution flaws. Be ready to apply it the moment it lands. Details of the two bugs, CVE-2026-109618 and CVE-2026-109619, leaked on October 20 ahead of their planned disclosure. The PHP security team moved the fix forward a day to October 21, 2026 at 14:00 UTC. The bugs are reported to affect every PHP version going back to PHP 5, which covers WordPress, WooCommerce and nearly every other PHP application on the web, and PHP will only patch the branches it still supports.

At a glance

CVE	CVE-2026-109618 and CVE-2026-109619
Software	PHP itself, the language runtime, not a plugin or application. About 2.2 million internet-facing hosts advertise PHP
Type	Remote code execution in PHP core, reportedly unauthenticated. Technical details are embargoed until the release
Severity	CVSS v4.0 9.2 for both, per PHP (the leak claimed 10.0). Critical either way
Affected	Reportedly every version since PHP 5 (or 5.4, depending on the source). Not yet confirmed by PHP
Fixed	Expected in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 14:00 UTC. PHP 8.1 and older will get no fix from PHP
Status	Weaponized exploit reportedly exists. Cloudflare reportedly saw early attacks on October 21. Others report none yet

What’s wrong

Here’s the uncomfortable part: we don’t know yet. PHP keeps fixes for embargoed vulnerabilities private until release, and its advance notice says only that “full details, affected versions, and the fixed versions will be published with the release.” What we do know comes from the leak and from researchers who have since seen more:

Both bugs are remote code execution in PHP’s core, triggered before any application code runs. That means WordPress, its plugins and its security settings never get a say. The request is handled by PHP, and PHP is what breaks.
watchTowr says it confirmed the flaws are real and reproduced CVE-2026-109618 within hours of the leak.
The leaked advisory shows an exploit tool called “PHP2Shell,” credited to Calif.IO, whose banner claims it works on every PHP release from 5.4.0.
It isn’t yet known which PHP component is at fault, which server setups (PHP-FPM, mod_php, CGI) are exposed, or whether any configuration avoids it.

The timeline so far:

Before October 20. The bugs were reported to PHP privately, and a coordinated disclosure was set for October 22.
October 20, morning. A post on Hacker News revealed the upcoming advisory. It was taken down, but screenshots spread.
October 20, afternoon. watchTowr confirmed the bugs were real.
October 20, 19:33 UTC. PHP announced an emergency release for October 21, 14:00 UTC, a day early, and said it would go even earlier if attacks began.
October 21. CERT-EU issued advisory 2026-018. Reports say Cloudflare started seeing early attacks against PHP sites and deployed WAF rules for all plans.

Normally, defenders get the patch and the attackers get the details at the same moment. This time attackers got a head start.

What the attacks look like

There are no published indicators yet: no IP addresses, no request patterns, no file names. That will change quickly after the release, because a patch is also a map of the bug. In June 2024, the PHP CGI flaw CVE-2024-4577 was being exploited within 24 hours of disclosure, according to Akamai.

Until then, the best signal is what happens after a successful attack: the PHP process starts running things it never normally runs. Huntress suggests watching for PHP worker processes (php-fpm, php-cgi, httpd, apache2) launching:

sh, bash, cmd.exe, powershell.exe
python, perl
curl, wget, nc, certutil.exe
whoami, id, uname -a, ipconfig

Look out for reverse-shell patterns too, such as /dev/tcp/, mkfifo and fsockopen in command lines. Florian Roth has released process-watcher to log PHP child processes on Linux. As he puts it, it detects. It “prevents nothing.” WordPress itself almost never needs to spawn a shell, so on a WordPress server, any of these is worth a look.

What to do

1. Find out which PHP you’re on

In WordPress, go to Tools → Site Health → Info → Server and look at the PHP version. Many servers also announce it in an X-Powered-By response header. Then match it up:

PHP 8.2, 8.3, 8.4 or 8.5: a fix is coming today. Get ready to apply it.
PHP 8.1 or older: PHP won’t patch it. Your options are moving to a supported branch, a backported fix from your Linux distribution or host, or taking the site offline or behind a VPN until you can. By Mallory’s count, nearly 884,000 hosts are in this group.

2. Patch the moment it lands

Managed or shared hosting: you can’t patch PHP yourself. Ask your host now when they’ll roll out the fix and, if they offer a PHP version switcher, be ready to use it. Mallory counts more than 142,000 PHP hosts at Hostinger and 290,000 at Amazon alone.
Your own server: update from your distribution as soon as packages appear, then reload PHP-FPM or restart Apache. If you install PHP from Remi’s repository (common on RHEL-based systems), Sansec warns that it won’t have the fix on October 21, so switch to distribution packages or build from source.
Internet-facing first. Public websites before internal tools.

Don’t rely on workarounds. Some posts are suggesting session.upload_progress.enabled = 0 and other php.ini changes. A PHP core developer has said that setting alone isn’t enough, and Aikido says the circulated settings don’t protect against these bugs. Cloudflare’s WAF rules help only if your origin server refuses traffic that doesn’t come through Cloudflare. Anyone who knows your server’s real IP address goes straight around them. Patching is the fix.

3. Check whether you were hit

If your site was online and unpatched from October 20 on, check after you update:

New PHP files in the web root, wp-content/uploads/, wp-content/mu-plugins/ and anywhere else they don’t belong
New administrator accounts in WordPress, and new system users on servers you control
New cron jobs, both in the system crontab and in WordPress scheduled events
Unknown keys in SSH authorized_keys
Your web server and PHP logs, kept somewhere safe before anything rotates them out

If you find a web shell, treat the server as compromised: isolate it, restore from a backup taken before October 20, and rotate every password and key it held.

4. Make the next one harder

Two settings won’t stop this bug, but they make attacks like it less effective. First, stop advertising your PHP version. Exposure counts like Mallory’s are built from X-Powered-By headers, and so are attackers’ target lists. Second, if your site doesn’t need PHP to run system commands (WordPress core doesn’t), take that ability away, so a web shell can’t easily turn into a full shell. In php.ini, or per pool for PHP-FPM:

; Don't announce the PHP version in response headers.
expose_php = Off

; Remove PHP's ability to run system commands.
; Test first: some plugins (image optimizers, backup tools) use these.
disable_functions = exec,passthru,shell_exec,system,proc_open,popen

On managed hosting, these are often in the control panel’s PHP settings. Neither one is a fix. Hiding a version doesn’t patch it, and disable_functions has known bypasses. But each one makes a mass attack a little more expensive.

The bigger lesson

Most CVE Watch posts are about plugins: code you chose, can replace, and can choose not to install. This one is about the floor everything stands on. You can run a perfectly patched WordPress with three carefully chosen plugins and still be exposed, because the language runtime underneath it has a hole.

Two things make that survivable. One is staying on a supported PHP branch. More than half the PHP servers Mallory counted are on versions that won’t get this fix at all, and PHP 8.2’s security support ends on December 31, 2026. The other is a host or deployment process that can roll out a runtime update in hours, not weeks. Today will show which sites have both.

PHP2Shell: Two Critical PHP Flaws Leaked Before the Patch