Cybersecurity
Information Technology
Information Security
Security
Hacking

Hunting PHP2Shell: A Practical Guide for SOC and DFIR Teams

seif

18 min readOct 22, 2026

On October 21, 2026, two critical vulnerabilities in PHP were publicly disclosed under the name PHP2Shell, tracked as CVE-2026–109618 and CVE-2026–109619, both carrying a CVSS score of 9.2

What makes this particularly concerning is that we’re not talking about a vulnerability in a WordPress plugin or a misconfigured web application. These vulnerabilities affect the PHP runtime itself, potentially exposing a massive number of web applications to unauthenticated remote code execution (RCE) and memory disclosure.

And exploitation attempts were already happening before the vulnerabilities became public.

According to Amazon Threat Intelligence, its MadPot infrastructure observed an exploitation attempt as early as October 17, four days before the official disclosure. Additional attempts followed as proof-of-concept exploits became publicly available.

There’s already excellent technical research explaining the memory corruption, use-after-free conditions, and exploitation chains behind PHP2Shell. Wiz’s research is particularly worth reading if you want to understand those internals.

But I wanted to approach this from a different angle.

If I’m sitting in a SOC or working an incident response case, my immediate questions aren’t necessarily about how the exploit manipulates PHP’s memory allocator.

I’m more concerned with:

Which of our assets are actually exposed?
Has anyone attempted to exploit them?
What telemetry would show those attempts?
How can we determine whether exploitation was successful?
If a server is compromised, what else should we investigate?
How do we contain the threat, patch the environment, and verify that we’re no longer exposed?

That’s what I want to focus on here.

This isn’t intended to be an exploit-development deep dive. It’s a practical hunting and incident response guide for SOC analysts, threat hunters, and DFIR practitioners who need to assess exposure and investigate potentially affected environments.

PHP2Shell: What Defenders Actually Need to Know

At a high level, PHP2Shell involves memory-safety vulnerabilities in how PHP handles certain errors and manages state across requests.

The two CVEs cover related but distinct issues:

CVE-2026–109618: An out-of-memory condition can interrupt PHP before internal state is safely initialized, leading to memory corruption during cleanup. Bottom line: Potential remote code execution
CVE-2026–109619: Request-owned state can remain accessible after its memory has been freed, allowing a later request to trigger a use-after-free. Bottom line: Potential memory disclosure or remote code execution

The exploitation details vary depending on the PHP version, configuration, server integration, and specific vulnerable path.

For example, Apache mod_php has a demonstrated application-independent exploitation path, while other server integrations have different requirements and varying levels of publicly demonstrated exploitability.

One detail I think defenders need to pay particular attention to is that some of this activity can happen before application code even executes.

That changes our visibility.

If we’re relying entirely on WordPress logs or other application-level logging, we might never see the full picture.

Another important point: PHP2Shell isn’t exclusively about dropping a web shell or spawning a command interpreter. Researchers also demonstrated the ability to disclose sensitive PHP worker memory, potentially exposing credentials, tokens, and other secrets.

A successful memory disclosure may not leave behind a suspicious executable, new file, or obvious child process.

So for this investigation, I wouldn’t limit myself to traditional web-shell indicators.

I’d approach it across three areas:

Incoming HTTP activity, PHP runtime behavior, and post-exploitation evidence.

The objective is to correlate them, not depend on a single indicator.

Before Hunting, Find Your Exposed Assets

This is where I’d start.

We can have excellent detection logic, but if we don’t know which applications are using vulnerable PHP runtimes, we’re already working with incomplete information.

I’d coordinate with infrastructure, application, and vulnerability management teams to identify internet-facing PHP services.

The initial asset inventory should cover:

Apache servers using mod_php
Nginx or Apache deployments using PHP-FPM
PHP-CGI and other PHP server integrations
WordPress, Drupal, Joomla, and custom PHP applications
Containers and Kubernetes workloads
Shared hosting environments
Third-party applications or appliances that bundle PHP

The last two are easy to overlook.

PHP might be embedded in a product without appearing as a separately managed application, and the runtime inside a container may differ from what’s installed on the host.

Quick Linux checks

Start with identifying running web and PHP processes:

ps -eo pid,ppid,user,comm,args |
grep -Ei 'php-fpm|php-cgi|apache2|httpd|lsphp|frankenphp'

Check the locally installed PHP CLI version:

php -v

