PHP2Shell CVE-2026-109618 and CVE-2026-109619: Pre-Patch Exploitation, Detection Guidance, and Current Threat Activity

Two Critical Use-After-Free Flaws in PHP Core Are Under Active Exploitation

The PHP project shipped emergency patches on October 21, 2026, for CVE-2026-109618 and CVE-2026-109619, two unauthenticated remote code execution vulnerabilities in the PHP engine itself [8][9]. Both carry a CVSS v4.0 score of 9.2 [15]. CVE-2026-109619 is classified as CWE-416 (use-after-free); CVE-2026-109618 involves memory corruption due to improper cleanup during out-of-memory handling, though some vendors also classify it as CWE-416 [15]. Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 [2][9]. The vulnerable code dates back to PHP 5.4.0, released in 2012 [1][3].

Amazon Threat Intelligence recorded the first exploitation attempt against its MadPot honeypot network on October 17, four days before public disclosure and while the flaws were still under embargo [2][13]. By the time patches shipped, watchTowr, Cloudflare, Hadrian, Patchstack, and VulnCheck all reported active exploitation attempts or scanning [4][5][13][14]. As of October 22, neither CVE has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and no organization has publicly confirmed a breach [4][17].

Background: Discovery and Broken Embargo

The vulnerabilities were independently discovered by two parties: Ryan Austin of Calif as part of the OpenAI "Patch the Planet" project, and researchers Sagi Tzadik, Shir Tamari, Nir Ohfeld, and Tomer Schwartz at Wiz [1][9]. Austin used OpenAI's GPT-5.6 Sol model; the Wiz team used Gemini 4 Argon, GPT-5.6 Sol, and their own Wiz Atlas tool [1]. The underlying out-of-memory bug behind CVE-2026-109618 was flagged during an internal PHP audit in 2024, but the development team could not reach consensus on a fix and deprioritized the issue because no working exploit existed at that time [1].

Coordinated disclosure was scheduled for Thursday, October 22, at 11:00 ET [16]. That plan collapsed on October 20, when a Hacker News post claimed two PHP RCE flaws rated CVSS 10.0 would be disclosed on Thursday [11]. The poster reportedly stated they had no evidence beyond informal sourcing [11]. watchTowr CEO Benjamin Harris confirmed the leak was genuine and that the flaws were under embargo [14][21]. PHP published an advance notice at 19:33 UTC that evening, naming neither CVE, and moved the release to October 21 at 14:00 UTC [11][12]. The patches actually appeared at approximately 13:34 to 13:52 UTC, ahead of even the accelerated schedule [16][17].

CERT-EU issued an initial notification on October 20, followed by the full Security Advisory 2026-018 on October 21, naming both CVEs [7][19]. NCSC-NL stated before the release that it had no indication of active exploitation but expected large-scale exploitation in the short term since PoCs existed [4].

CVE-2026-109618: OOM Corruption (GHSA-w8hw-w9fx-j79w)

Out-of-memory handling can interrupt PHP while internal request data is only partially initialized [5][8]. The cleanup routine then processes the invalid, partially-initialized data as though it were valid [8]. On mod_php, this occurs during request startup before any application code runs [9][12]. Multipart parsing provides attackers several ways to trigger OOM while staying inside apparent limits, such as sending parts with an unbounded number of headers [12].

CVE-2026-109619: Stale Global State (GHSA-6wmf-4rv5-p3rp)

Request-owned internal state can survive after its backing memory has been freed [5][8]. A later request handled by the same worker may use that stale state before normal initialization resets it [5]. This is a heap use-after-free that enables memory disclosure, and ultimately RCE, with the web worker's privileges [9]. The session upload progress path is the primary demonstrated attack vector for this CVE [4].

Affected Configurations

Every PHP installation that serves web requests is affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed [9][16]. The PHP security team considers the risk highest for mod_php: "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs" [9]. Datadog independently confirmed that application-level authentication cannot block the attack because PHP processes the malicious request before any application code executes [6].

Calif reported successful unauthenticated RCE against Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1, and WHMCS [3].

ASLR and Exploitation Constraints

VulnCheck's early analysis found the vulnerabilities exploitable for RCE on ARM64 systems and x86 systems without ASLR [5]. ASLR reduces the available attack surface. However, VulnCheck later produced a weaponized exploit for CVE-2026-109618 that achieves RCE on x86-64 platforms with ASLR enabled and display_errors=off, the recommended production configuration [5].

