PHP Remote Code Execution (“PHP2Shell” CVE-2026-109618 & CVE-2026-109619)

Key Facts

• Industry name: PHP2Shell
• CVE: CVE-2026-109618 CVE-2026-109619
• CVSS: CVSSv4.0 9.2
• Exploited in the wild: Yes, reported by watchTowr
• Fix available: For some affected versions
• Last updated: October 22, 2026

What Is PHP2Shell?

CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell, are two Remote Code Execution vulnerabilities in PHP, the scripting language many web servers use to run applications. CVE-2026-109618 is triggered when PHP runs out of memory partway through setting up a request, leaving internal data half built for the cleanup code to trust. CVE-2026-109619 comes from internal state that outlives the request memory it points to, so the next request that the same PHP worker picks up can act on that leftover data. PHP confirms both can let an attacker run their own code on the server without logging in. Reaching the server over the network is enough; no account or prior access is needed.

Unlike a typical coordinated disclosure, this one got away from everybody. On October 20, details of two critical remote code execution (RCE) vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, leaked online before their coordinated disclosure and before patches were released. The PHP security team had pre-announced an emergency release for Wednesday, October 21, 2026, at 14:00 UTC, but the embargo broke first: a proof-of-concept tool called “PHP2Shell” surfaced, and at least one security firm said it had reproduced one of the vulnerabilities.

watchTowr was the first to confirm the leak was genuine, with CEO Benjamin Harris communicating to the industry that the rumored vulnerabilities were real and that the company had successfully reproduced CVE-2026-109618 and CVE-2026-109619, without publishing details before the patches shipped.

watchTowr enabled watchTowr Platform clients to rapidly react to this emerging threat and mitigate their exposure with Active Defense capabilities 24 hours before PHP published patches.

Every PHP installation that serves web requests is in scope, including PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP, and LiteSpeed, and PHP says the risk is highest on mod_php, where an attack can succeed before any application code runs. Session Upload Progress, a feature turned on by default, offers one confirmed path to CVE-2026-109619, so most default deployments meet that precondition. PHP has released fixed versions for every currently supported branch: 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

Security teams should prioritize internet-facing servers running PHP as an Apache module, since PHP identifies that configuration as carrying the highest demonstrated risk. Systems on PHP 8.1 or older no longer receive official PHP updates and need either a distribution backport or an upgrade to a supported branch.

These vulnerabilities were discovered by the incredible security research team at Calif, who have published the full research write-up.

Is PHP2Shell Being Exploited?

watchTowr has observed exploitation of both CVE-2026-109618 and CVE-2026-109619 in the wild.

Timeline

• October 20, 2026: After embargo leaks were observed, watchTowr publicly confirmed that the rumored PHP vulnerabilities were indeed real and that organizations should take them seriously. watchTowr was the first in the industry to do so.
• October 20, 2026: The PHP security team gave advance notice of a security release set for October 21, 2026, at 14:00 UTC covering two critical vulnerabilities, each rated CVSS v4.0 9.2, without naming CVE identifiers.
• October 20, 2026: watchTowr published a frequently asked questions page covering CVE-2026-109618 and CVE-2026-109619, noting that no vendor advisory had yet confirmed scope, cause or fixed versions.
• October 20, 2026: BleepingComputer reported PHP’s advance notice and said watchTowr identified the two issues as CVE-2026-109618 and CVE-2026-109619 and believed it had reproduced CVE-2026-109618.
• October 21, 2026: The UK NCSC published an alert urging organizations to update PHP immediately and to consider taking systems offline where they cannot be updated or mitigated in time.
• October 21, 2026: PHP published a security advisory naming CVE-2026-109618 as remote code execution via out-of-memory corruption and CVE-2026-109619 as remote code execution via stale global state, and released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 containing the fixes.
• October 21, 2026: heise reported that the disclosure, originally planned for October 22, was brought forward by a day after a leak, and listed the four fixed releases.
• October 21, 2026: watchTowr’s Attacker Eye honeypot network observed exploitation of CVE-2026-109618 and CVE-2026-109619 in the wild.

