PHP2Shell: What CVE-2026-109618 and CVE-2026-109619 Mean, and What to Do Now

PHP2Shell is the name given to two critical remote code execution vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2. PHP released fixes on 21 October 2026: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.[1][2][3]

If you run PHP anywhere - a public WordPress site, an intranet, a control panel, a vendor appliance - this is what happened, who is at risk, and what to do today.

What is PHP2Shell?

These are bugs in the PHP engine, not in WordPress, not in a plugin, and not in a single hosting panel. A remote attacker who can send HTTP requests to a PHP site may be able to run their own code as the web server user, without logging in.

PHP workers are reused across requests. Both bugs are about a request that dies badly and leaves the worker unclean for the next one.

CVE-2026-109618 - if PHP runs out of memory while a request is still starting (for example while parsing an upload), shutdown can run on half-built internal data. Researchers demonstrated remote code execution on Apache with mod_php using default settings, before any application code runs.[2]
CVE-2026-109619 - internal state from one request can survive after its memory is freed. The next request on the same worker can then use that stale state. Remote code execution was demonstrated on mod_php against a real application.[3]

PHP says every SAPI that serves the web is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed. They consider mod_php the highest risk.[1]

How serious is it?

A 9.2 critical RCE in PHP is as bad as it sounds. A successful attack can mean control of the site, the data behind it, and a foothold on the server.

CISA, on the day of the fix, had not observed exploitation. CERT-EU noted public discussion and early proofs of concept. Those are different facts. Leaked, widely used software is usually exploited quickly once the patch is public, because attackers can diff patched and unpatched code.[4][5]

Internet-facing systems are the priority.

Which systems are affected?

Treat any system running PHP as potentially vulnerable until it is patched. The bugs reach back through current 8.x; Google’s write-up of the same disclosure puts the range at PHP 5.4 through 8.5.11.[6]

PHP often runs where teams do not look first:

Public sites on WordPress, Drupal, Magento, Laravel
Intranets, customer portals, phpMyAdmin, Roundcube
Hosting control panels and their internal PHP
Vendor appliances that embed PHP

The last two are the easiest to miss. Ask the vendor or host whether the product runs PHP and when their package lands.

WordPress core updates do not fix this. The fix is the PHP binary on the server.

What to do now

The patch is the fix. Most of the work is knowing where PHP actually runs.

Find your PHP. Inventory every binary that serves requests (php -v on that binary, not only root’s PATH). Include FPM pools, LiteSpeed lsphp, Apache modules, containers, and panel-managed versions.
Patch now. On PHP 8.2 or newer, update to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. On 7.4, 8.0 and 8.1, use your vendor’s backport or the PHP team’s source patches. Patch internet-facing systems first. Restart php-fpm, Apache or LiteSpeed so old workers die.[1]
Plan for versions with no upstream fix. PHP 5 and 7.x before 7.4 are end-of-life at php.net. Upgrade, or contain them (next section). Some Linux vendors backport; do not assume they did until you check the changelog.
Reduce exposure. Admin panels and internal tools that do not need to be public should not be. VPN or IP allowlists remove most of the remote-attack surface while you patch.
Watch for compromise. Patching does not evict an attacker who is already in. Keep watching after you update.

Until the new binary is running, PHP’s own partial measures (they do not make an unpatched engine safe): keep post_max_size low; set session.upload_progress.enabled=0 in a system ini or FPM/Apache admin value, not .user.ini; on PHP 8.5 set fatal_error_backtraces=0; do not use RLIMIT_AS / RLIMIT_DATA as a stand-in for memory_limit. Restart every worker after those changes.[1]

Versions with no php.net release

PHP 8.1 and older no longer get releases from php.net. The project published minimal source backports for 7.4, 8.0 and 8.1. Some distributions and panels have already shipped packages; Remi’s volunteer repo was told not to expect same-day builds.[1]

For anything you cannot patch today:

Upgrade to a supported 8.x - the only permanent fix.
Isolate - take it off the internet or put it behind a VPN.
WAF - a stopgap for systems that must stay public. It only blocks attacks it can recognise.

Isolate first, then upgrade. A WAF is not a patch.

How to spot a compromise

An attacker who gets code execution will usually try to stay: a small PHP file in an upload directory, a new cron, outbound curl/wget from the web user.

Look for:

PHP or web-server processes starting shells, interpreters, or download tools
New or changed PHP files under the docroot, especially uploads
Unusual outbound connections from the web user
New cron jobs or unexpected user accounts

If you suspect a compromise, isolate the server and keep web and PHP logs before you clean anything. We are not publishing exploit steps.

FAQ

Is there a patch? Yes. 21 October 2026. 8.2 and newer: the versions above. 7.4 / 8.0 / 8.1: vendor backport or PHP source patches. PHP 5 and early 7.x: no php.net fix.

Is WordPress affected? WordPress runs on PHP, so treat the site as in scope until PHP is patched. A plugin update will not do it.

Has it been exploited? CISA had not observed exploitation on 21 October. CERT-EU reported early PoCs. Expect scanning to rise now the patch is public.[4][5]

Does a WAF protect you? Only as a stopgap, and only for attacks it can recognise. Patch.

Honesty

We did not exploit this.
A complete PHP-FPM exploit for CVE-2026-109618 is not claimed in the advisory. FPM is still not “safe.”[2]
Confirm the version on the running SAPI. Root’s php -v is often a different binary.

Sources

[1] https://www.php.net/archive/2026.php#2026-10-21-5 - PHP security advisory, 21 Oct 2026
[2] https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w - CVE-2026-109618
[3] https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp - CVE-2026-109619
[4] https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching - CISA
[5] https://cert.europa.eu/publications/security-advisories/2026-018 - CERT-EU 2026-018
[6] https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619 - affected range