For Apache, identify whether a PHP module is loaded:

apachectl -M 2>/dev/null | grep -i php

These checks are useful for initial triage, but I’d be careful about treating php -v as definitive evidence of the web-facing runtime version.

The command-line PHP installation isn’t necessarily the same runtime used by PHP-FPM, Apache, or an application container.

Verify the actual package, runtime instance, and vendor patch revision for each affected service.

How Far Back Should We Hunt?

This part is important.

The official disclosure happened on October 21, but AWS observed an exploitation attempt on October 17.

If I were scoping a PHP2Shell investigation today, my initial historical hunting window would be:

October 17, 2026, 00:00 UTC to present. Or even a month before if your logs permit

For critical infrastructure or systems with strong historical telemetry, I’d consider extending that window further back.

I wouldn’t automatically treat the disclosure date as the beginning of malicious activity.

And I’d distinguish three things throughout the investigation:

Scanning: Someone is probing the application or looking for vulnerable behavior.
Attempted exploitation: The activity resembles a known exploitation technique but success hasn’t been established.
Confirmed compromise: We have evidence of unauthorized execution, access, disclosure, persistence, or another security impact.

This distinction matters in incident reporting.

An attacker sending a malicious HTTP request doesn’t necessarily mean the server was compromised.

Likewise, a lack of obvious post-exploitation artifacts doesn’t automatically mean exploitation failed.

Hunting for PHP2Shell

Here’s how I’d break down the actual hunting work.

Hunt 1: Suspicious HTTP POST and Multipart Requests

Hypothesis: An attacker is manipulating PHP request parsing or upload-progress handling to trigger vulnerable runtime behavior.

One of the areas I’d prioritize is unusual multipart/form-data traffic.

PHP’s official advisory documents multipart parsing conditions that can contribute to memory exhaustion. These include unusual field structures, excessive multipart headers, and requests that place unexpected pressure on memory allocation.

I’d look for patterns such as:

Multipart POST requests to endpoints that don’t normally process uploads.
Repeated requests with unusually large bodies.
Abnormal request sizes or missing usable content-length information.
Excessive multipart field or header structures, where body inspection is available.
Multiple suspicious requests targeting the same application within a short period.
Requests followed by PHP errors, HTTP 500 responses, or unusual worker behavior.

Another relevant string is:

PHP_SESSION_UPLOAD_PROGRESS

This is associated with PHP’s session upload-progress functionality and is specifically mentioned in AWS’s hunting recommendations.

However, it’s not inherently malicious. It’s also not required by every PHP2Shell exploit path.

I would treat it as a lead, not a signature that proves exploitation.

Example: Splunk hunt for unusual multipart POST activity

This query assumes normalized web or WAF fields and is intended as a starting point. Adjust the index, field names, and thresholds for your environment.

index=web_logs earliest="10/17/2026:00:00:00"
| eval src_ip=coalesce(client_ip,src_ip,src)
| eval target=coalesce(vhost,server_name,host)
| eval method=upper(coalesce(http_method,method))
| eval content_type=lower(coalesce(content_type,request_content_type,""))
| eval status=tonumber(coalesce(status,http_status,sc_status))
| where method="POST"
    AND like(content_type,"%multipart/form-data%")
| bin _time span=5m
| stats count AS post_count
    count(eval(status>=500)) AS server_errors
    values(uri_path) AS requested_paths
    by _time src_ip target
| where post_count>=5 OR server_errors>=2
| sort - server_errors - post_count

I’m not looking at the request count alone.

If I find unusual multipart traffic, I want to know what happened immediately afterward.

Did the same server start returning errors? Did a PHP worker restart? Was there unexpected process execution? Did the application behave differently?

That’s where the hunt becomes more useful.

Visibility limitation: Standard Apache and Nginx access logs usually don’t contain request bodies, so searching those logs for multipart fields may not work. Body-level indicators require WAF, proxy, or network inspection telemetry that actually captures them.

Hunt 2: PHP Fatal Errors, Memory Exhaustion, and Worker Instability

Hypothesis: Exploitation attempts are causing abnormal PHP runtime conditions.

I’d pivot from suspicious web requests into PHP and web-server error logs.

Some useful indicators include:

Allowed memory size ... exhausted
Maximum execution time ... exceeded
Unexpected PHP fatal errors
PHP-FPM worker failures
Apache child-process crashes
Segmentation faults
Repeated HTTP 500/502/503 responses
Unusual PHP worker recycling

