PHP2Shell: Investigating Exposure and Exploitation with Network-Derived Telemetry

On October 21, the PHP development team released emergency security updates addressing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Discovered by Wiz Research, both vulnerabilities can allow unauthenticated remote code execution in affected PHP environments, creating an urgent need for organizations to identify potential exposure and apply the appropriate security updates.

For security teams, the challenge extends beyond identifying vulnerable software. They also need to understand which systems may be exposed, whether suspicious activity indicates attempted exploitation, and where to prioritize investigation and remediation.

This is where independent network evidence provides valuable context. The Gigamon Deep Observability Pipeline delivers trusted network-derived telemetry, including application-aware metadata from Gigamon Application Metadata Intelligence (AMI), to security and observability tools. This independent source of contextual evidence helps security teams assess potential exposure, investigate suspicious behavior, and make more informed response decisions.

In this post, we’ll examine how AMI can help answer three critical questions:

• Which systems may be exposed?
• Is there evidence of attempted exploitation?
• Where should security teams prioritize their response?

Understanding the PHP2Shell Vulnerabilities

Both vulnerabilities stem from how PHP handles certain fatal errors, particularly when a request exhausts available memory. Under specific conditions, PHP may fail to properly clean up internal data, creating memory-corruption conditions that attackers could exploit to execute malicious code. One vulnerability involves a cross-request use-after-free condition associated with session upload-progress handling, while the other involves memory corruption triggered within a single request through memory exhaustion.

For security teams, the immediate priorities are identifying potentially affected PHP installations, investigating suspicious requests, and applying the appropriate security updates.

Identifying Potentially Exposed PHP Systems with AMI

Identifying potentially affected systems is an important first step in responding to PHP2Shell. Gigamon AMI provides application-aware network metadata that can help security teams identify PHP-related activity in observed network traffic, examine Hypertext Transfer Protocol (HTTP) headers and protocol attributes, and identify systems that warrant further investigation.

Unlike approaches that rely exclusively on endpoint agents or asset inventories, network-derived telemetry provides an independent perspective on observed communications across hybrid cloud infrastructure. Combined with asset and configuration data, this context can help teams identify potential visibility gaps and prioritize systems for further verification.

Several AMI attributes may provide useful indicators of PHP-related activity, depending on the application, network configuration, and available traffic visibility.

AMI attribute	Potential investigative value
http_header_name http_header_value	Identifies PHP version information when present in observed HTTP response headers.
http_server_agent	Provides observed web-server or runtime information to support identification of potentially affected systems.
http_user_agent	Provides additional application context in observed outbound requests.
ssl.fingerprint_ja3s, ssl.certificate_subject_cn	Provides Transport Layer Security (TLS) fingerprint and certificate context to help correlate observed activity across systems but does not independently establish PHP version or patch status.

Different applications and server configurations expose different levels of information through network traffic. Some may advertise PHP version details in HTTP headers, while others provide only indirect indicators of PHP-related activity.

By examining multiple attributes together, security teams can build a more complete picture of observed systems and identify where additional verification is needed.

Security teams can use Gigamon AMI to support a tiered investigation of potentially affected systems, based on the strength of available evidence:

• Version observed: Network traffic contains an explicit PHP version indicator that can help identify systems requiring patch verification.
• Environment inferred: Web-server banners, distribution information, or other application attributes provide clues about the underlying environment and potentially affected PHP branches.
• PHP activity observed: Session cookies, PHP-related request paths, or other indicators suggest that a system may be running a PHP application, even when its version cannot be determined.

Correlating these observations with configuration management database (CMDB) records can provide additional context, including system ownership, business service, and environment. This helps security teams identify systems requiring further investigation and route findings to the appropriate teams.

Network-derived indicators should be validated against authoritative asset, software inventory, and package information before determining whether a system is vulnerable.

Illustrative Inventory Investigation Logic

- FOR each server observed in HTTP traffic:

- IF an explicit PHP version is observed
       (response header, server banner, or
       attributable outbound User-Agent):

-         tier = 1
        version = observed version
        patch_status = "requires verification"

-         IF version >= 5.4.0 AND
           (branch is end-of-life OR version < fixed[branch]):
            flag = "potentially affected"

-        IF the version came from the web-server banner
           (Apache appends it only for mod_php):
            sapi = "mod_php"
       ELSE IF web-server, distribution, or application
            metadata suggests a PHP environment:
 
- tier = 2
        environment = "PHP inferred"
        branch = inferred from web-server or distribution banner
        version = "unknown"

- ELSE IF a PHPSESSID cookie or .php request path
            is observed:

        tier = 3
        environment = "PHP activity observed"
        version = "unknown"

- ELSE:
        CONTINUE

- CORRELATE with available asset and configuration data

