PHP2Shell Intruder Reached Government MFA Secrets in Two Hours

Unit 42’s October 25 correction retracts its attribution of a European government intrusion to PHP2Shell. It saw an attack in the context of a vulnerable PHP application but cannot confirm that initial access used either CVE-2026-109618 or CVE-2026-109619. Both flaws remain real; this case does not establish their use.

For operators of exposed PHP applications, the urgent work now has two parts: get the fixed PHP build into the running web worker, and look for activity between the first exposure and that replacement. Unit 42’s current PHP2Shell report no longer presents the case-specific agentic and government website details as evidence of either CVE. Investigate worker anomalies without assigning their cause from that withdrawn account.

Two PHP failures across requests

The PHP Group’s October 21 advisory in its release archive says installations serving web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php: its demonstrated unauthenticated request can reach the flaw before application code runs. Both CVEs have a 9.2 CVSS 4.0 score. These are worker-memory failures, so an application-level input check alone is an incomplete answer.

In CVE-2026-109618, out-of-memory handling uses longjmp() to abort a request; cleanup can then read partially initialized request memory. In CVE-2026-109619, global state can keep a pointer into memory that was freed at the end of a request, and a later request on that worker can encounter the stale pointer. The PHP project says both paths can lead to remote code execution. A worker reused across requests is the important unit to replace when patching.

PHP fixed both flaws in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Distributions and long-term-support vendors may supply backported packages; for their builds, use the vendor’s patch status rather than the upstream version string alone. PHP 8.1 and older have no regular project updates. PHP’s security team supplied minimal source backports for 7.4, 8.0 and 8.1, while recommending a supported release or vendor-maintained fix.

A web worker led inward

Unit 42 saw the government attack in the context of a vulnerable PHP application but cannot confirm that either PHP2Shell CVE supplied initial access. Its current report no longer presents the earlier web-shell delimiters, credential timeline or identity-system sequence as evidence of these CVEs. A suspicious PHP worker still needs investigation; determine its actual entry route rather than assigning these CVEs by association.

Unit 42 estimates that Cortex Xpanse saw more than 22.6 million exposed instances potentially vulnerable at publication. Palo Alto Networks also evaluates its own defenses in the report: it lists Cortex hunts and firewall signatures, including Threat ID 543004. Those are vendor product claims; updating PHP remains the PHP project’s complete fix.

Hunt from the PHP worker

Before changing the host, preserve available web request, process-start and identity logs for the exposure window. In endpoint process telemetry, look for a shell or other new child process whose parent or causality chain is apache2, httpd, php-fpm, php-cgi, lsphp or w3wp.exe. Unit 42 publishes a Cortex XQL hunt organized around that parent-child relationship, then groups recon, downloads, writable-directory execution, interpreter use and credential access on the same host and service account. Its authors warn that the query covers other web-app compromises and can return legitimate application work: examine the command line, account, origin and corresponding web requests before assigning a cause. Correlate suspicious child-process commands with originating web requests and retained artifacts; the earlier case-specific delimiters are no longer present in Unit 42’s PHP2Shell report.

Patch every serving PHP worker and its deployed image or vendor package, then restart the workers so old processes stop handling requests. Confirm the build reported by the running web service or its deployed package and map it to the PHP project’s fixed release or your vendor’s backport notice. The PHP project says “updating is the only safe choice.” Its interim memory_limit=-1 guidance reduces the controllable OOM path but underlying allocation failures remain; disabling session.upload_progress.enabled before parsing and restarting workers blocks confirmed session paths for the second flaw, while other variants still require the upgrade. When the service cannot be patched immediately, limit its exposure and arrange the upgrade rather than treating either setting as a fix. The separate PHP upload-progress advisory covers the unusual configuration and application-code combination announced on October 23.

Verify PHP and credential recovery

For a server with suspicious worker-child processes, isolate the host and investigate the affected identity accounts. Review access to password hashes and MFA secrets, NTLM relay activity and changes to privileged group membership; rotate exposed secrets and reset or re-enroll affected credentials through the incident process. Then compare process-start and web logs against the period the vulnerable worker was reachable. A clean current version answers the patch question; historical telemetry and credential-access review answer the intrusion question.

The practical test is specific: after the rollout and worker restart, each serving worker should map to a fixed release or vendor-backported build, and process telemetry should show no unexplained command execution under the web-service account. If the earlier window includes unexplained child processes, handle them as incident leads even when the live worker is patched.