When PHP2Shell emerged, checking versions and configurations was essential, but it could not tell us whether exploitation had been attempted or what happened afterwards. This is how we turned a critical vulnerability alert into a measured investigation and four high-signal, monitor-only SentinelOne detections.

What happened?

On 21 October 2026, the PHP project released emergency fixes for two critical vulnerabilities in the PHP runtime:

• CVE-2026-109618, involving memory corruption when an out-of-memory condition interrupts request processing while internal data is only partially initialised.
• CVE-2026-109619, involving request state that can remain after its underlying memory has been freed and be reused by a subsequent request.

Both vulnerabilities can lead to unauthenticated remote code execution under the right conditions. The PHP project rated them Critical at CVSS 9.2 and released fixed versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. It considered Apache mod_php to present the highest risk because exploitation had been demonstrated before application code began executing, while other PHP serving models had different conditions and levels of validation.^[1][2][3]

Defenders had good reason to move quickly. Amazon reported exploitation attempts against its honeypot network from 17 October, before public disclosure, although it cautioned that it was unclear whether those attempts would have succeeded against real systems.^[4]

On 26 October, CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalogue. A KEV listing establishes evidence of exploitation in the wild; it does not mean every vulnerable organisation was attacked or compromised.^[5]

A third issue, CVE-2026-115560, was disclosed separately on 23 October. It is not one of the two PHP2Shell vulnerabilities and was not fixed by the 21 October releases. PHP described it as an unlikely remote-code-execution vector requiring an unusual combination of configuration and application behaviour:

1. session.serialize_handler is configured as php_binary or php_serialize;
2. the application changes it to php at runtime before calling session_start(); and
3. session upload progress remains enabled.

Pending a regular bug-fix release, PHP advised affected organisations to set session.upload_progress.enabled=0 and restart the relevant workers. Applications that never change the serializer in this way are not exposed to this specific vector.^[6]

These distinctions matter. A vulnerable version is not proof of a reachable configuration. A reachable configuration is not proof of an exploitation attempt. An attempted exploit is not necessarily successful. Suspicious behaviour on an endpoint may be consistent with post-exploitation, but it is not by itself proof that a particular CVE supplied the initial access.

Why a version check was necessary but insufficient

The first response had to be conventional vulnerability management:

• Find every PHP runtime, including containers and less obvious application bundles.
• Identify the effective web-serving runtime rather than relying only on the command-line version.
• Establish the SAPI and configuration in use: PHP-FPM, mod_php, CGI, LiteSpeed or FrankenPHP.
• Check for vendor security backports where the package version may not match PHP's upstream release number.
• Patch to a fixed upstream or vendor-supported build.
• Restart the affected workers so the fixed runtime and revised configuration are actually loaded.
• Review the separate prerequisites for CVE-2026-115560.

That work answers an exposure question: could this system be vulnerable?

It does not answer the incident question: did someone exploit it, and what did the process do next?

A server can be patched today but still require investigation for activity that occurred before the patch. Conversely, a scanner can report an old-looking package version even though a Linux or long-term-support vendor has backported the security correction. Version evidence therefore needs package provenance, runtime verification and configuration context.

This is where endpoint telemetry can add value, provided it is used for the questions it can genuinely answer.

Starting with behaviour, not a supposed exploit signature

SentinelOne STAR rules operate on endpoint telemetry. They are well suited to identifying process creation, file creation and network activity. They do not inherently see every HTTP body, malformed multipart request or web-server response.

We therefore chose not to build a rule claiming to detect "PHP2Shell exploitation". That would have overstated what the available data could establish.

Instead, we asked a narrower question:

If a PHP web worker were successfully compromised, which follow-on behaviours would be sufficiently unusual to justify investigation?

The initial hypotheses included:

• a PHP or web-server worker starting a command shell;
• a web worker writing an executable server-side script into a served upload directory;
• a PHP worker starting a utility capable of downloading a payload; and
• a shell started by PHP opening a network connection.

These behaviours do not identify a particular vulnerability. They can follow PHP2Shell, exploitation of a vulnerable application or plug-in, stolen administrative access, or an unsafe application feature. That lack of CVE specificity is a strength: the detections remain useful beyond one emergency.

Why the first queries were rejected

The first Deep Visibility queries were intentionally broad. Their purpose was to measure the environment, not to become production rules unchanged.

That baseline quickly showed why process names alone were not enough.