Individually, these aren’t strong indicators of compromise.

Applications encounter legitimate memory and execution errors all the time.

What makes them interesting is their relationship to suspicious external requests.

Example: Splunk hunt for runtime errors

index=php_logs earliest="10/17/2026:00:00:00"
(
    "Allowed memory size"
    OR "Maximum execution time"
    OR "Fatal error"
    OR "segmentation fault"
    OR "SIGSEGV"
    OR "child exited on signal"
)
| bin _time span=5m
| stats count AS error_count
    values(source) AS log_sources
    values(_raw) AS sample_errors
    by _time host
| where error_count>=3
| sort - error_count

Again, I’d tune that threshold based on the application’s normal behavior.

What I’d correlate

Imagine the following sequence:

10:30:01 — Unusual multipart POST reaches the application

10:30:02 — PHP reports memory exhaustion

10:30:03 — The PHP worker exits unexpectedly

10:30:05 — Another suspicious request reaches the server

10:30:06 — EDR records unusual web-server process activity

This is an illustrative sequence, not a confirmed PHP2Shell incident.

That combination is much more interesting than a standalone memory error.

There’s also an important caveat: successful exploitation may not produce a visible crash.

I wouldn’t make a PHP error or worker restart mandatory in detection logic. These are useful supporting signals, not prerequisites for successful exploitation.

Hunt 3: Suspicious Request Sequences

Hypothesis: An attacker is using multiple requests to manipulate and subsequently access stale PHP worker state.

CVE-2026–109619 is particularly interesting from a hunting perspective because some exploitation paths involve operations occurring across separate HTTP requests.

A request may leave unsafe state behind, and another request handled by the same worker may later interact with it.

For a threat hunter, that means treating every HTTP request as an isolated event may miss the relationship between them.

I’d investigate suspicious clusters of requests targeting the same application, especially when accompanied by fatal errors, unusual responses, or worker anomalies.

Where telemetry permits, I’d try to determine whether related requests were handled by the same PHP worker.

Ordinary access logs typically don’t preserve that level of detail.

And this is important: Two requests sharing a source IP or a session cookie do not prove they were processed by the same worker.

That relationship has to be supported by runtime or worker-level evidence.

Existing Zeek and Suricata detections

Corelight has published a useful detection project:

corelight/php2shell-detect

For teams already using Zeek, the package provides detections for suspicious request patterns and correlated HTTP activity.

Relevant notices include:

PHP2SHELL::PHP_Crash_Sequence
PHP2SHELL::Multipart_Header_Flood
PHP2SHELL::Large_Form_Key
PHP2SHELL::Serialized_Integer_Overflow

The PHP_Crash_Sequence notice represents a correlation of suspicious HTTP transactions. It doesn't independently prove that a worker crashed.

I’d review the detection conditions before enabling them broadly, particularly in environments with heavy legitimate upload activity.

Corelight also provides Suricata signatures covering a research-associated request marker and potentially affected PHP versions.

Those version detections are useful for asset discovery, but they aren’t evidence of exploitation.

My preference would be to start with the vendor-maintained rules, validate their behavior, and then add environment-specific correlations rather than inventing a single supposedly universal PHP2Shell signature.

Hunt 4: Suspicious Child Processes From Web Servers

Hypothesis: An attacker achieved code execution and used the PHP or web-server process to execute operating-system commands.

This is where I would start looking for evidence of actual compromise.

If a PHP worker suddenly launches a shell, downloader, or unexpected interpreter, I want to know why.

Processes worth investigating include:

bash, sh, dash
curl, wget
python, python3, perl
nc, ncat, socat
cmd.exe, powershell.exe
Discovery utilities such as whoami, id, and uname

Potential parent processes include PHP-FPM, PHP-CGI, Apache, and other PHP-serving processes.

Microsoft Defender XDR: Advanced Hunting

DeviceProcessEvents
| where Timestamp >= datetime(2026-10-17)
| where
    InitiatingProcessFileName startswith "php-fpm"
    or InitiatingProcessFileName in~ (
        "php", "php.exe",
        "php-cgi", "php-cgi.exe",
        "apache2", "httpd", "w3wp.exe"
    )
| where FileName in~ (
    "sh", "bash", "dash",
    "curl", "wget",
    "python", "python3", "perl",
    "nc", "ncat", "socat",
    "cmd.exe", "powershell.exe"
)
| project
    Timestamp,
    DeviceName,
    AccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FileName,
    ProcessCommandLine,
    ReportId