Sansec noted that a PHP2Shell attack needs specific knowledge of the target server and specific conditions on it, and that most public PoC exploits require the target application to have a local file inclusion bug [3]. This is an important nuance: mass exploitation may be less trivial than the initial panic suggested, though the VulnCheck weaponized exploit contradicts the claim that default installations are safe.

Current Exploitation Activity

The timeline of observed exploitation:

• October 17, 07:43 UTC: Amazon Threat Intelligence recorded the first exploitation attempt from a commercial anonymization network against its MadPot honeypots [2][13]. Amazon stated: "The targeting of a honeypot from an anonymized IP address suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure" [13].
• October 21, 07:34 UTC: Patchstack began receiving reports of attacks from hosting company partners [20].
• October 21, 07:43 UTC: Cloudflare's Dane Knecht reported "seeing early attacks emerging" and said the company deployed firewall rules for all customers, including free plans [2][20].
• October 21, 08:36 UTC: VulnCheck logged probing activity using user-agent string php2shell-scan/109618 against multiple hosts [5][22].
• October 21, 14:19 UTC: watchTowr published a new advisory stating it is "observing active exploitation attempts of both CVE-2026-109618 and CVE-2026-109619" through its global honeypot network [10][14][17].
• October 21, afternoon: Amazon reported that "PHP2Shell is now being broadly exploited in the wild," with payloads and infrastructure suggesting multiple actors [2][13].

VulnCheck told SecurityWeek that at least one Chinese IP address unsuccessfully attempted to exploit PHP2Shell to deploy a webshell [13]. Hadrian reported exploitation at scale, mostly through the session upload progress path [4]. Dark web forum activity showed users requesting working exploits and expressing intent to begin compromising servers [7].

Counterpoint: multiple organizations, including CISA, Huntress, and the Canadian Centre for Cyber Security, stated as of October 21 that they had not observed successful exploitation on live systems [4][17][18]. SecurityWeek reported that watchTowr "has not observed successful attempts" despite seeing broad exploitation activity [17]. Sansec revised its initial expectation of mass exploitation, noting that the attack requires specific knowledge of the target and that "nobody has shown" a single request that works against any vulnerable server the way Log4Shell or Shellshock did [3].

Exposure Estimates

Silas Cutler estimated over 1.3 million internet-exposed hosts as potentially vulnerable; a Shodan search by Henk Poley counted over 1.9 million [2]. CybelAngel estimated 2.24 million internet-facing PHP hosts, with 59% running versions that will receive no upstream fix [16]. VulnCheck, VirusTotal, and Censys data indicated more than 1 million PHP servers running unpatched releases as of October 21 [13].

IOC Table

Amazon stated that the six MadPot IPs include shared anonymization infrastructure and should be investigated, not blocked outright [4].

MITRE ATT&CK Mapping

Web Server Logs

The most immediately actionable detection vector is the user-agent string php2shell-scan/109618, observed by VulnCheck across multiple hosts during early scanning waves on October 21 [5]. Search access logs for this string. Sophisticated actors will not use this UA, but opportunistic scanners and script-based tools will.

The attack chain for CVE-2026-109618 involves large multipart form submissions designed to trigger OOM conditions during request initialization [6][12]. Look for:

• HTTP POST requests with unusually large Content-Length values or multipart bodies containing many parts with excessive headers [12]
• PHP fatal errors referencing memory exhaustion (Allowed memory size of X bytes exhausted) occurring during request initialization rather than during application execution [6]
• Requests to /index.php (or any PHP endpoint) followed by 500-series responses in rapid succession from the same source IP [5]

For CVE-2026-109619, the session upload progress path is the primary exploitation route [4]. Monitor for:

• Requests containing session.upload_progress parameters from external sources, particularly when paired with unusual session cookie values [4][6]
• PHP worker processes spawning unexpected child shell processes (/bin/sh, /bin/bash, cmd.exe) [6]

Sigma Rule: PHP2Shell Scanning Activity

title: PHP2Shell Scanner User-Agent Detection
id: f8c2e3a1-7d4b-4e9f-a123-456789abcdef
status: experimental
author: RedSheepSec
date: 2026/10/22
description: Detects the php2shell-scan user-agent string observed in early exploitation scanning
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-user-agent|contains: 'php2shell-scan'
    condition: selection
falsepositives:
    - Legitimate vulnerability scanners using the same user-agent