- PRIORITIZE investigation, in order:
        - Suspicious request patterns already observed against the host
        - sapi = mod_php (rated highest-risk in PHP's advisory)
        - Potentially affected or end-of-life PHP version or environment
        - Internet-facing or untrusted network exposure
        - Business criticality

- VERIFY vulnerability and patch status using
    authoritative software inventory, package
    information, and vendor security advisories

Verifying patch status: Linux distributions such as Debian, Ubuntu, and Red Hat Enterprise Linux (RHEL) may backport security fixes without changing the upstream PHP version reported in HTTP headers. As a result, a version banner may not alone establish whether a system is vulnerable or has been patched. Network-derived telemetry helps identify systems requiring investigation, while authoritative package information and vendor security advisories provide the basis for verifying vulnerability and remediation status.

Investigating Potential PHP2Shell Exploitation Attempts

Identifying potentially vulnerable systems is only part of the challenge. Security teams also need to investigate whether suspicious network activity may indicate attempted exploitation.

When HTTP request content is visible, Gigamon AMI can provide application-aware metadata that helps analysts examine request characteristics and identify unusual patterns. Depending on the available attributes and deployment configuration, these observations may include multipart form submissions, request sizes, session-related indicators, and other HTTP activity associated with potential exploitation attempts.

By combining application-aware metadata with network traffic patterns, security teams can develop targeted threat-hunting queries and investigate suspicious activity that may not be apparent from asset inventories alone.

Potential indicator	Investigative significance
PHP session upload-progress field in a multipart form submission	Identifies requests containing a field associated with the vulnerable upload-progress code path
Session identifiers supplied through cookies or multipart form fields	Identifies the request carrying the session identifier the upload progress path requires.
Unusually large POST requests or form-field names	Identifies abnormal request characteristics associated with potential memory exhaustion
Hundreds to thousands of multipart form parts in a single request	Identifies request patterns that may place additional memory pressure on the application.

Detection logic: Illustrative threat-hunting logic, subject to validation

The following indicators can provide a starting point for targeted threat hunting. Their presence does not independently confirm a PHP2Shell exploitation attempt, and detection thresholds should be validated against known exploit behavior and normal application traffic to reduce false positives.

- FOR each server observed in HTTP traffic:

-     IF an explicit PHP version is observed
       (response header, server banner, or
       attributable outbound User-Agent):

-         tier = 1
        version = observed version
        patch_status = "requires verification"

-     IF version is within a potentially affected
           branch or precedes the applicable fixed release:
            flag = "potentially affected"

       
-     IF observed metadata explicitly identifies mod_php:
            sapi = "mod_php"

-     ELSE IF web-server, distribution, or application
            metadata suggests a PHP environment:

        tier = 2
        environment = "PHP inferred"
        branch = inferred from web-server or distribution banner
        version = "unknown"
   
-     ELSE IF a PHPSESSID cookie or .php request path
            is observed:
        tier = 3
        environment = "PHP activity observed"
        version = "unknown"

-       ELSE:
        CONTINUE

- CORRELATE with available asset and configuration data

- PRIORITIZE investigation, in order:
        - Suspicious request patterns already observed against the host
        - mod_php, which PHP's advisory rates highest-risk
        - Potentially affected or end-of-life PHP version or environment
        - Internet-facing or untrusted network exposure
        - Business criticality

- VERIFY vulnerability and patch status using
    authoritative software inventory, package
    information, and vendor security advisories

- FOR each HTTP POST:

- upload_progress =upload-progress field present
        as a multipart form part
- session_present =PHPSESSID observed as a cookie
        OR as a multipart form part
- oversized =
        request body substantially exceeds
        the endpoint's normal size

- IF upload_progress AND session_present
       AND oversized:
        ALERT "Potential PHP2Shell setup request"
        elevate priority if any of:
            session identifier supplied as a form part
            no User-Agent header
            chunked transfer with no declared length

- ELSE IF a single form-field name
            substantially exceeds
            the endpoint's normal size:
        ALERT "Potential PHP2Shell
               memory-exhaustion request"

- IF repeated alerts occur from one client
       to one server within a short time window:
        elevate investigation priority

- ON any alert:
        tag the destination host
        "suspicious request patterns observed"

Exploitation attempts may involve repeated requests as attackers adjust their approach to the target environment. Clusters of similar POST requests from the same source may therefore provide useful investigative leads, particularly when correlated with application logs and other security evidence. Correlating related requests within a short time window may provide additional context for investigating potential exploitation.

Reported exploitation activity, including scanning for vulnerable PHP installations and attempts to establish persistent access, underscores the importance of investigating unusual request patterns alongside other available security evidence.

Investigating Suspicious Activity in Encrypted Traffic

Encrypted traffic can create visibility gaps for security teams investigating potential exploitation. While application-layer details may not be accessible without decryption, network-derived telemetry can still provide valuable context about observed communications.

Depending on the available telemetry, analysts can examine TLS handshake characteristics, connection durations, traffic volume, and communication patterns to identify activity that warrants further investigation.

The exploit chain has a recognizable shape even when the payload is encrypted. From one client to one server, within seconds: multi-megabyte uploads answered by a few hundred bytes; one upload answered by a response far larger than the server normally returns, and a final upload that receives no response at all. Connections close normally throughout. The sequence is not proof of exploitation on its own, but it is unusual enough to be a strong lead evidence.

The Gigamon Deep Observability Pipeline helps security teams extend visibility across hybrid cloud infrastructure, while Gigamon Precryption^® technology can provide access to plaintext traffic at supported points before encryption or after workload decryption. Combined with Gigamon AMI, this can deliver deeper application-aware context for security investigations.

• Investigating suspicious exchange sequences: A single client sending several large uploads to the same server within seconds, where the server responds back with almost nothing followed by an unusually large response. Correlating these observations with TLS fingerprints and other network evidence helps security teams identify activity that warrants further investigation.
• Correlating suspicious activity across systems: A TLS fingerprint associated with suspicious activity on a decrypted segment provides a starting point for investigating potentially related connections across other observed systems. Because fingerprints are not unique identifiers, these findings should be correlated with additional network and security evidence.

- FOR each TLS flow to a web server, grouped by client and server over 5 minutes
- upload_large = client bytes well above the server's normal req size
- tiny_or_none   = server bytes under 1 KB, or zero
- oversized_response  = server bytes far above the server's normal response size
- IF count(upload_large AND tiny_or_none) >= 2
     AND count(upload_large AND leak_response) >= 1
     AND client fingerprint not in the browser baseline:
       HUNT LEAD "Possible PHP2Shell-shaped exchange sequence"
- FOR each source flagged above:
-   fingerprint = its client's TLS fingerprint
-   LIST every other server that fingerprint connected to  →  candidate systems for further investigation

These indicators help security teams investigate potentially related activity across systems, even when application payloads remain encrypted.

Prioritizing Investigation and Remediation

Once security teams have identified potentially affected systems and suspicious activity, the next challenge is determining where to focus their response.

Network-derived telemetry informs these decisions by providing evidence of observed communications, suspicious activity, and application behavior. Correlated with asset inventories, vulnerability assessments, and business context, this evidence helps security teams prioritize investigation and remediation.

For example, an internet-facing PHP server exhibiting suspicious request patterns may warrant immediate investigation, particularly if it supports a critical business service. Gigamon AMI provides additional application-aware context to help security teams make these decisions with greater confidence.

Security teams can prioritize their response by evaluating four key factors:

• Confirm vulnerability status: Has the affected software version and patch status been verified?
• Exposure: Is the system accessible from untrusted networks?
• Suspicious activity: Does network-derived telemetry reveal behavior that warrants investigation?
• Business criticality: What is the operational or security impact if the system is compromised?

Applying Security Updates and Verifying Remediation

Applying the appropriate security updates remains the most important step in addressing PHP2Shell. Organizations should follow the official PHP security advisory and applicable operating system or distribution vendor guidance to identify affected installations, deploy available fixes, and verify remediation.

The following guidance can help security teams determine the appropriate remediation path:

PHP environment	Recommended action
Supported PHP branches	Upgrade to the applicable security-fixed release identified in the official PHP advisory.
Older or end-of-life PHP branches	Upgrade to a supported release or follow verified vendor security guidance.
Distribution-managed PHP packages	Check the distribution vendor’s security advisory and installed package status, including any backported fixes.

Linux distributions may backport security fixes without changing the upstream PHP version reported in HTTP headers. As a result, a version banner alone cannot reliably establish whether a system has been patched.

Temporary configuration changes may reduce exposure to specific exploitation paths but should not be considered substitutes for security updates.

Network-derived telemetry complements remediation by helping security teams investigate suspicious traffic patterns and identify systems that may require additional attention. Confirming patch status, however, requires authoritative software inventory, package, and configuration information.

From Network Visibility to Informed Security Response

PHP2Shell illustrates a broader challenge facing security teams: identifying potential exposure is only the beginning. Organizations also need to understand what’s happening across their infrastructure, investigate suspicious activity, and prioritize their response with confidence.

The Gigamon Deep Observability Pipeline helps address this challenge by delivering trusted network-derived telemetry to security and observability tools. With application-aware context from Gigamon AMI, security teams gain an independent source of evidence to investigate potential threats, correlate activity across systems, and make more informed response decisions.

Network-derived telemetry complements vulnerability scanning, endpoint security, and patch management with independent, application-aware evidence. Together, these capabilities help organizations reduce blind spots, strengthen security investigations, and respond more effectively as new threats emerge.

Sources

• Wiz Research — PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
• PHP.net — Security advisory: Critical remote code execution vulnerabilities, update now (Oct. 21, 2026)
• GHSA-w8hw-w9fx-j79w — CVE-2026-109618
• GHSA-6wmf-4rv5-p3rp — CVE-2026-109619