| order by Timestamp desc

This is a behavior-based starter hunt, not a PHP2Shell-specific detection.

It should be expanded for version-specific process names, indirect process ancestry, and legitimate web-server workloads in the environment.

What matters is whether the execution is expected.

Some applications legitimately use subprocesses for image processing, document conversion, or maintenance tasks.

But unexplained shell execution from a web-facing service should be investigated, especially if it follows suspicious HTTP activity.

If I find unauthorized command execution, I’d escalate the investigation immediately.

I also wouldn’t automatically attribute it to PHP2Shell.

The same behavior could result from another web application vulnerability or preexisting compromise.

We still need evidence connecting the execution to the initial access mechanism.

Hunt 5: Memory Disclosure and Suspicious Session Cookies

Hypothesis: An attacker exploited PHP worker-memory handling to disclose sensitive information through an HTTP response.

This is one of the more interesting parts of PHP2Shell, and one I wouldn’t want SOC teams to overlook.

Wiz demonstrated a memory-disclosure technique in which stale memory contents could be exposed through malformed PHPSESSID response cookies.

The attacker may be able to retrieve sensitive data without dropping a file or executing an external command.

Get seif’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

If I have response-header telemetry available, I’d look for:

Unusually large PHPSESSID values.
Unexpected changes in session-cookie length or format.
Suspicious multipart requests followed by abnormal response headers.
Responses containing session cookies from endpoints that don’t ordinarily create them.

I would first establish what a normal session cookie looks like for that application.

A long cookie isn’t automatically malicious.

I’d also consider whether sensitive application secrets could have been present in the affected worker’s memory.

This has consequences for incident scoping.

A server can be patched and show no suspicious process execution, while the possibility of earlier credential exposure still needs to be assessed.

If the evidence indicates likely memory disclosure, I’d investigate the downstream use of potentially affected secrets, not just the original web server.

Raw session cookies and leaked data should be handled as sensitive evidence rather than pasted into broadly accessible incident tickets.

Hunt 6: Post-Exploitation Activity and Persistence

Hypothesis: After gaining access, the attacker established persistence, collected information, or moved into other systems.

At this point, I’d stop thinking exclusively about PHP2Shell and start investigating the host as a potentially compromised system.

I’d look for:

New or modified PHP files in web roots.
Unexpected scripts in writable upload directories.
Suspicious scheduled tasks or cron jobs.
Modified application or service configurations.
Unauthorized SSH keys or user accounts.
Newly created executables in temporary directories.
Unexpected outbound connections.
Access to application secrets or cloud credentials.

Quick Linux filesystem triage

sudo find /var/www -type f \
  \( -name "*.php" -o -name "*.phtml" \) \
  -newermt "2026-10-17" \
  -printf "%TY-%Tm-%Td %TH:%TM %p\n"

This is a basic starting point for finding recently modified PHP files.

I’d compare results against expected deployments and known-good application files.

Modification timestamps can be changed, and deleted or in-memory artifacts won’t appear in this search.

For network activity, I’d focus on connections that aren’t part of the web server’s usual behavior.

For example, if a public PHP server suddenly connects to an unfamiliar external endpoint or internal administrative system, I’d want an explanation.

Still, not every successful exploitation chain requires a web shell, outbound callback, or persistent artifact.

That limitation should remain part of the investigation.

How I’d Triage the Findings

One of the mistakes I try to avoid is treating every suspicious event as confirmation of compromise.

I’d organize findings into a few practical categories.

The important distinction is between evidence of attempted exploitation and evidence of successful compromise.

A WAF alert doesn’t tell us an attacker successfully executed code.

A vulnerable PHP version doesn’t tell us the server was exploited.

And a clean EDR search doesn’t eliminate the possibility of memory disclosure or in-process exploitation.

I would rather report that the available telemetry found no evidence of compromise than claim that exploitation definitely didn’t happen.

Those are very different conclusions.

What If We Actually Find Evidence of Compromise?

If the investigation produces credible evidence of unauthorized execution, malicious file activity, memory disclosure, or related impact, I’d move into the incident-response process.

Containment

First, determine whether the affected server or workload needs to be isolated immediately.

For high-confidence compromise, I’d coordinate containment with infrastructure and application owners to prevent further attacker access.