level: high
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2026.109618
    - cve.2026.109619

Sigma Rule: PHP OOM During Request Initialization

title: PHP Memory Exhaustion During Request Initialization
id: a1b2c3d4-5678-9abc-def0-123456789abc
status: experimental
author: RedSheepSec
date: 2026/10/22
description: Detects PHP fatal errors from memory exhaustion that may indicate CVE-2026-109618 exploitation attempts
logsource:
    category: application
    product: php
detection:
    selection:
        |EventData|contains|all:
            - 'Allowed memory size'
            - 'bytes exhausted'
    filter_normal:
        EventData|contains:
            - 'composer'
            - 'artisan'
    condition: selection and not filter_normal
falsepositives:
    - Legitimate large file uploads or resource-intensive PHP operations
level: medium
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2026.109618

Sigma Rule: Unexpected Shell Spawned by PHP Worker

title: Shell Process Spawned by PHP Worker
id: b2c3d4e5-6789-abcd-ef01-23456789abcd
status: experimental
author: RedSheepSec
date: 2026/10/22
description: Detects shell processes spawned by PHP-FPM or Apache PHP worker processes, indicating possible post-exploitation from PHP2Shell or similar RCE
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        ParentImage|endswith:
            - '/php-fpm'
            - '/php'
            - '/php-cgi'
            - '/httpd'
            - '/apache2'
        Image|endswith:
            - '/sh'
            - '/bash'
            - '/dash'
    condition: selection
falsepositives:
    - Legitimate PHP applications that execute shell commands (e.g., deployment scripts)
level: high
tags:
    - attack.execution
    - attack.t1059.004
    - cve.2026.109618
    - cve.2026.109619

Network-Level Detection

Controls at a reverse proxy or WAF boundary in front of PHP can block requests before they reach the vulnerable parser [6]. Cloudflare deployed firewall rules for all customers on October 21 [20]. Organizations running their own WAF should build rules to:

• Block or alert on POST requests with multipart bodies exceeding a defined part count or header count threshold
• Rate-limit or flag rapid sequences of requests from a single source that produce 500 errors on PHP endpoints
• Monitor for the IOC IP addresses listed above in firewall and proxy logs

Endpoint and Process Monitoring

Datadog recommended looking for unexpected shell processes spawned by PHP workers and for memory-exhaustion errors during request initialization [6]. On Linux hosts, auditd or an EDR agent should flag any execve call from a PHP worker process that launches a shell or common post-exploitation tools (wget, curl, python, perl, nc).

Analysis

PHP2Shell represents the intersection of two trends: AI-assisted vulnerability research lowering the barrier to discovering complex memory-safety bugs, and the enduring fragility of memory-unsafe codebases. Wiz researchers stated: "The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier" [8].

The practical exploitability question is critical. Sansec's analysis that most public PoCs require a local file inclusion bug or non-default configurations [3] conflicts with VulnCheck's claim of a weaponized exploit working on x86-64 with ASLR and recommended production settings [5]. This gap suggests that exploitation difficulty varies substantially by target configuration, and that more capable actors with private exploits pose a different level of risk than script-based opportunistic scanning.

The pre-disclosure exploitation observed by Amazon on October 17 [2][13] is concerning. The use of anonymization infrastructure suggests a threat actor who either discovered the flaws independently, obtained them through the supply chain of researchers and vendors with advance access, or had access to the embargo communications. Amazon noted it remains unclear how the actor acquired exploit information prior to disclosure [13].

Kevin Beaumont stated: "The PHP situation will lead to a mass of incidents, it's one of the biggest vulns in years" [8]. Kelly Shortridge noted that "the gap between disclosure and widespread, repeatable exploitation is typically hours to a few days for vulnerabilities of this severity and attack ROI" [18].

References