Legitimate PHP applications can start shell scripts for maintenance, monitoring, backups, deployment and control-panel operations. Application arguments and temporary build paths can also contain weak textual indicators such as curl without executing a download. Even supposedly suspicious strings can appear inside opaque tokens or application data.

A broad "PHP started a shell" search produced substantial legitimate activity in some scopes. A generic upload-directory rule also matched legitimate application upgrades because a vendor library happened to contain a directory named Upload.

Those candidates were rejected.

This tuning stage is important. A detection that produces a large volume of predictable legitimate alerts does not merely inconvenience analysts. It conceals the event the rule was meant to highlight and encourages overly broad exclusions.

We refined the logic by:

• concentrating on direct parent-and-child process relationships;
• requiring high-signal command content for Unix shells;
• retaining direct launches of shell-capable networking and scripting utilities;
• excluding common generic child processes from the main rule;
• restricting file detections to executable server-side script types written to actual served upload locations;
• separating shell, file-write, download and network behaviours so each could be tuned independently; and
• avoiding global exclusions for PHP, Apache, destinations or entire server roles.

The final historical hunts produced no matches for the refined conditions in the retained telemetry across the searched consoles. That was useful baseline evidence, but it was not proof that no exploitation had occurred. Request-only activity, missing telemetry, memory disclosure, alternative post-exploitation techniques and activity outside the retention window remained outside that conclusion.

‍

What is a STAR rule?

A SentinelOne STAR (Storyline Active Response) rule is a custom detection that continuously checks endpoint activity against a query you define, then raises an alert, and optionally takes an automated response action, whenever matching behaviour occurs.

Watch our video of using STAR rules in action

‍

The four validated STAR rules

The investigation produced four SentinelOne STAR rules:

CV - PHP web worker spawned command shell

Detects a PHP runtime or recognised PHP web-server worker starting a command shell, scripting host or shell-capable networking utility. Unix shell matches require stronger command indicators associated with discovery, interactive shells or named-pipe behaviour.

CV - PHP web worker wrote executable script to upload directory

Detects a PHP or web-server worker writing an executable server-side script into a served upload location. The final rule avoids matching every directory whose name merely contains "upload".

CV - PHP web worker launched network download tool

Detects a PHP or web-server worker starting tools such as curl, wget, certutil or bitsadmin with an HTTP or HTTPS location. It is kept separate because some applications legitimately retrieve remote content.

CV - PHP child shell opened network connection

Detects a command shell or shell-capable utility started by a PHP process opening a network connection. This can highlight reverse-shell or command-and-control behaviour, but the connection must still be investigated in context.

All four rules were configured as High severity and detection-only. They did not perform active response, quarantine an endpoint or automatically treat the matching activity as a threat.

Validating without exploiting a real workload

Before wider deployment, the rules were created in a non-production SentinelOne environment.

We reconfirmed that active response, network quarantine and threat treatment were disabled, then generated harmless synthetic behaviours on a lab endpoint:

• a temporary PHP-named test process launched a harmless shell;
• it wrote and removed a non-executed marker in a test upload directory;
• it launched a download utility towards a closed local port; and
• a child shell briefly opened a local network connection without sending a command.

Each rule generated one alert for its intended behaviour. Temporary files and listeners were removed afterwards.

This proved that the rules compiled, received the expected endpoint fields and alerted on the intended process, file and network relationships. It did not prove that they detect every exploitation technique, and the synthetic alerts were not evidence of real attacks.

Why we deployed in monitor-only mode

After non-production validation, the four rules were promoted to the managed production console in monitor-only mode. No synthetic testing was performed on customer or production endpoints.

At the time of final readback, the rules were active, detection-only and had generated no natural alerts. That accurately describes the point-in-time result; it does not guarantee that the rules will never alert or that the environment was universally safe.

Monitor-only deployment mattered for three reasons.

First, the rules identify behaviours that are suspicious but not impossible for legitimate applications. Automatically killing a process or isolating a web server before understanding the local workflow could cause avoidable disruption.

Second, natural observations provide evidence for later tuning. Any exception should be narrow, combining the relevant server role, executable path, command line and application context. Excluding PHP or Apache globally would remove much of the value.

Third, some response actions are much harder to reverse than an alert. Detection confidence and response confidence are not the same thing.

Cross-console historical hunting was equally important. A query that looks quiet in a lab or one customer environment may be routine in another. Searching every available scope before deployment exposed legitimate workflows early and prevented a noisy first version from becoming a fleet-wide rule.

What a STAR alert can prove

A matching STAR alert can establish that the endpoint agent observed the configured behaviour: for example, a particular parent process started a shell, wrote a file or made a network connection.