Depending on the environment, that could involve restricting network access, taking the application out of service, isolating a workload, or replacing it with a trusted instance.

I wouldn’t indiscriminately restart everything before collecting evidence.

PHP2Shell involves runtime memory behavior, which means potentially relevant volatile evidence may disappear when workers terminate.

Preservation and containment need to be coordinated, with containment taking priority when continued attacker access presents an unacceptable risk.

Evidence preservation

Before rebuilding or replacing a potentially compromised system, I’d want relevant evidence preserved.

That includes:

Reverse-proxy, WAF, and web-server logs.
PHP error and PHP-FPM logs.
EDR process and network telemetry.
Suspicious files and relevant filesystem metadata.
Container events and deployment histories.
Authentication and cloud audit records.
Memory captures where warranted, feasible, and properly authorized.

I’d document collection timestamps and preserve originals when possible.

Timeline reconstruction

Then I’d reconstruct the activity from the earliest suspicious request.

The timeline I’m trying to establish is:

Initial request → PHP behavior → possible exploitation → unauthorized activity → persistence or data access.

Each step needs evidence.

If there’s a gap in the sequence, I’d document it rather than invent a connection.

Scope beyond the initial server

This is where I’d spend considerable effort.

If an attacker potentially accessed PHP worker memory, what secrets might have been exposed?

I’d look at application credentials, database connection strings, authentication tokens, API keys, and cloud credentials accessible to the affected workload.

Then I’d investigate whether those credentials were used elsewhere.

The scope may extend beyond the original application, even if no persistent malware remains on that server.

Patching and Recovery: Don’t Stop at the Version Number

Patching needs to happen urgently.

The PHP project is clear that upgrading to a fully patched release is the only complete mitigation for these vulnerabilities.

But there’s a difference between deploying a patch and knowing the affected environment is actually remediated.

Here’s what I’d want to verify:

The updated PHP package or container image contains the required fix.
The web-facing runtime is actually using that patched version or vendor backport.
All affected workers have been restarted or replaced.
No old PHP-FPM pools, legacy applications, or unpatched containers remain accessible.
WAF protections and other compensating controls remain enabled.
The team has reviewed potential exploitation that occurred before patching.

For workloads that can’t be patched immediately, I’d work with application owners to apply temporary, documented risk-reduction measures based on PHP’s official advisories.

These may include restricting unnecessary multipart uploads or disabling unused session upload-progress functionality.

However, configuration changes and WAF protections do not eliminate every PHP2Shell exploitation path.

I also wouldn’t casually change PHP memory settings as a workaround without considering the official guidance and availability implications.

Most importantly:

Patching removes the known vulnerable condition. It does not remove an attacker who has already established access, or invalidate credentials that may have been stolen.

If compromise is confirmed, recovery should include trusted rebuilds where appropriate, persistence removal, credential rotation, and verification of downstream activity.

Useful IOCs and Existing Detection Content

Several vendors have already published detection material that teams can use to accelerate hunting.

AWS threat intelligence

AWS published six source IPs associated with its observed exploitation attempts:

103.216.220.92
31.223.184.166
37.19.200.5
134.209.159.64
103.114.163.188
95.217.98.37

AWS notes that some addresses belong to shared anonymization infrastructure.

I would use these for enrichment and historical investigation, not as automatic proof that every connection from those IPs is malicious.

Cloudflare WAF

Cloudflare published managed PHP2Shell protections, including rules that consider both request and response signals.

For environments using Cloudflare, I’d review:

Security → Security Analytics → Events

Then filter for the PHP2Shell-related rule identifiers published in Cloudflare’s advisory.

I’d look at which rules triggered, what action the WAF took, which applications were targeted, and whether requests reached the origin.

A blocked request is still useful intelligence, but not confirmation of a compromised server.

Corelight

Corelight’s detection repository provides Zeek and Suricata content for suspicious HTTP behavior.

I’d review those detections alongside local application baselines and ensure the network sensors can actually inspect the relevant traffic.

HTTPS traffic needs to be decrypted at an appropriate inspection point for many HTTP-body detections to work.

The main point: These tools help generate leads. The evidence still needs correlation and analyst validation.

What I’d Prioritize During the First 24 Hours

If I were helping coordinate the SOC response, this would be my working checklist.

These activities don’t all need to happen sequentially.

I’d want vulnerability management, infrastructure, detection engineering, and incident response working in parallel.

