PHP2Shell: Two Critical PHP Flaws Reported as RCE, CVE-2026-109618 and CVE-2026-109619

PHP2Shell is the name used for two critical flaws in PHP itself, which CERT-EU names CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both 9.2 on CVSS v4.0 and says fixed releases are due on Wednesday, 21 October 2026 at 14:00 UTC. CERT-EU says the score points to possible remote code execution without a login. When this post was written, PHP had not yet published the affected versions, the fixed versions or any technical detail.

This post joins what PHP, CERT-EU and security researchers have said so far. It marks what is confirmed and what is only reported, and it lists steps you can take today. Where nobody has published a fact, the post says so instead of guessing.

What Do We Know So Far?

Very little is confirmed by PHP, and a lot is reported by others. The dates below come from PHP’s notice and from Sansec, Huntress and CERT-EU.

The facts split into three groups.

• Confirmed by PHP: two critical flaws, a score of 9.2 each on CVSS v4.0, and the release date and time. The PHP notice does not name the CVE ids.
• Reported by others: the CVE ids (CERT-EU), remote code execution (CERT-EU, citing leaks, and Sansec) and the name PHP2Shell. Sansec says it is the name of an exploit tool seen in a leaked screenshot and credited to Calif.IO.
• Not published yet: the root cause, the affected versions, the conditions needed, the fixed versions and any indicators of compromise. Huntress writes that no indicators of compromise have been confirmed yet. The GitHub security advisory list for php-src had no entry for either CVE when we checked.

Nobody reported exploitation in the wild when we looked. Huntress has not seen it across its own customers, and the CISA Known Exploited Vulnerabilities catalog listed neither CVE. Sansec still expects mass attacks to start within 15 minutes of the release. That is a forecast, not a measurement.

Which PHP Versions Are Exposed?

PHP has not said. CERT-EU, citing a social media post, says all versions from PHP 5 onward may be affected. Sansec says the flaws affect all web servers running PHP 5.4 or later, and that the banner of the leaked tool claims the same range. PHP has not confirmed either claim. Until PHP publishes its list, treat every branch as exposed. No current release can contain the fix, because the fixed releases do not exist yet.

The support dates come from php.net and the release numbers from its news page. PHP’s notice does not list branches, so the “official fix” entries for the supported branches are our assumption until the release is out. Sansec says servers on 8.1 or older need a backport from their provider or an upgrade to a supported PHP version.

Has PHP Said What the Root Cause Is?

No. Huntress writes that no technical root cause has been published, and Sansec says PHP will publish technical details and the fixed versions with the release. Public write-ups name functions and extensions, but they rest on material that PHP has not confirmed, so this post does not repeat them. When PHP publishes its advisory, the root cause, the conditions and the affected versions will come from there.

One setting deserves a look anyway. The PHP manual describes session upload progress, a feature that tracks a file upload and writes its progress into the session. The manual lists session.upload_progress.enabled as on by default, and it advises turning it off when you do not use progress bars, because field names are not validated. No source we read confirms that this setting has anything to do with the two flaws.

How Can You Check Your Own Exposure?

We know of no published safe test for the bugs, so do not send exploit traffic to a server. What you can check safely is the version and the setting. Huntress starts with an inventory, including PHP bundled in vendor software, control panels and CMS platforms.

php -v
php -i | grep -i session.upload_progress
php-fpm -v
curl -sI https://www.example.com/ | grep -iE "^(server|x-powered-by):"

The second command reads the setting for the command line, which may use a different php.ini than your website. Check the file your web server really loads, for example with a phpinfo() page that you delete right after.

To see the PHP version your site advertises to the outside world without a terminal, run our free PHP2Shell vulnerability check. It sends one ordinary request to your homepage, reads the version from the response headers and never sends exploit traffic.

What Should You Do Before the Patch?

Nothing replaces the update. These steps reduce risk while you wait, and none is confirmed to stop both bugs.

• Prepare the update. Sansec says the fix is a PHP update at server level that cannot be applied from application code. Back up files and databases, book a change window and ask your host to stand by.
• Consider turning off upload progress where you do not use it. Set session.upload_progress.enabled = 0 in php.ini, or php_admin_flag[session.upload_progress.enabled] = off in an FPM pool file. The manual lists the setting as changeable only per directory or server, so ini_set() in code does not work. Only progress tracking stops. This is the manual’s general advice, not a confirmed workaround for these flaws.
• Isolate what you cannot patch. CERT-EU advises isolating internet-facing applications from public networks if immediate patching is not possible.
• Plan the move off old branches. Huntress says to upgrade end-of-life PHP (5, 7 and 8.0 or 8.1), take it offline or put it behind a VPN or WAF.

What Should You Do After the Patch?

Read the php.net announcement first. It will carry the affected versions and the fixed versions, and the numbers in your plan should come from there.

1. Patch internet-facing PHP first. Huntress says to patch internet-facing systems first, and Sansec expects attacks within minutes of the release.
2. Check your Linux distribution or host for backported packages. Huntress advises checking distribution and hosting providers for backported packages.
3. Restart PHP-FPM or the web server so running workers load the new code, then confirm the version again with the commands above.
4. Look back through logs since 20 October for the signs in the next section.

Teams that lose track of their PHP hosts can use External Attack Surface Management to list what faces the internet. That list is the starting point for the update order.

How Do You Spot an Attack?

No indicators of compromise are published. Huntress says none has been confirmed, and Sansec lists no signatures. The practical signal is behavior: a web server process doing something a web server should not do. Successful remote code execution often ends in a web shell that gives the attacker a way back in.

• PHP worker processes (php-fpm, php-cgi, httpd, apache2) starting shells such as sh, bash, cmd.exe or powershell.exe, per Huntress. The same goes for interpreters such as python or perl, or tools such as curl, wget, nc or certutil.exe.
• Command-line strings with /dev/tcp/, fsockopen or mkfifo, and reconnaissance commands such as whoami, id, uname -a and ipconfig run by the web server, per Huntress.

If you find signs of compromise, Huntress advises you to isolate the server and keep the web server and PHP logs. Then look for web shells, new files in the web root, cron jobs, scheduled tasks and new accounts. Attackers who use this route are exploiting a public-facing application, which MITRE tracks as T1190 (Exploit Public-Facing Application), and a planted shell maps to T1505.003.

How Is PHP2Shell Different From WP2Shell?

The names are close, the problems are not. In our WP2Shell analysis, the flaws sit in WordPress core code and are fixed by updating WordPress. PHP2Shell concerns PHP itself. Sansec says the fix is a PHP update at server level, which a store cannot apply from its own code. It says this reaches stores such as Magento, Shopware and WooCommerce. A WordPress site on an exposed PHP version could be affected by both stories, and each needs its own update.