Practical detection and hunting investigation for CVE-2026-109618 and CVE-2026-109619
PHP2Shell is the name given to two critical vulnerabilities in the PHP runtime that can allow unauthenticated remote code execution. CVE-2026-109618 involves memory corruption when allocation fails during request parsing. CVE-2026-109619 involves stale memory being reused across requests.
Both flaws can be reached while PHP processes an HTTP request, before the application code runs. Exploitation attempts have already been observed. Start with two practical checks for detection and exposure, then follow the hunting workflow to find suspicious traffic and validate what happened.
Need Help Investigating PHP2Shell?
Have questions about the hunting queries, detection rules, or packet reconstruction workflow? Connect with our team for guidance.
Pre-hunt Checks / Detection & Exposure
Set up automated detection
Create a NetWitness Application Rule to flag inbound form-based POST requests that use PHP’s session upload progress feature. This pattern has appeared in observed exploitation and scanning activity.
APPLICATION RULE
direction = 'inbound' && service = 80 && action = 'post' && content = 'multipart/form-data','application/x-www-form-urlencoded' && query contains 'PHP_SESSION_UPLOAD_PROGRESS' && query count 10The query count condition makes the rule more selective, but it may miss probes with fewer parameters. Consider removing it for broader coverage. This rule identifies a common suspicious pattern, not every way the vulnerabilities can be exploited.
Identify potentially vulnerable PHP servers
PHP released fixes on October 21, 2026. Start by looking for web servers that advertise PHP versions earlier than the fixed releases to help identify servers that may be vulnerable and still need to be patched.
| PHP branch | First fixed version |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
NETWITNESS QUERY: ADVERTISED VERSIONS
server regex 'PHP/(?:[5-7]\.\d+|8\.[01]\.\d+|8\.2\.(?:[0-9]|[12][0-9]|3[0-4])|8\.3\.(?:[0-9]|[12][0-9]|3[0-5])|8\.4\.(?:[0-9]|1[0-9]|2[0-6])|8\.5\.(?:[0-9]|1[01]))(?:\D|$)'This query looks for PHP version strings in HTTP server metadata. It is a triage aid, not proof of vulnerability: servers may hide their version, a proxy can rewrite headers, and vendors may backport fixes without changing the visible version.
EVIDENCE / ADVERTISED PHP VERSIONS
Figure 1. NetWitness metadata showing PHP/8.4.26 and PHP/8.4.6 in HTTP server headers. Both are below the upstream PHP 8.4.27 fix.
Hunting Workflow / Investigate PHP2Shell
STEP 01 — Narrow the hunt to inbound HTTP POST requests
NETWITNESS QUERY
direction = 'inbound' && service = 80 && action = 'post'This is a starting point because the vulnerabilities are reached during HTTP request processing. Do not limit the hunt to URLs ending in .php as applications can use URL rewriting, and PHP may handle requests without exposing a script extension. For HTTPS, inspecting content requires decryption or equivalent request visibility.
Form submissions are a useful next filter:
NETWITNESS QUERY
content = 'multipart/form-data','application/x-www-form-urlencoded'Public attempts have used multipart bodies, and form parsing is relevant to the affected code paths. Neither content type indicates malicious behavior on its own.
STEP 02 — Look for PHP session upload progress activity
NETWITNESS QUERY
query contains 'PHP_SESSION_UPLOAD_PROGRESS'PHP supports upload progress tracking through session data. The feature appears in observed attack traffic, so investigate unexpected use of it. Look for repeated POSTs, changing PHPSESSID values, unusual filenames or form values, and large numbers of fields within the same request.
EVIDENCE / HTTP SESSION METADATA
Figure 2. Example NetWitness triage metadata: multipart POST requests and session upload progress fields are identified along with a long list of unique query values.
The sample shows repeated, incrementing form-field names. Combined with the session upload progress marker, that pattern deserves investigation.
STEP 03-A — Look for unusually large requests
NETWITNESS QUERY
payload.req > 4000000Memory allocation failure is relevant to CVE-2026-109618. Oversized request bodies or form fields may help an attacker trigger such conditions. A 4 MB threshold is a starting point, not a signature. Tune it to normal application traffic, and remember that some attacks could use smaller requests.
STEP 03-B — Look for deeply nested array parameters
NETWITNESS QUERY
query regex '(\[[^\[\]]*\]){6,}'PHP can build nested arrays from names such as user[profile][settings]. Deeply repeated bracketed parameters can increase parsing work and memory usage and can be another technique to trigger CVE-2026-109618. This query looks for six or more consecutive bracketed segments in the available query metadata. Prioritize unusual nesting that appears with high request volume, errors, or other suspicious behavior.
STEP 04 — Reconstruct and validate suspicious sessions
Once a request stands out, reconstruct the HTTP session from captured packets and inspect its headers, parameters, filenames, and body content. Correlate the time of the request with web server logs and endpoint telemetry.
- PHP memory errors, worker crashes, or unexpected HTTP 500 responses around the requests.
- Web-facing processes such as php-fpm, php-cgi, httpd, or apache2 launching shells or tools such as curl, wget, or nc.
- New or modified files in the web root, including possible web shells.
- Unexpected outbound connections from the affected server after suspicious inbound traffic.
The strongest findings connect events: for example, a suspicious multipart POST followed by a web server process launching a shell. Any individual signal can have an innocent explanation, and the absence of crashes does not rule out successful exploitation.
Final thoughts
PHP2Shell illustrates why network visibility matters beyond known signatures. This is also why continuous full packet capture matters. When a new vulnerability becomes public, exploitation may already have been happening for days or weeks. Retained packet history lets analysts go back, apply new hunting logic, and reconstruct the exact traffic that reached an affected server.
Selective or smart packet capture can leave gaps if the activity did not match the triggers known at capture time. Metadata can help locate a suspect session, but it cannot recreate a payload that was never retained.
You cannot investigate packets you never captured.
Start with detection rules and asset identification, hunt across historical traffic, and correlate packet evidence with endpoint and server activity. Above all, patch the affected systems.