It can provide:

• the process lineage and command lines;
• endpoint and user context;
• surrounding file activity;
• subsequent child processes;
• network connections visible to the agent; and
• a Storyline around the event.
• That is valuable incident evidence.

It cannot, by itself, establish:

• the malicious HTTP request or request body;
• which vulnerability supplied initial access;
• whether a particular malformed request reached PHP;
• whether an installed PHP package was genuinely vulnerable after vendor backports;
• whether code execution occurred entirely in memory without one of the selected behaviours;
• whether every PHP runtime or container was covered by the agent and query;
• whether a matching administrative action was authorised; or
• whether an empty historical hunt proves that no compromise occurred.

Attribution requires correlation. Analysts should preserve the endpoint Storyline and align it with WAF, reverse-proxy, load-balancer, web-server and application logs. They should also review files written around the event, outbound connections, the effective PHP version and configuration, and the application workflow that received the initiating request.

Patching and web telemetry remain essential

The PHP project is clear that updating is the only complete remediation for CVE-2026-109618 and CVE-2026-109619. Configuration mitigations reduce exposure to particular paths but do not make an unpatched installation safe.^[1]

A WAF can help identify or restrict suspicious web requests while patching is under way. It may also preserve the request evidence needed to link endpoint behaviour to an initial access attempt. But WAF coverage depends on traffic routing, inspection limits, encoding, rule configuration and logging. It should be treated as a complementary layer, not a substitute for patching.^[7]

Likewise, STAR is a compensating detection control. It helps answer what an endpoint did after code execution. It does not repair the vulnerable runtime.

Lessons for defenders

The most useful outcome from this work was not a single query. It was a repeatable detection-engineering method:

1. Separate exposure from compromise. Record what the version and configuration establish without turning it into an incident verdict.
2. Hunt before alerting. Run candidate logic over the longest practical retention window and across different server roles.
3. Expect the first query to be wrong. Broad reconnaissance is useful, but it is not production detection content.
4. Investigate legitimate matches rather than hiding them. They reveal where command boundaries, paths and parent-child relationships need improvement.
5. Keep distinct behaviours in separate rules. Shell creation, payload retrieval, file creation and network activity have different baselines and exceptions.
6. Validate safely. Use harmless synthetic activity in a non-production environment and confirm the response settings before testing.
7. Start with detection-only deployment. Observe real matches before considering automated response.
8. Use multiple telemetry layers. Endpoint, WAF, proxy, server and application logs answer different parts of the incident question.
9. Phrase conclusions precisely. "No retained events matched this query" is defensible. "No exploitation occurred" is not.
10. Patch first. Detection engineering provides visibility and resilience, but it does not replace remediation.

Practical PHP2Shell checklist

• Inventory PHP runtimes in hosts, containers and bundled products.
• Identify the effective web SAPI and runtime configuration.
• Upgrade to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or confirm a vendor-supported backport.
• Restart PHP and web workers and verify the live runtime afterwards.
• Review PHP's interim configuration guidance where immediate patching is impossible.
• Assess the separate prerequisites for CVE-2026-115560.
• Keep session.upload_progress.enabled=0 where the PHP advisory recommends it, and restart affected workers.
• Search historical endpoint telemetry from at least the earliest credible exploitation date.
• Review WAF, reverse-proxy and web-server logs for suspicious multipart and session activity.
• Hunt for unexpected shells, executable files in served upload paths, payload retrieval and outbound connections.
• Validate behavioural rules in a non-production environment.
• Deploy new detections in monitor-only mode first.
• Investigate each match using the complete process tree, files, network activity and initiating web request.
• Do not treat an empty hunt as proof of absence.

The bottom line

The central lesson is simple: vulnerability management tells us where risk may exist; behavioural detection helps us see what a system actually did. Defenders need both, and they need the discipline not to claim more than either source of evidence can prove.

References

1. PHP security advisory, PHP project, 21 October 2026.
2. CVE-2026-109618 advisory, PHP project.
3. CVE-2026-109619 advisory, PHP project.
4. Amazon threat-intelligence report on PHP2Shell exploitation attempts, Amazon.
5. Known Exploited Vulnerabilities catalogue, CISA.
6. PHP session upload progress advisory (CVE-2026-115560), PHP project, 23 October 2026.
7. AWS WAF guidance for PHP2Shell, Amazon Web Services.

‍

‍

‍

‍

‍

James Kavanagh

Chief Technology Officer

‍

‍