For confirmed compromise, containment and evidence preservation take precedence over waiting for an exhaustive hunt to finish.

The Visibility Problem

One thing I think deserves more attention in vulnerability response discussions is visibility.

It’s easy to publish a search query and tell defenders to look for a particular pattern.

But the query is only as useful as the telemetry behind it.

For PHP2Shell, several limitations matter:

Standard web access logs may not contain multipart request bodies.
Application logs may miss behavior occurring before application execution.
Response headers may not be collected.
EDR might not capture in-process exploitation.
Worker restarts can destroy volatile evidence.
Load balancing and worker reuse complicate request correlation.
Short-lived containers may disappear before investigation begins.

If an organization doesn’t retain the necessary data, no amount of clever query writing can reconstruct information that was never captured.

I think it’s important to be explicit about that when reporting results.

A hunt returning zero events is not automatically a clean bill of health.

The better question is: What activity could we realistically have detected with the telemetry available to us?

That answer should influence both our confidence in the investigation and the detection improvements we prioritize afterward.

PHP2Shell Is an Incident Response Problem, Not Just a Patching Problem

There’s no question that these vulnerabilities need to be patched urgently.

But I think teams can make the mistake of treating critical CVE response as a simple vulnerability management exercise.

Identify the vulnerable software, deploy the fix, close the ticket.

That works for reducing future exposure. It doesn’t answer whether somebody already exploited the environment.

And with PHP2Shell, we already know exploitation attempts were observed before the public release.

That’s why I’d treat patching and threat hunting as parallel workstreams.

I’d also avoid building the entire detection strategy around one exact payload, IP address, or proof-of-concept signature.

Those indicators are useful, but they only cover what we already know.

What I’d rather focus on is the behavior around the exploit:

Unexpected HTTP request patterns.
Runtime errors and worker anomalies.
Suspicious execution from web-serving processes.
Unusual response data.
Unauthorized persistence or file modification.
Unexpected credential use or downstream access.

Not every signal will be present, and not every match will indicate compromise.

The value comes from correlating the available evidence and understanding what it actually supports.

Another takeaway for me is how quickly the gap between vulnerability disclosure and exploitation continues to shrink. PHP2Shell is a particularly interesting example because AI-assisted vulnerability research and exploit development played a significant role in the discoveries and demonstrations.

For defenders, this reinforces the need to make asset visibility, emergency patching, and behavior-based detection part of normal operations rather than something assembled from scratch during a major vulnerability disclosure.

Don’t Assume We’ve Seen Every Exploit Variant

One thing I’d keep in mind is that the publicly documented PHP2Shell exploitation techniques may not be the only ones out there.

With vulnerabilities this significant, I’d operate under the assumption that additional exploit chains, payload variations, and ways to bypass existing detections either already exist or will continue to emerge.

This is why I wouldn’t rely solely on published IOCs, known PoCs, or vendor signatures. Those detections are valuable, but they only cover the techniques we currently understand.

For SOC and DFIR teams, I’d recommend continuing to hunt for abnormal PHP runtime behavior, suspicious HTTP activity, unexpected process execution, and post-exploitation indicators, even when traffic doesn’t match any known PHP2Shell signature.

The absence of known indicators doesn’t necessarily mean the absence of exploitation.

Patch the known vulnerabilities, maintain visibility, and keep hunting. Don’t assume our current understanding of PHP2Shell represents the entire attack surface.

Final Thoughts

PHP2Shell is a good reminder that vulnerabilities don’t have to exist in application code to put an application at risk.

A flaw in the underlying runtime can expose an otherwise well-maintained web application, and successful exploitation may not leave behind the usual evidence we associate with a compromised web server.

For SOC and DFIR teams, I’d focus on four things:

Know what’s exposed. Hunt across multiple telemetry sources. Investigate evidence of compromise beyond the initial request. Patch and verify remediation without assuming the incident is automatically over.

Ultimately, the purpose of the hunt isn’t simply to find traffic that looks like PHP2Shell.

It’s to determine whether the environment was targeted, whether exploitation may have succeeded, what the attacker could have accessed, and what we need to do to contain and recover from it.

That’s the part that matters when you’re the one responsible for investigating the alert.

References

Official advisories and technical research

Threat intelligence and detection engineering

Research current as of October 22, 2026. Hunting queries are illustrative starting points and should be tested and tuned against your environment before production deployment.