1. PHP2Shell - Wikipedia
2. Tenable - php2shell FAQ
3. Sansec - PHP2Shell: PHP RCE
4. Brandefense - PHP2Shell Fixed PHP Versions
5. VulnCheck - PHP2Shell Vulnerabilities
6. Datadog Security Labs - PHP2Shell
7. SOCRadar - PHP2Shell CVE-2026-109618 & 109619
8. Help Net Security - PHP2Shell patched
9. BleepingComputer - PHP ships emergency patches
10. The Hacker News - PHP Issues Emergency Patches
11. The Hacker News - PHP2Shell: Two Unpatched Critical PHP RCE Flaws
12. TuxCare - PHP2Shell Patches for EOL PHP
13. SecurityWeek - PHP2Shell Exploitation Started Days Before Patches
14. watchTowr - PHP Remote Code Execution PHP2Shell
15. Black Kite - PHP2Shell: Two Critical RCE Vulnerabilities
16. CybelAngel - What We Know About php2shell
17. Rescana - Two Critical PHP Vulnerabilities Fixed
18. CyberScoop - PHP releases emergency fixes
19. OffSec Radar - PHP2Shell Mass Exploitation
20. Roland Farkas - PHP2Shell: What We Know
21. PhishingBox - php2shell: The PHP Bug That Does Not Need Anyone to Click
22. Aviatrix - php2shell: Two Critical PHP RCEs

Event Timeline

Entity Relationships

Diamond Model

Hunt Guide: PHP2Shell CVE-2026-109618 and CVE-2026-109619 Pre-Patch Exploitation and Active Scanning

Attribution: Rules adapted, ported, or quoted from a public source retain that source's author (e.g. SigmaHQ / Florian Roth, Elastic, Emerging Threats, Abuse.ch, or the cited vendor/researcher) and carry an attribution credit. Rules without a credit were authored in-house by RedSheepSec. If you reuse a rule, preserve its stated attribution.

Hypothesis: If threat actors are exploiting PHP2Shell (CVE-2026-109618 or CVE-2026-109619) against our PHP web infrastructure, we expect to observe the php2shell-scan/109618 user-agent string in web access logs, anomalous multipart POST requests generating HTTP 500 responses and PHP memory exhaustion errors, connections from known exploitation IPs, and unexpected shell processes spawned by PHP worker processes.

Intelligence Summary: CVE-2026-109618 and CVE-2026-109619 are two unauthenticated remote code execution vulnerabilities in the PHP engine (CVSS v4.0 9.2) patched on October 21, 2026. Amazon Threat Intelligence recorded exploitation attempts four days before disclosure, and multiple vendors report active scanning and exploitation attempts from numerous source IPs. No organization has publicly confirmed a breach on production systems, but weaponized exploits exist for x86-64 with ASLR enabled, and over one million internet-facing PHP servers remained unpatched as of October 21.

Confidence: Moderate | Priority: Critical

Scope

• Networks: All network segments hosting PHP-based web applications, including DMZ web servers, internal application servers running PHP-FPM or mod_php, Docker/container environments with PHP, and any vendor appliances running embedded PHP (cPanel, Plesk, phpMyAdmin, Nextcloud). Include cloud-hosted PHP instances in AWS, Azure, and Oracle Cloud.
• Timeframe: October 15 through present. Pre-disclosure exploitation was recorded October 17; extend lookback to October 15 to capture any precursor scanning. Continue active monitoring for at least 30 days given the large population of unpatched servers.
• Priority Systems: Internet-facing PHP servers running Apache mod_php (highest risk per PHP security team). Any system running Magento, WordPress, Drupal, Joomla, phpMyAdmin, Nextcloud, Roundcube, or WHMCS. PHP servers running versions below 8.2 that will not receive upstream patches. Systems without WAF protection.

MITRE ATT&CK Techniques

T1190: Exploit Public-Facing Application (Initial Access) [P1]

Both CVEs enable unauthenticated RCE against any PHP web server before application code executes. CVE-2026-109618 exploits OOM-triggered memory corruption during multipart request parsing; CVE-2026-109619 exploits a use-after-free via stale global state, primarily through the session upload progress path. Attack occurs at the PHP engine level, bypassing application-layer authentication.

Splunk SPL:

index=apache sourcetype=apache:access ("php2shell-scan" OR "session.upload_progress") | eval src_ip=clientip | stats count earliest(_time) as first_seen latest(_time) as last_seen values(uri) as uris values(useragent) as user_agents by src_ip | where count > 2 | sort -count | table src_ip count first_seen last_seen uris user_agents

Elastic KQL:

(http.request.headers.user-agent:*php2shell-scan* OR url.query:*session.upload_progress*) AND (http.response.status_code:500 OR http.response.status_code:502)

Sigma Rule:

title: PHP2Shell Scanner User-Agent Detection
id: f8c2e3a1-7d4b-4e9f-a123-456789abcdef
status: experimental
author: RedSheepSec
date: 2026/10/22
description: Detects the php2shell-scan user-agent string observed in early exploitation scanning for CVE-2026-109618 and CVE-2026-109619
logsource:
    category: webserver