What Is PHP?

PHP is a server-side scripting language created in 1994 and built specifically for the web, which makes handling HTML, servers, and databases its natural strength.

It powers a huge range of applications: content management systems (CMS) like WordPress, Drupal, and Joomla, e-commerce platforms, internal business web apps, and APIs, often through frameworks like Laravel. Its most famous project is WordPress, which is built entirely on PHP and powers more than 43% of all websites on the internet.

As of mid-2026, PHP runs 70.8% of all websites whose server-side programming language is known, more than ten times the share of the next-closest language. That puts it on hundreds of millions of live systems worldwide.

Which PHP Versions Are Affected?

Is Your Deployment Of PHP Affected?

• Put simply: if you have not applied the update, your deployment of PHP is vulnerable.
• PHP’s Session Upload Progress feature, enabled by default, is one confirmed path to trigger CVE-2026-109619. It is not the only path to exploitation.
• Mitigations that involve changes to .ini files should be understood to be ineffective and not suitable to prevent exploitation.
• Check the PHP version that actually serves web requests, using phpinfo() output or your package manager. The command-line php binary can be a different version from the one PHP-FPM or Apache runs.
• Every installation that serves PHP web requests is affected, whether it runs under PHP-FPM, Apache mod_php, php-cgi, LiteSpeed or FrankenPHP.
• Apache’s mod_php configuration carries the highest demonstrated risk, since an attacker’s request can succeed before any application code runs.

What to Do About PHP2Shell?

The only complete fix is updating to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, matching the branch in use; PHP states no configuration change fully closes the vulnerability. Organizations on PHP 7.4, 8.0, or 8.1, which no longer receive official support, should use a distribution or LTS vendor package, use the security team’s minimal source backports, or move to a supported branch.

1. Preserve PHP and web server logs, configuration snapshots, and any suspicious files before making changes.
2. Check affected systems for new web shells, unexpected cron jobs, or newly created accounts tied to PHP processes.
3. Update every PHP installation to version 8.5.12, 8.4.27, 8.3.36, or 8.2.35, matching the branch in use.
   1. For PHP 7.4, 8.0 and 8.1, use a distribution or LTS vendor package or PHP’s minimal source backports.
4. Restart every PHP worker after installing the update so the fix takes effect across the environment.
5. Restrict internet access to PHP systems that cannot be updated immediately until the update can be applied.

The vendor advisories for CVE-2026-109618 and CVE-2026-109619 have full details and any later changes.

How to Check for Compromise

The UK National Cyber Security Centre advises organizations to inventory PHP systems, prioritize internet-facing ones, and monitor them for malicious activity while applying PHP’s updates. Where a system could not be updated straight away, the NCSC advises assessing it for evidence of compromise and looking for backdoors installed by an attacker before upgrading.

Both vulnerabilities are triggered by errors inside a request, so PHP and web server logs are a useful starting point. Look for unusually large or deeply nested multipart requests, PHP workers that crashed or hit their memory limit, and files written to web roots or outbound connections from PHP processes that you cannot explain.

How watchTowr Is Helping Clients

The watchTowr Platform delivers Preemptive Exposure Management, identifying, validating, and mitigating external exposure across enterprise environments.

• watchTowr Instinct assessed CVE-2026-109619 in real time at disclosure as highly likely to be exploited in the wild.
• Attacker Eye, our global honeypot network, is monitoring for exploitation activity as it emerges.
• Adversary Sight engine identified PHP instances across client environments and assessed exposure.
• Automated Red Teaming engine validated exploitability of affected instances using real-world attacker tactics and techniques.
• Rapid Reaction identified exposure to this vulnerability across the watchTowr client base, giving teams the time they need to act.
• Active Defense released targeted network-level mitigations to clients, enabling immediate risk reduction while permanent fixes are applied.

Request a demo to see how Rapid Reaction identifies exposure to emerging threats like CVE-2026-109618 & CVE-2026-109619.