Most people know CrowdStrike for its EDR capabilities. The Falcon ecosystem, however, is a comprehensive security platform that brings endpoint protection together with Next-Gen SIEM, Exposure Management and threat intelligence. When a critical vulnerability emerges, this integration matters: it helps an organization identify its affected assets, investigate exploitation signals and respond as the attack progresses. The real PoC test we ran against the PHP2Shell vulnerability shows, with concrete logs, how these capabilities complement each other in the same scenario.
A vulnerability on an internet-facing web server makes business applications, the data those applications can reach and the server’s relationship with the corporate network part of the same investigation. That is why the security team needs to scope the problem quickly after a vulnerability is announced. Without knowing which systems run PHP, whether they are exposed to the internet, which version they use and whether they are covered by protection, prioritization remains incomplete. Once an attack begins, web logs and endpoint telemetry must be read together.
PHP2Shell is an example that makes this need visible. When assessing a vulnerability in the PHP core, the application inventory, runtime behavior and activity on the OS have to be considered together. A memory exhaustion signal in the web server’s error log, a command interpreter launched under PHP and a vulnerability finding reported for the same server each answer a different question. The analyst’s job is to connect these logs and establish which attempt took place, which behavior was blocked and which risk remains.
At InfinitumIT, we ran controlled tests using a real Proof of Concept (PoC) for the PHP2Shell vulnerability. We examined the logs produced by the exploitation activity in CrowdStrike Next-Gen SIEM, the detections and blocks for post-exploitation activity on the Endpoint Security side, and the Network Vulnerability Scanning results in Exposure Management. This let us evaluate, for the same target, both the evidence generated during the attack and the findings on its vulnerability status.
This approach reflects the operational value of running MDR, threat intelligence, Vulnerability Management and Purple Team work together under the InfinitumIT CROC service. Identifying affected systems early, validating detection content and responding to post-exploitation activity all help manage the risk until patching is complete. In the rest of this article, we walk step by step through the logs generated in our real PoC test and the results the Falcon ecosystem produced along the attack chain.
Scope of the PHP2Shell vulnerability and the test environment
CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell, are two critical vulnerabilities in the PHP core that, under the right conditions, can enable unauthenticated Remote Code Execution (RCE). Both have been assigned a CVSS score of 9.2. The issue is not limited to a particular CMS or plugin running on PHP. The PHP runtime that processes the web request and its configuration are what determine exposure.
CVE-2026-109618 relates to partially prepared request data being left in an invalid state during memory exhaustion. CVE-2026-109619 relates to stale global state that survives after the memory allocated for a request has been freed, which can lead to use-after-free behavior during a subsequent request. In both cases, memory management behavior beneath the application layer is what matters.
A separate analysis covering the root cause and the affected PHP structures has been published by our InfinitumIT Purple Team. In this article, our focus is on the traces the real PoC test left on the defensive side and what they mean operationally.
The scenario validated with a real PoC
The tests targeted a Windows server named INFNT-LAB-SRV01. Process logs showed php-cgi.exe instances running under both Apache and IIS. After the exploitation activity performed with the PHP2Shell PoC, command execution and file transfer behaviors were attempted in the web server context. This allowed the initial access signal and the OS activity in the post-exploitation stage to be evaluated together.
| Component | Test scope |
|---|---|
| Attacker system | PoC client, represented in the scenario by the address 192.168.120.30 |
| Target system | Windows web server environment on INFNT-LAB-SRV01 |
| Web and PHP components | Apache httpd.exe, IIS w3wp.exe and php-cgi.exe; PHP 8.3.35 in the vulnerability list |
| Monitoring and protection | Falcon Insight process telemetry and IOA logs; Next-Gen SIEM log correlation |
| Exposure check | Network Vulnerability Scanning via Exposure Management |
This work is a test performed using the PHP2Shell PoC. It is not an independent measurement of exploit success rates for each of the two CVEs. The assessment is based on the behaviors tested and the results observed in Falcon.
Preparing the log flow for Next-Gen SIEM
To investigate the traces of PHP2Shell’s exploitation stage, the web server’s error logs were forwarded to Next-Gen SIEM. A connection named Lab Test was configured as a Push type connection for the Apache Httpserver product, using the apache-httpserver parser and a repository of the same name. Its Active status and visible data ingestion confirmed that the log flow was working during the test.
This flow complements the process telemetry the Falcon sensor collects from the endpoint. The error raised while the PHP request is processed can be investigated in the Apache logs, while command execution and prevention results can be tracked in the endpoint logs. Dashboards and correlation rules that depend on these logs should not be expected to produce results until third-party log ingestion is in place.
Detecting memory exhaustion during request startup
During the test, the correlation rule provided by CrowdStrike, “Generic - Web - PHP Memory Exhaustion During Request Startup (CVE-2026-109618 & CVE-2026-109619)”, generated a detection. The detection was shown with Medium severity and with the tactic and technique information Initial Access via Exploit Public-Facing Application.
What sets the rule apart is that it looks for a narrower pattern than an ordinary PHP memory error log. A memory exhaustion message appearing together with “in Unknown on line 0” points to an error that occurred during request startup, before a normal application script context was established. This pattern is valuable for investigation, but on its own it does not confirm that successful command execution took place.
Examining the exploitation activity through logs
The Event summary of the alert shows the log source the detection is based on.
The error contains a PHP Fatal error message produced by php-cgi.exe. The PHP memory limit seen in the log was 134217728 bytes, or 128 MiB. The “Unknown on line 0” part of the message is the core signal for the correlation rule used in this work.
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
... in Unknown on line 0What is being tracked here is the error log the PHP runtime leaves behind while processing the request. A web request looking ordinary in the access log, or not directly producing a High severity EDR alert, does not diminish the importance of this error signal. The analyst should consider the error log together with the client IP address, the target server and recent process activity.
When a similar match appears in a production environment, the request that caused the error and repeated attempts from the same source are examined first. Next, command interpreter processes launched under PHP or the web server, unexpected network connections and file write activity are investigated. In this test as well, the meaning of the log signal was evaluated together with the process logs covered in the following sections.
Emerging Threat Response dashboard findings
The Emerging Threat Response dashboard in Next-Gen SIEM presents the logs collected for PHP2Shell in a single view. The PHP Memory Exhaustion Events counter shows three events related to the incident. The timeline chart and the detailed log table make it easier to investigate the memory exhaustion logs from the same test.
An event count on the dashboard does not mean that three separate successful breaches occurred. The number reflects the events that matched the query within the selected time range and data sources. These three logs show the memory exhaustion events generated during our PoC test.
An empty dashboard does not by itself prove that the environment is unaffected. Data source coverage, whether the parser produces the expected fields, the time range and whether the relevant content is enabled must all be verified together. In our test, the active Apache connection and the raw error logs support the dashboard findings.
Post-exploitation blocks on Apache
In one of the controlled attempts in the post-exploitation stage, a command intended for file transfer was executed through the PHP process running under Apache. The process tree shows httpd.exe instances under services.exe, followed by php-cgi.exe and cmd.exe. This relationship is one of the key findings for establishing that the command came from the web server context. The log below shows the endpoint block against this post-exploitation activity.
The command line was intended to call certutil.exe through cmd.exe to download x.txt from an HTTP address to C:\Windows\Temp\lab_x.txt. Although certutil is a legitimate Windows component, attackers can also use it for file transfer. In this assessment, the fact that the command was launched under PHP and its link to a web request matter as much as the command itself.
Falcon associated this activity with the PublicFacingAppExploitation IOA, with High severity and technique T1190. The Action taken field on the details screen showed Process blocked. This log shows that the tested post-exploitation command was blocked.
The observed action applies to the cmd.exe behavior in question. This result does not mean that the root cause of the memory corruption issue in PHP has been fixed, or that every possible PHP2Shell variant is stopped at the initial HTTP request stage. The block on the endpoint is the defensive layer that limits the attack’s progress on the OS.
From the MDR analyst’s perspective, the investigation at this stage continues with two questions: whether the file transfer completed, and whether any other file or process was created earlier. An incident should not be closed by looking only at the blocked command. Recent activity of PHP and the web server must be assessed together.
Post-exploitation blocks on IIS
The second example examines the block against reconnaissance (recon) activity performed as part of post-exploitation. The process tree in the IIS application pool context showed svchost.exe, w3wp.exe, php-cgi.exe and cmd.exe. The log is associated with the DefaultAppPool user, so in addition to the Apache example, post-exploitation behavior produced by PHP running on IIS was also observed.
In this attempt, the following command was run through cmd.exe. It queries the Domain Admins group in the domain. Launching it from the web application pool context shows reconnaissance activity outside normal web request handling.
net.exe group "Domain Admins" /domainFalcon flagged the activity with the ReconCommands IOA at High severity and raised an alert. The Process blocked result in the Action taken field confirms that this remote command execution (RCE) attempt was blocked.
This detection does not indicate that the Domain Admins group was successfully enumerated or that privilege escalation occurred. The valuable finding on the defensive side is that an operating system command launched through the PHP runtime is visible together with its root process, and that it can be acted on in the post-exploitation stage after PHP2Shell.
Assessing SIEM and endpoint detections within the same case
In the Falcon Next-Gen SIEM interface, correlation logs from Apache and EDR detections from endpoint security appear together. This view provided a common starting point for investigating the transition from the error signal in the exploitation stage to post-exploitation activity.
In the Workbench view of the case created for the incident in Next-Gen SIEM, named INFNT-LAB-SRV01 PHP2Shell Exploitation, the web detection is linked to the target server and user contexts. The cmd.exe logs seen under DefaultAppPool and the server account are examined together with IOAs such as ReconCommands and PublicFacingAppExploitation.
The list also includes additional detection names such as ApexCloudDetectMedium, ApexCloudDetectHigh and ApexCloudDetectLowest. Because the same process or behavior can be flagged by more than one mechanism, the alert count should not be read as the number of separate attacks. The Workbench correlation supports the analysis.
Network Vulnerability Scanning with Exposure Management
In addition to visibility into attack behavior, the target system’s vulnerability status was assessed through Exposure Management. A vulnerability scan named “INFNT-LAB Php2Shell Vulnerability Scan” was run under Network scanning.
The network vulnerability scan took 36 minutes and 3 seconds. It ran only against the INFNT-LAB-SRV01 web server in the test scope and reported a total of seven vulnerability findings, four of which are related to PHP2Shell.
Checks performed in the CrowdStrike Exposure Management / Vulnerabilities panel show the PHP2Shell vulnerabilities for the INFNT-LAB-SRV01 server. Both CVEs show a Critical CVSS and ExPRT rating, a risk score of 73/100 and a Vulnerability confidence value of Potential.
Test results and priority actions for organizations
In this work with a real PHP2Shell PoC, we found answers to three different security questions. Next-Gen SIEM made the exploitation signal on the web server visible. Falcon Insight made the suspicious commands launched under PHP visible along with their process relationships, and a Process blocked action was seen in two examples. Exposure Management linked the target’s PHP version to the two CVEs, helping track its vulnerability status.
| Layer | Observed result | Operational meaning |
|---|---|---|
| Exploitation signal | Three PHP Memory Exhaustion events | Investigation through request and error logs |
| Post-exploitation file transfer | PublicFacingAppExploitation; Process blocked | Post-exploitation file transfer attempt blocked |
| Post-exploitation reconnaissance | ReconCommands; Process blocked | Post-exploitation reconnaissance attempt blocked |
| Network Vulnerability Scanning | Seven findings in total on one asset; two PHP2Shell CVEs | Exposure confirmed and patching prioritized |
Scope and update priority
Identify the web servers covered by EDR, compare them with the organization’s inventory and verify any web and PHP systems left outside coverage. Prioritize internet-facing systems.
Verify the PHP version that actually handles web requests; assess separate installations on the same server, IIS FastCGI definitions, application pool configurations and container images individually.
On supported branches, update to at least PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and separately verify distribution vendors’ backported patches. After updating, restart the relevant workers and services and check the running version.
Verify Falcon sensor health, prevention policies and the web server log flow, and test correlation rules against real logs.
Perform retrospective threat hunting for the pre-patch period; investigate suspicious child processes, file writes and outbound connections, and rescan after remediation.
Although the general remediation advice on screen points to PHP 8.5.12 or later, the fixed minimum for the 8.3.35 branch listed in the test is 8.3.36. Patch decisions should be based on the branch in use and the vendor’s security advisory. A successful block on the endpoint is not a substitute for updating PHP.
Early prevention and response with InfinitumIT CROC
For a vulnerability with as broad an impact as PHP2Shell, the first task of security operations is to determine which of the organization’s systems are at risk. In the InfinitumIT CROC service, handling MDR, SOC, threat intelligence, Vulnerability Management and Purple Team validation within the same operation reveals the concrete impact of an announced vulnerability on the organization sooner.
The MDR team reviews web server processes and protection coverage using EDR telemetry. Comparing this with the organization’s application inventory reveals servers without a sensor or outside monitoring coverage. Internet exposure, PHP version and the server’s business criticality are assessed together to set the priority of checks.
Threat intelligence and Vulnerability Management work helps turn new information into a list of affected assets. Version and service findings from capabilities such as Network Vulnerability Scanning are verified, shared with those responsible for patching, and the remediation process is tracked. This goes beyond simply issuing a CVE notice and makes clear which action the organization will take on which asset.
On the detection side, MDR and SOC make sure that web and PHP error logs reach the SIEM, that correlation content works and that prevention policies on endpoints are applied with the right scope. When an alert fires, the analyst combines the error log with the process tree and command line on the same server. Response, evidence preservation and customer communication are carried out according to the scope of the incident.
Purple Team tests show how these controls hold up against real attack behavior. The real PHP2Shell PoC used in this work also allowed us to evaluate log collection, correlation and endpoint blocking in the same scenario.
The value we see in this scenario is the ability to bring exposure information and attack evidence into the same investigation. For the organization, the goal is to identify the affected system early, investigate the exploitation signal, limit the attack’s progress and complete the operation by verifying the patch status, which is the permanent fix.
Related analyses and technical references
- PHP security announcement and fixed versions
- PHP security advisory: RCE via OOM corruption
- PHP security advisory: RCE via stale global state
- InfinitumIT Purple Team technical analysis of PHP2Shell
Hakan Aksungur
InfinitumIT MDR