detection:
    selection:
        cs-user-agent|contains: 'php2shell-scan'
    condition: selection
falsepositives:
    - Legitimate vulnerability scanners using the same user-agent string
level: high
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2026.109618
    - cve.2026.109619

The php2shell-scan/109618 UA string is used by opportunistic scanners. Sophisticated actors will not use this UA; absence does not indicate absence of exploitation. Also hunt for high-volume multipart POSTs to PHP endpoints producing 500-series errors.

T1190: Exploit Public-Facing Application (Initial Access) [P2]

Detection of anomalous multipart POST requests with excessive content lengths or rapid 500-error sequences against PHP endpoints, characteristic of CVE-2026-109618 OOM exploitation attempts.

Splunk SPL:

index=corelight sourcetype=corelight_http method=POST uri_path="*.php" status_code>=500
| bin _time span=1m
| stats count as error_count dc(uri_path) as unique_paths avg(request_body_len) as avg_body_len max(request_body_len) as max_body_len by _time id_orig_h
| where error_count > 10 AND max_body_len > 1048576
| table _time id_orig_h error_count unique_paths avg_body_len max_body_len

Elastic KQL:

http.request.method:POST AND url.path:*.php AND http.response.status_code:>=500 AND http.request.body.bytes:>1048576

Sigma Rule:

title: Rapid HTTP 500 Errors on PHP Endpoints from Single Source
id: c3d4e5f6-7890-abcd-ef12-345678901234
status: experimental
author: RedSheepSec
date: 2026/10/22
description: Detects rapid sequences of HTTP 500 errors on PHP endpoints from a single source IP, which may indicate CVE-2026-109618 OOM exploitation attempts
logsource:
    category: webserver
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem|endswith: '.php'
        sc-status:
            - 500
            - 502
            - 503
    condition: selection | count() by c-ip > 10
falsepositives:
    - Application bugs causing legitimate 500 errors
    - Load testing
level: medium
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2026.109618

Tune the threshold (count > 10 per minute) based on normal error rates in your environment. Correlate with content-length values exceeding 1MB on POST requests to PHP endpoints.

T1059.004: Unix Shell (Execution) [P1]

Post-exploitation from PHP2Shell RCE results in PHP worker processes (php-fpm, apache2, httpd) spawning shell processes. This is the primary indicator of successful exploitation as opposed to mere scanning or failed attempts.

Splunk SPL:

index=linux-server sourcetype=linux:audit type=EXECVE
| search (a0="/bin/sh" OR a0="/bin/bash" OR a0="/bin/dash" OR a0="/usr/bin/sh" OR a0="/usr/bin/bash")
| join pid [search index=linux-server sourcetype=linux:audit type=EXECVE (a0="*php*" OR a0="*httpd*" OR a0="*apache2*") | rename pid as ppid | fields ppid]
| table _time host a0 a1 a2 pid ppid
| sort _time

Elastic KQL:

process.parent.executable:(*php-fpm* OR *php-cgi* OR *httpd* OR *apache2*) AND process.executable:(*sh OR *bash OR *dash)

Sigma Rule:

title: Shell Process Spawned by PHP Worker
id: b2c3d4e5-6789-abcd-ef01-23456789abcd
status: experimental
author: RedSheepSec
date: 2026/10/22
description: Detects shell processes spawned by PHP-FPM or Apache PHP worker processes, indicating possible post-exploitation from PHP2Shell or similar RCE
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        ParentImage|endswith:
            - '/php-fpm'
            - '/php'
            - '/php-cgi'
            - '/httpd'
            - '/apache2'
        Image|endswith:
            - '/sh'
            - '/bash'
            - '/dash'
    condition: selection
falsepositives:
    - Legitimate PHP applications that execute shell commands such as deployment scripts or cron-triggered tasks
level: high
tags:
    - attack.execution
    - attack.t1059.004
    - cve.2026.109618
    - cve.2026.109619

This detection fires on any shell spawned by a PHP worker. Baseline your environment for legitimate PHP exec() and system() calls to reduce false positives. Also look for wget, curl, python, perl, and nc spawned by PHP workers.

T1059.004: Unix Shell (Execution) [P1]

Extended post-exploitation detection covering common download and lateral movement tools spawned by PHP workers after successful RCE.

