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 21, 2026

What Is PHP2Shell?

CVE-2026-109618 & CVE-2026-109619 are Remote Code Execution vulnerabilities in PHP, the scripting language many web servers use to run applications. It stems from stale internal data that survives after its memory is freed; a later request handled by the same worker can use that leftover data, and PHP confirms this 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 reproduced one of the flaws.

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 the problem, 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.io.

Is PHP2Shell Being Exploited?

watchTowr is observing active exploitation attempts of both CVE-2026-109618 and CVE-2026-109619.

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 21 October 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 organisations to prepare to update PHP immediately and to consider taking systems offline where immediate remediation is not possible.
• October 21, 2026: PHP published a security advisory naming 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 22 October, was brought forward by a day after a leak, and listed the four fixed releases.

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 is used by 70.8% of all the websites whose server-side programming language we know – more than ten times the share of the next-closest language – meaning it runs 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 patch, your deployment of PHP is vulnerable
• ]PHP’s default-enabled Session Upload Progress feature provides one confirmed path to trigger the vulnerabilities however, it is important that this 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.
• Every installation that serves PHP web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.
• 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 the security team’s 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.
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 advisory has 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 as they become available.

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.