HawkEye Advisory: PHP2Shell Critical PHP Remote Code Execution Flaws CVE-2026-109618 and CVE-2026-109619
A pair of critical vulnerabilities in PHP has moved from advance warning to an active patching priority within roughly 24 hours.
The flaws, CVE-2026-109618 and CVE-2026-109619, affect PHP itself rather than a specific CMS, plugin or web framework. Both carry a CVSS v4.0 score of 9.2 and can lead to unauthenticated remote code execution under vulnerable conditions. On 21 October, the PHP project released emergency security updates for supported branches and urged all users to upgrade immediately.
The timing matters. Details of the vulnerabilities leaked on 20 October before the planned coordinated disclosure. Within hours, researchers had begun validating the flaws, and by 21 October both Patchstack and Unit 42 were reporting exploitation activity.
For security teams, this should be treated as a rapid exposure, patch and hunt exercise, especially where PHP is reachable from the internet.
HawkEye Cyber Threat Intelligence is tracking vulnerability disclosures and security advisories such as this to help teams prioritize issues against the technologies they operate.
What Happened?
On 20 October, the PHP security team gave advance notice that two critical vulnerabilities would be addressed through an emergency release scheduled for the following day.
The announcement was unusually direct: both flaws were rated Critical at 9.2, and users were told to prepare for immediate upgrades. CERT-EU issued its own advisory shortly afterwards and recommended identifying PHP assets before the patches became available. PHP News
The PHP project has now released the following patched versions:
Branch | Patched version |
PHP 8.2 | 8.2.35 |
PHP 8.3 | 8.3.36 |
PHP 8.4 | 8.4.27 |
PHP 8.5 | 8.5.12 |
PHP states that installations serving web requests are at risk, including deployments using PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The project considers mod_php particularly exposed because a working unauthenticated attack has been demonstrated before application code needs to execute.
Organizations still running older unsupported PHP branches should not wait for a backported fix that may never arrive. The safer path is migration to a currently supported patched branch.
At a Glance
CVE-2026-109618 | CVE-2026-109619 | |
Flaw | RCE through out-of-memory corruption | RCE through stale global state |
Access | Network, no privileges, no user interaction | Network, no privileges, no user interaction |
Validated | RCE over HTTP against mod_php with default input and memory limits | RCE against mod_php and FPM |
PHP advisory |
Fixed in: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Affected: earlier builds of those branches, per both PHP advisories. PHP 8.1 and earlier are no longer supported by the project.
Who Is Exposed
PHP says all PHP installations serving web requests are at risk, including FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed, per Huntress’s summary. With mod_php, an unauthenticated request can trigger CVE-2026-109618 before any application code runs. FPM is a confirmed path for CVE-2026-109619 and a source-analysis candidate for CVE-2026-109618.
Unit 42 counted over 22.6 million internet-exposed instances potentially vulnerable, using Cortex Xpanse telemetry, and reports at least one European government took a website offline as a precaution. Bundled PHP matters too: Huntress and the UK NCSC both point to appliances and vendor software that ship their own PHP, and Huntress adds control panels.
CVE-2026-109618: Remote Code Execution Through Memory Corruption
The first vulnerability, CVE-2026-109618, involves how PHP responds to out-of-memory conditions.
PHP uses longjmp() in certain memory-exhaustion situations to abort request handling. Researchers found that an allocation failure can occur while request memory is still in an incomplete state. PHP can then continue shutdown processing against invalid memory, creating conditions that can be shaped into remote code execution. The PHP advisory confirms unauthenticated RCE as the impact. Full exploitation was validated over HTTP against Apache mod_php using normal configurations. Other execution models can also be exposed, although the exact conditions and reliability differ.
The important point for defenders is that this is a PHP runtime problem.
Updating WordPress, Drupal, Magento or Laravel does not patch the vulnerable PHP interpreter underneath them.
CVE-2026-109619: Stale State Survives Between Requests
The second flaw, CVE-2026-109619, concerns state retained by persistent PHP workers.
Certain error, session or extension data can continue referencing memory that belonged to a previous request. Once that memory has been released, a later request may interact with the stale reference before normal initialization resets it.
That creates a use-after-free condition which can ultimately produce remote code execution.
The vulnerability is particularly concerning because the producing event and the later trigger can occur across separate requests handled by the same worker.
PHP’s advisory is clear on remediation: updating to a release containing the complete fix is the only reliable mitigation. Configuration changes can reduce individual attack paths but do not close the entire vulnerability.
Why PHP2Shell Has a Large Potential Blast Radius
The nickname PHP2Shell has circulated since the vulnerabilities leaked, and the reason for the attention is straightforward.
PHP sits underneath an enormous number of public-facing applications. The vulnerable component may be present even when application owners do not think of themselves as running a “PHP server.”
Common exposure points include:
- WordPress and other CMS platforms
- ecommerce applications
- customer portals
- shared hosting environments
- internally developed PHP applications
- appliances or vendor products with embedded PHP components
This makes asset discovery as important as patch deployment.
Unit 42 reported identifying more than 22.6 million exposed instances potentially affected through its internet telemetry. It has also reported exploitation in the wild. Unit 42
The figure should not be interpreted as 22.6 million confirmed vulnerable systems, but it illustrates how broad the search surface can be.
HawkEye Recommended Actions
Security teams should prioritize internet-facing PHP systems first.
- Identify every PHP deployment.
Include public websites, forgotten applications, development servers and vendor-managed systems. Check the underlying runtime rather than relying on the application version alone. - Patch immediately.
Upgrade to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, depending on the branch currently deployed. Restart PHP workers and web services after the upgrade so vulnerable worker processes are not left running. - Treat unsupported PHP as a separate remediation problem.
Older branches that do not have a supported security release should be migrated rather than left exposed behind temporary configuration changes. - Reduce exposure where patching cannot happen immediately.
CERT-EU recommends isolating affected internet-facing applications where immediate remediation is impossible. - Hunt for post-exploitation behaviour.
Pay particular attention to PHP or web-server worker processes spawning shells, interpreters or unexpected download utilities. Review for new files in web roots, persistence mechanisms, suspicious scheduled tasks and unauthorized accounts. Huntress highlighted these behaviours as useful indicators while teams investigate possible PHP exploitation.
HawkEye CSOC & XDR provides continuous monitoring, threat hunting and incident triage across endpoint, infrastructure and network telemetry, which is particularly important where exploitation can use legitimate web-server processes as its starting point.
Patching Is Only Half the Response
When a critical internet-facing RCE becomes public, the response should not end once the server reports a patched PHP version.
There is now a period between the disclosure leak and remediation during which vulnerable systems may have been reachable.
Organizations with exposed PHP assets should therefore ask whether exploitation occurred before the patch was installed.
That means preserving web-server and PHP logs, reviewing process telemetry and checking for persistence or unexpected changes. Systems showing suspicious activity may require isolation and deeper compromise assessment rather than simply returning them to production.
HawkEye Managed CSOC and XDR combines continuous monitoring with managed threat detection and incident response capabilities to help organizations investigate this type of exposure and determine whether a vulnerability remained only a risk or became an intrusion.
Conclusion: Treat PHP2Shell as a Patch-and-Hunt Event
CVE-2026-109618 and CVE-2026-109619 deserve immediate attention because the vulnerable component sits beneath many internet-facing applications and successful exploitation can lead directly to code execution without prior authentication.
The patches are now available. The priority is therefore clear: find vulnerable PHP installations, update them and investigate systems that were exposed before remediation.
The leak ahead of coordinated disclosure compressed the normal defensive window, while reports of active exploitation mean organizations should avoid treating this as a routine monthly patch.
For teams already using HawkEye AI SOC, the operational focus should be on rapid alert triage, correlation of suspicious web activity with endpoint behaviour and escalation of any evidence that a PHP worker moved beyond its expected role.
For PHP2Shell, knowing that an asset was vulnerable is the first question. Knowing whether somebody reached it before you patched is the one that matters next.