Splunk SPL:

index=crowdstrike sourcetype="crowdstrike:events:sensor" event_simpleName=ProcessRollup2
| where match(ParentImageFileName, "(?i)(php-fpm|php-cgi|php|httpd|apache2)")
| where match(ImageFileName, "(?i)(sh|bash|dash|wget|curl|python|perl|nc|ncat|socat|chmod|chown)")
| stats count earliest(_time) as first_seen latest(_time) as last_seen values(CommandLine) as commands by ComputerName ParentImageFileName ImageFileName
| sort -count
| table ComputerName ParentImageFileName ImageFileName commands count first_seen last_seen

Elastic KQL:

process.parent.name:(php-fpm OR php-cgi OR php OR httpd OR apache2) AND process.name:(sh OR bash OR dash OR wget OR curl OR python* OR perl OR nc OR ncat OR socat OR chmod)

Sigma Rule:

title: Post-Exploitation Tool Spawned by PHP Worker
id: d4e5f6a7-8901-bcde-f234-567890123456
status: experimental
author: RedSheepSec
date: 2026/10/22
description: Detects common post-exploitation tools spawned by PHP worker processes, indicating successful RCE exploitation such as PHP2Shell
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        ParentImage|endswith:
            - '/php-fpm'
            - '/php'
            - '/php-cgi'
            - '/httpd'
            - '/apache2'
        Image|endswith:
            - '/wget'
            - '/curl'
            - '/python'
            - '/python3'
            - '/perl'
            - '/nc'
            - '/ncat'
            - '/socat'
    condition: selection
falsepositives:
    - PHP applications legitimately calling curl or wget for API requests
level: critical
tags:
    - attack.execution
    - attack.t1059.004
    - cve.2026.109618
    - cve.2026.109619

curl and wget spawned by PHP workers can be legitimate in some applications. Correlate with the destination IP or URL to differentiate benign API calls from payload downloads.

T1505.003: Server Software Component: Web Shell (Persistence) [P2]

VulnCheck reported at least one Chinese IP attempting to deploy a webshell via PHP2Shell exploitation. Post-exploitation webshell deployment provides persistent access to compromised PHP servers.

Splunk SPL:

index=linux-server (sourcetype=linux:audit OR sourcetype=auditd) type=SYSCALL (syscall=2 OR syscall=257) success=yes
| search (name="*.php" OR name="*.phtml" OR name="*.phar")
| where NOT match(name, "(cache|session|tmp|log)")
| search (exe="*php*" OR exe="*httpd*" OR exe="*apache2*")
| stats count earliest(_time) as first_seen values(name) as files_created by host exe
| where count > 0
| table first_seen host exe files_created count

Elastic KQL:

event.category:file AND event.action:creation AND file.extension:(php OR phtml OR phar) AND process.executable:(*php* OR *httpd* OR *apache2*)

Sigma Rule:

title: PHP File Written by Web Server Process
id: e5f6a7b8-9012-cdef-3456-789012345678
status: experimental
author: RedSheepSec
date: 2026/10/22
description: Detects PHP files written to disk by web server or PHP worker processes, which may indicate webshell deployment after PHP2Shell exploitation
logsource:
    category: file_event
    product: linux
detection:
    selection_process:
        Image|endswith:
            - '/php-fpm'
            - '/php'
            - '/php-cgi'
            - '/httpd'
            - '/apache2'
    selection_file:
        TargetFilename|endswith:
            - '.php'
            - '.phtml'
            - '.phar'
    filter_normal:
        TargetFilename|contains:
            - '/cache/'
            - '/session/'
            - '/tmp/'
    condition: selection_process and selection_file and not filter_normal
falsepositives:
    - CMS systems writing PHP cache files
    - Plugin installations
level: high
tags:
    - attack.persistence
    - attack.t1505.003
    - cve.2026.109618
    - cve.2026.109619

CMS platforms such as WordPress and Drupal write PHP files during plugin and theme updates. Correlate with expected change windows and the specific file paths to reduce false positives.

Indicators of Compromise

IOC Sweep Queries (Splunk):

