PHP2Shell Explained: CVE-2026-109618 and CVE-2026-109619
Understand how two critical PHP flaws can become unauthenticated remote code execution, which web runtimes are exposed, and why immediate patching matters.
PHP2Shell Response Series
Move from understanding the vulnerability to patching and verifying PHP shipped with Plesk.
In This Lesson
Build a defensive mental model of both vulnerabilities, identify affected PHP web runtimes, separate confirmed vendor facts from evolving threat intelligence, and choose the safest response.
Quick Learning Map
Keep the response simple: find reachable PHP, install a trusted fixed build, then verify and investigate.
Inventory
Find every PHP runtime serving web requests, especially public-facing Apache mod_php systems.
Patch
Move supported branches to the fixed release and obtain trusted backports or upgrades for EOL branches.
Validate
Confirm the running binary and build, restart workers where required, monitor logs, and investigate suspicious behavior.
PHP2Shell at a Glance
Both flaws sit in PHP request handling and can be reached without authentication. The exact mechanism differs, but the operational answer is the same: patch every PHP runtime that serves web traffic.
PHP2Shell Incident Snapshot
Severity
Critical, CVSS v4.0 9.2 for both CVEs according to the PHP release announcement.
Access required
None. A remotely reachable attacker can target vulnerable request handling without first logging in.
Observed activity
Exploitation attempts reported by watchTowr. This is separate from CISA KEV status.
PHP2Shell is a convenient industry label, not a separate product or malware family. It refers to CVE-2026-109618 and CVE-2026-109619.
What PHP Is and Why the Exposure Is Broad
PHP is a server-side scripting language used to generate dynamic websites, APIs, content-management systems, e-commerce services, and internal business applications. A web server hands a request to a PHP runtime, which executes application code and returns the response.
That placement makes a runtime vulnerability unusually important. The affected PHP process can sit beneath WordPress, Drupal, Joomla, Laravel, custom applications, and hosting control panels. Updating the application alone does not repair a flaw in the PHP engine that executes it.
How the Two Vulnerabilities Differ
Both issues can produce remote code execution, but they arise from different failures in PHP's internal request lifecycle.
CVE-2026-109618: OOM corruption
Out-of-memory handling can interrupt PHP while internal request data is only partly initialized. Cleanup may later treat invalid data as trustworthy state, opening a path to code execution.
CVE-2026-109619: stale global state
Request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may reuse that stale state before normal initialization resets it.
Why both matter
These are engine-level request-handling flaws. Application authentication, framework validation, or a fully patched CMS cannot compensate for an affected PHP runtime underneath.
mod_php as the highest-risk configuration demonstrated so far because the attack can run before application code. PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are also in scope.Defensive Attack Path
- Reach a PHP web endpointAn attacker sends a crafted HTTP request to an internet-facing service using a vulnerable PHP runtime.
- Trigger vulnerable request handlingThe request exercises an affected out-of-memory or stale-state path inside the PHP engine.
- Cross the application boundaryBecause the flaw is in the runtime, exploitation may occur before normal application controls can help.
- Execute code in the worker contextSuccessful exploitation can provide server-side code execution with the privileges of the PHP or web-server process.
- Expand impactAn intruder may access application secrets and data, establish persistence, move laterally, or alter hosted content.
This intentionally stays at a defensive level. Detection and remediation do not require reproducing the exploit on production systems.
Affected and Fixed PHP Versions
All PHP installations serving web requests should be treated as in scope until the installed package is confirmed to contain the fix. For currently supported upstream branches, use these minimum versions.
| PHP branch | Affected releases | Fixed release | Action |
|---|---|---|---|
| PHP 8.5 | 8.5.11 and earlier | 8.5.12 | Update immediately |
| PHP 8.4 | 8.4.26 and earlier | 8.4.27 | Update immediately |
| PHP 8.3 | 8.3.35 and earlier | 8.3.36 | Update immediately |
| PHP 8.2 | 8.2.34 and earlier | 8.2.35 | Update and plan the next supported branch |
| PHP 8.1 and older | Upstream EOL branches | Trusted vendor backport or supported-branch upgrade | Do not infer safety from the version string alone |
Exploitation Status and Timeline
October 20, 2026 — advance warning and leak
The PHP security team announced an emergency security release for two critical CVSS 9.2 vulnerabilities. Details also appeared publicly before the planned coordinated disclosure.
October 21, 2026 — fixes released
PHP published its advisory and released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 at 14:00 UTC. The project stated that updating is the only complete solution.
October 21–22, 2026 — active response
watchTowr reported observing exploitation attempts. Plesk then published fixed PHP packages and fixed sw-engine updates for supported Plesk Obsidian branches.
How watchTowr says it is helping customers
In its dated PHP2Shell briefing, watchTowr says its Adversary Sight capability identified PHP instances and assessed exposure, Rapid Reaction highlighted affected customer assets, and Active Defense supplied network-level mitigations while permanent fixes were being applied. These are vendor claims and temporary protective services; they do not replace PHP or Plesk updates.
There is no public attribution in the supplied reporting. Do not wait for a named threat actor or a CISA KEV entry before patching a critical, remotely reachable RCE.
Immediate Response Priorities
- Inventory all PHP web runtimes: include PHP-FPM pools, Apache
mod_php,php-cgi, FrankenPHP, LiteSpeed, containers, appliances, and control panels. - Prioritize public Apache modules: PHP describes
mod_phpas the highest demonstrated risk, but do not exclude other SAPIs. - Install a trusted fixed build: use upstream PHP, your Linux distribution, Plesk, or an accountable lifecycle-support vendor.
- Restart affected workers: make sure long-lived workers actually load the new binary and clear vulnerable in-memory state.
- Validate from the running environment: record version, package/build provenance, handler, restart time, and application health.
- Hunt for compromise: review web, PHP, WAF, EDR, process, authentication, and outbound-network telemetry for anomalies.
- Isolate suspicious hosts: preserve evidence and investigate rather than assuming the patch removes an existing foothold.
Authoritative and Dated Sources
- PHP security advisory and fixed releases — technical mechanisms, affected runtimes, update versions, and temporary exposure-reduction guidance.
- Plesk vulnerability advisory — Plesk package and
sw-enginebuild status. - watchTowr PHP2Shell briefing — third-party active-exploitation reporting and disclosure timeline.
- CISA KEV catalog — live government catalog status; verify it again during every response cycle.
Next: continue to Part 2: the Plesk patching and verification runbook.
PHP2Shell Frequently Asked Questions
What is PHP2Shell?
PHP2Shell is the industry name used for CVE-2026-109618 and CVE-2026-109619, two critical PHP vulnerabilities that can permit unauthenticated remote code execution when PHP handles web requests.
Are CVE-2026-109618 and CVE-2026-109619 being exploited?
watchTowr reported observing active exploitation attempts for both vulnerabilities. As of October 22, 2026, the supplied status information did not show either CVE in CISA KEV; check the live catalog because that status can change.
Which PHP versions fix PHP2Shell?
The PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 with the fixes. Older branches need a trusted vendor backport or migration to a supported release.
Can a configuration change fully mitigate PHP2Shell?
No. PHP states that no complete mitigation exists and updating is the only safe solution. Temporary controls can reduce particular attack paths but do not make an affected installation safe.
Which PHP runtime has the highest demonstrated risk?
PHP identifies Apache mod_php as the highest demonstrated risk because an unauthenticated request can trigger the attack before application code runs. PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are also in scope.