index=corelight sourcetype=corelight_conn (id_orig_h="103.216.220.92" OR id_resp_h="103.216.220.92") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="31.223.184.166" OR id_resp_h="31.223.184.166") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="37.19.200.5" OR id_resp_h="37.19.200.5") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="134.209.159.64" OR id_resp_h="134.209.159.64") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="103.114.163.188" OR id_resp_h="103.114.163.188") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="95.217.98.37" OR id_resp_h="95.217.98.37") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="85.11.167.243" OR id_resp_h="85.11.167.243") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="45.198.224.169" OR id_resp_h="45.198.224.169") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="221.14.159.134" OR id_resp_h="221.14.159.134") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="109.71.252.97" OR id_resp_h="109.71.252.97") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="91.90.123.25" OR id_resp_h="91.90.123.25") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="167.148.201.106" OR id_resp_h="167.148.201.106") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_conn (id_orig_h="92.118.112.100" OR id_resp_h="92.118.112.100") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_resp_p) as dest_ports by id_orig_h id_resp_h | table first_seen last_seen id_orig_h id_resp_h dest_ports count

index=corelight sourcetype=corelight_dns query="*vpsvault.host*" | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_orig_h) as src_ips values(answers) as resolved_ips by query | table first_seen last_seen query src_ips resolved_ips count

index=corelight sourcetype=corelight_dns query="*php2shell.com*" | stats count earliest(_time) as first_seen latest(_time) as last_seen values(id_orig_h) as src_ips by query | table first_seen last_seen query src_ips count

index=crowdstrike sourcetype="crowdstrike:events:sensor" SHA256HashData="150ae88f0999032e2a6113501d6082f54a3ed98d02427b21a96e773a27d7bf16" | stats count earliest(_time) as first_seen latest(_time) as last_seen by ComputerName ImageFileName | table first_seen last_seen ComputerName ImageFileName count

YARA Rules

PHP2Shell_Exploitation_Payload: Detects PHP2Shell exploitation artifacts including the known malicious file hash and common webshell patterns associated with PHP2Shell post-exploitation

rule PHP2Shell_Exploitation_Payload
{
    meta:
        description = "Detects artifacts associated with PHP2Shell CVE-2026-109618/109619 exploitation"
        author = "RedSheepSec"
        date = "2026-10-22"
        reference = "https://www.vulncheck.com/blog/php2shell-vulnerabilities"
        hash = "150ae88f0999032e2a6113501d6082f54a3ed98d02427b21a96e773a27d7bf16"

    strings:
        $ua = "php2shell-scan/109618" ascii wide
        $session_upload = "session.upload_progress" ascii wide
        $oom_trigger1 = "Content-Disposition: form-data" ascii
        $shell1 = "/bin/sh -c" ascii
        $shell2 = "/bin/bash -c" ascii
        $webshell_eval = "eval($_" ascii
        $webshell_system = "system($_" ascii
        $webshell_exec = "exec($_" ascii
        $webshell_passthru = "passthru($_" ascii

    condition:
        $ua or
        ($session_upload and any of ($shell*)) or
        (any of ($webshell*) and filesize < 10KB)
}

Suricata Rules

SID 2026101: Detects the php2shell-scan/109618 user-agent string in HTTP requests, indicating active PHP2Shell scanning activity

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"REDSHEEPSEC PHP2Shell Scanner UA Detected - CVE-2026-109618"; flow:to_server,established; http.user_agent; content:"php2shell-scan"; nocase; classtype:web-application-attack; sid:2026101; rev:1; metadata:created_at 2026_10_22, cve CVE-2026-109618;)

SID 2026102: Detects HTTP traffic from known PHP2Shell exploitation IP 109.71.252.97 (AbuseIPDB confidence 100%, 243 reports)

alert ip 109.71.252.97 any -> $HOME_NET any (msg:"REDSHEEPSEC PHP2Shell Exploitation Source IP 109.71.252.97"; classtype:web-application-attack; sid:2026102; rev:1; metadata:created_at 2026_10_22, cve CVE-2026-109618;)

SID 2026103: Detects HTTP traffic from known PHP2Shell exploitation IP 91.90.123.25 (AbuseIPDB confidence 72%)

alert ip 91.90.123.25 any -> $HOME_NET any (msg:"REDSHEEPSEC PHP2Shell Exploitation Source IP 91.90.123.25"; classtype:web-application-attack; sid:2026103; rev:1; metadata:created_at 2026_10_22, cve CVE-2026-109618;)

SID 2026104: Detects HTTP traffic from known PHP2Shell exploitation IP 221.14.159.134 (CN, webshell deployment attempt)

alert ip 221.14.159.134 any -> $HOME_NET any (msg:"REDSHEEPSEC PHP2Shell Webshell Deployer IP 221.14.159.134"; classtype:web-application-attack; sid:2026104; rev:1; metadata:created_at 2026_10_22, cve CVE-2026-109618;)

SID 2026105: Detects HTTP POST to PHP endpoints with session.upload_progress parameter, the primary exploitation path for CVE-2026-109619

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"REDSHEEPSEC PHP2Shell CVE-2026-109619 session.upload_progress Exploitation Attempt"; flow:to_server,established; http.method; content:"POST"; http.uri; content:".php"; http.request_body; content:"session.upload_progress"; nocase; classtype:web-application-attack; sid:2026105; rev:1; metadata:created_at 2026_10_22, cve CVE-2026-109619;)

SID 2026106: Detects DNS query for vpsvault.host, hosting provider for PHP2Shell exploitation infrastructure

alert dns $HOME_NET any -> any any (msg:"REDSHEEPSEC PHP2Shell Infrastructure DNS Lookup vpsvault.host"; dns.query; content:"vpsvault.host"; nocase; classtype:bad-unknown; sid:2026106; rev:1; metadata:created_at 2026_10_22;)

Data Source Requirements

Recommendations

• Patch all PHP installations immediately to versions 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Prioritize internet-facing servers running Apache mod_php, which the PHP security team identifies as highest risk. Restart all PHP worker processes after patching.
• Inventory all PHP installations across the enterprise, including PHP embedded in vendor appliances (cPanel, Plesk), Docker containers, and application stacks. Use php -v on managed hosts and scan for PHP response headers (X-Powered-By) on all web assets.
• Deploy all detection queries from this hunt guide (Appendix: Splunk queries, Sigma rules, Suricata rules) across production Splunk, Elastic, and network IDS instances within 24 hours.
• Apply interim mitigations on any system that cannot be patched within 24 hours: set session.upload_progress.enabled=0 in php.ini; on PHP 8.5, also set fatal_error_backtraces=0. Place unpatched PHP behind a WAF or reverse proxy capable of filtering malicious multipart payloads.
• Block or alert on the 13 IOC IP addresses with moderate or higher confidence (103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37, 85.11.167.243, 45.198.224.169, 221.14.159.134, 109.71.252.97, 91.90.123.25, 167.148.201.106, 92.118.112.100) at the perimeter firewall. Amazon notes the MadPot IPs include shared anonymization infrastructure; investigate connections to these IPs rather than blocking blindly.
• Isolate or retire PHP installations running EOL versions (8.1 and earlier). Contact distribution vendors or TuxCare for backported fixes for PHP 7.4, 8.0, and 8.1. Versions below 7.4 have no available patches.
• Ensure auditd or an EDR agent is deployed on all Linux web servers hosting PHP, configured to log EXECVE syscalls and file creation events. This is the primary detection path for successful post-exploitation.
• Verify WAF or reverse proxy rules are in place to limit multipart POST body size and part count on PHP endpoints. Coordinate with application teams to set appropriate thresholds that do not break legitimate file uploads.

Sources

• PHP2Shell - Wikipedia
• Tenable - php2shell FAQ
• Sansec - PHP2Shell: PHP RCE
• Brandefense - PHP2Shell Fixed PHP Versions
• VulnCheck - PHP2Shell Vulnerabilities
• Datadog Security Labs - PHP2Shell
• SOCRadar - PHP2Shell CVE-2026-109618 & 109619
• Help Net Security - PHP2Shell patched
• BleepingComputer - PHP ships emergency patches
• The Hacker News - PHP Issues Emergency Patches
• The Hacker News - PHP2Shell: Two Unpatched Critical PHP RCE Flaws
• TuxCare - PHP2Shell Patches for EOL PHP
• SecurityWeek - PHP2Shell Exploitation Started Days Before Patches
• watchTowr - PHP Remote Code Execution PHP2Shell
• Black Kite - PHP2Shell: Two Critical RCE Vulnerabilities
• CybelAngel - What We Know About php2shell
• Rescana - Two Critical PHP Vulnerabilities Fixed
• CyberScoop - PHP releases emergency fixes
• OffSec Radar - PHP2Shell Mass Exploitation
• Roland Farkas - PHP2Shell: What We Know
• PhishingBox - php2shell: The PHP Bug That Does Not Need Anyone to Click
• Aviatrix - php2shell: Two Critical PHP RCEs