PHP2Shell Exploitation Attempts Surge: Detection, Hardening, and Remediation Guide

Wiz Research has been tracking a wave of exploitation attempts against a recently disclosed PHP-based attack vector commonly referred to as “PHP2Shell.” While the research team notes that observed attempts have not resulted in successful compromises so far, the campaign is important for defenders because it demonstrates how quickly internet-facing web technologies attract probing and weaponization after public disclosure. Organizations running PHP-backed web applications—especially those with exposed administrative interfaces, misconfigured runtimes, outdated frameworks, or internet-accessible development endpoints—should treat this activity as an immediate warning signal. Even unsuccessful exploitation attempts can reveal exposed assets, weak runtime controls, and gaps in detection that more capable operators may exploit later.

Technical Analysis

Based on the available reporting, PHP2Shell is being used as a shorthand for a family of exploitation attempts aimed at turning vulnerable PHP execution paths into command execution on the underlying host. The key takeaway from Wiz’s monitoring is not merely that attempts are occurring, but that attackers are already iterating on payloads, delivery methods, and post-exploitation behavior. In practical terms, this usually means defenders should expect a blend of automated scanning, opportunistic exploitation, and follow-on manual activity where a target appears weak or uniquely exposed.

At the time of writing, the referenced source does not provide a specific CVE identifier in the supplied title or summary. For that reason, this article does not invent one. Defenders should focus on the observable technique: attempts to abuse a PHP runtime or PHP-backed application in order to reach shell execution, typically by submitting crafted HTTP requests to vulnerable endpoints or by abusing unsafe file upload, template rendering, code evaluation, command injection, or insecure deserialization patterns in PHP applications. In many incidents, the first observable stage is not the final payload but a low-cost probe designed to identify whether a target can process attacker-controlled input and return evidence of command execution.

The Wiz research note that none of the observed attempts have succeeded is significant. That outcome is likely due to a combination of controls and environmental mismatches rather than a lack of attacker interest. Common blockers in these scenarios include:

• patched or unaffected application versions,
• hardened PHP runtime settings,
• disabled dangerous functions such as exec, shell_exec, system, and passthru,
• restrictive web server process permissions,
• containerized deployments with read-only filesystems,
• egress filtering that prevents callback or payload staging,
• WAF or reverse proxy rules that interrupt malformed requests,
• application frameworks that reject dangerous parameterization patterns,
• and ephemeral or short-lived compute that breaks persistence attempts.

This does not mean defenders can assume safety. Exploitation attempts that fail in one environment often succeed in another where the same stack is deployed with a slightly different configuration. Attackers actively test variations because PHP ecosystems are highly heterogeneous: CMS platforms, plugins, custom APIs, legacy intranet applications, developer tools, and forgotten staging servers can all share the same internet exposure while differing radically in patch level and hardening.

The most important exposure trend is that internet visibility changes quickly after disclosure. As defenders investigate vulnerable components, temporarily expose diagnostic endpoints, or spin up test systems, the attack surface can expand rather than shrink. Conversely, as teams identify and isolate vulnerable instances, observed exposure may decline. That fluctuation is operationally relevant: SOC teams should expect waves of scanning that track public discussion, exploit availability, and attacker tooling updates.

Detection & Response

Because this is a technical threat, defenders should implement targeted detections for pre-exploitation probes, command execution attempts, and post-exploitation artifacts. The most effective telemetry sources are web server logs, application logs, WAF alerts, process creation events from web and PHP worker hosts, container runtime logs, and network egress telemetry.

The following detections are intentionally scoped to behaviors defenders can realistically hunt for without overwhelming the environment with generic PHP noise.

---
title: PHP Web Process Command Execution Attempt
id: 8f2b8a0c-5a3b-4f4b-9d66-0f2a2f0f9c21
status: experimental
description: Detects suspicious shell command execution initiated by PHP or web server worker processes, which may indicate attempted PHP2Shell exploitation.
references:
  - https://www.wiz.io/blog/php2shell-exploitation-so-far
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/02/12
tags:
  - attack.execution
  - attack.t1059
  - attack.t1203
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/php'
      - '/php-fpm'
      - '/php-cgi'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
      - '/chmod'
      - '/chattr'
      - '/nc'
      - '/netcat'
  condition: selection_parent and selection_child
falsepositives:
  - Rare administrative or application maintenance activity from PHP workers
level: high
---
title: Suspicious PHP Probe or Exploit Payload in HTTP Request
id: c14f16fb-9838-4f1e-a1f7-1d61a10a1c72
status: experimental
description: Detects HTTP requests containing common command execution and code evaluation strings often associated with PHP exploitation attempts.
references:
  - https://www.wiz.io/blog/php2shell-exploitation-so-far
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/02/12
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
  product: linux
detection:
  selection_uri:
    c-uri|contains:
      - 'cmd='
      - 'exec='
      - 'shell_exec('
      - 'system('
      - 'passthru('
      - 'base64_decode('
      - 'eval('
      - 'php://input'
      - '/bin/sh'
      - '/bin/bash'
      - 'wget%20'
      - 'curl%20'
  condition: selection_uri
falsepositives:
  - Security testing, vulnerability scanners, and developer tooling
level: medium
---
title: PHP Worker Writes Executable Content to Web-Accessible Path
id: 0ce1ef64-a7fd-4a43-a746-e4b1c84a12e8
status: experimental
description: Detects PHP or web server processes writing script files into web-accessible directories, a common webshell staging behavior after successful exploitation.
references:
  - https://www.wiz.io/blog/php2shell-exploitation-so-far
  - https://attack.mitre.org/techniques/T1505/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/12
tags:
  - attack.persistence
  - attack.t1505
  - attack.execution
logsource:
  category: file_event
  product: linux
detection:
  selection_process:
    Image|endswith:
      - '/php'
      - '/php-fpm'
      - '/php-cgi'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_path:
    TargetFilename|contains:
      - '/var/www/'
      - '/public_html/'
      - '/htdocs/'
      - '/wp-content/uploads/'
      - '/uploads/'
  selection_ext:
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.phar'
      - '.php5'
      - '.php7'
  condition: selection_process and selection_path and selection_ext
falsepositives:
  - Legitimate deployments or CMS content uploads
level: high

// Hunt for suspicious HTTP probes and possible PHP command-execution payloads ingested through Syslog/CEF/web logs
let timeframe = 14d;
union isfuzzy=true
(Syslog
| where TimeGenerated > ago(timeframe)
| where SyslogMessage has_any ("cmd=", "exec=", "shell_exec(", "system(", "passthru(", "base64_decode(", "eval(", "php://input", "/bin/sh", "/bin/bash")),
(CommonSecurityLog
| where TimeGenerated > ago(timeframe)
| where RequestURL has_any ("cmd=", "exec=", "shell_exec(", "system(", "passthru(", "base64_decode(", "eval(", "php://input", "/bin/sh", "/bin/bash")),
(SecurityEvent
| where TimeGenerated > ago(timeframe)
| where EventID == 4688
| where CommandLine has_any ("php", "php-fpm", "apache", "httpd", "nginx")
   and CommandLine has_any ("bash", "sh", "curl", "wget", "python", "perl", "nc", "base64"))
| project TimeGenerated, SourceComputer, Computer, SyslogMessage, RequestURL, CommandLine, Process, Account

// Defender process hunt for suspicious child processes spawned by web or PHP processes
let timeframe = 7d;
DeviceProcessEvents
| where TimeGenerated > ago(timeframe)
| where InitiatingProcessFileName has_any ("php", "php-fpm", "php-cgi", "apache2", "httpd", "nginx")
| where FileName has_any ("sh", "bash", "dash", "zsh", "curl", "wget", "python", "python3", "perl", "nc", "netcat", "base64", "chmod", "chattr")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName, SHA256, FolderPath

-- Hunt for suspicious child processes spawned by PHP or web server workers
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(php|php-fpm|php-cgi|apache2|httpd|nginx)'
   OR Exe =~ '(php|php-fpm|php-cgi|apache2|httpd|nginx)'

-- Hunt for recently created PHP files in web-accessible locations
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs='/var/www/**/*.php')
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

#!/usr/bin/env bash
# Verify and harden a Linux host running PHP web workloads against common command-execution abuse paths
set -euo pipefail

WEB_ROOTS=("/var/www" "/srv/www" "/usr/share/nginx/html")
PHP_INI_CANDIDATES=("/etc/php" "/etc/php.d" "/etc")
REPORT="/tmp/php2shell_hardening_report.txt"

{
  echo "=== PHP2Shell Hardening Verification ==="
  date -u
  echo

  echo "[+] PHP versions installed"
  if command -v php >/dev/null 2>&1; then
    php -v
  else
    echo "php CLI not found"
  fi
  echo

  echo "[+] Searching for dangerous PHP functions enabled in php.ini files"
  for dir in "${PHP_INI_CANDIDATES[@]}"; do
    if [ -d "$dir" ]; then
      find "$dir" -type f \( -name 'php.ini' -o -name '*.ini' \) -print 2>/dev/null | while read -r ini; do
        echo "--- $ini"
        grep -Ei '^(disable_functions|allow_url_include|allow_url_fopen|expose_php|open_basedir)\s*=' "$ini" || true
      done
    fi
  done
  echo

  echo "[+] Recent suspicious PHP files in web roots"
  for root in "${WEB_ROOTS[@]}"; do
    if [ -d "$root" ]; then
      find "$root" -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) -mtime -14 -printf '%T@ %TY-%Tm-%Td %TH:%TM:%TS %p\n' 2>/dev/null | sort -nr | head -100
    fi
  done
  echo

  echo "[+] World-writable files in web roots"
  for root in "${WEB_ROOTS[@]}"; do
    if [ -d "$root" ]; then
      find "$root" -xdev -type f -perm -0002 -print 2>/dev/null | head -100
    fi
  done
  echo

  echo "[+] Active PHP/web processes"
  ps auxww | egrep 'php-fpm|php-cgi|apache2|httpd|nginx' | grep -v egrep || true
  echo

  echo "[+] Recent shell-like children of web processes"
  ps -eo pid,ppid,user,comm,args --forest | egrep 'php|apache2|httpd|nginx|bash|sh|curl|wget|python|perl|nc' | grep -v egrep || true
  echo

  echo "[+] Listening sockets for web services"
  ss -lntp || true
  echo

  echo "[+] Recommended php.ini hardening values to verify manually"
  echo "disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec"
  echo "allow_url_include = Off"
  echo "allow_url_fopen = Off"
  echo "expose_php = Off"
  echo "open_basedir = /var/www:/tmp"
} | tee "$REPORT"

echo
echo "Report written to $REPORT"

Remediation

Defenders should approach PHP2Shell activity as an immediate exposure-management exercise even if current observed exploitation attempts have not succeeded. The absence of confirmed compromise is an opportunity to harden before a more effective exploit chain appears.

First, inventory every internet-facing PHP asset, including forgotten staging sites, developer portals, CMS instances, file upload handlers, API endpoints, and legacy admin panels. Pay special attention to assets reachable from cloud load balancers, ingress controllers, and content delivery networks. If the application does not need to be public, remove public exposure immediately through VPN-only access, IP allowlisting, private networking, or identity-aware proxy controls.

Second, verify patch status across the entire stack: PHP runtime, web server, framework, CMS core, plugins, themes, and any custom code that handles user input, file upload, templating, or command execution. Because the supplied source does not include a CVE identifier, defenders should follow the official Wiz blog and their application vendors’ advisories for any subsequent disclosure details, exploit notes, and affected-version statements. Where possible, subscribe to vendor security advisories and monitor CISA KEV in case a related CVE is later added.

Third, harden the PHP runtime itself. Disable unnecessary functions that enable direct command execution, including exec, shell_exec, system, passthru, proc_open, popen, and pcntl_exec where application requirements allow. Disable allow_url_include, and where feasible disable allow_url_fopen if remote file retrieval is not required. Use open_basedir restrictions, minimize writable directories, block execution from upload paths, and ensure web workers run as low-privilege users. If workloads are containerized, enforce read-only root filesystems, drop capabilities, and restrict outbound network access.

Fourth, review application architecture for the classes of weakness that make PHP exploitation valuable to attackers. That includes unsafe upload handling, weak MIME and extension validation, user-controlled file paths, template injection, unsafe includes, unauthenticated debug endpoints, and any code path that passes request parameters into command execution or file-writing operations. Application security teams should prioritize hot paths that are externally reachable and historically under-tested.

Fifth, tighten detection and response. Alert on PHP or web workers spawning shell interpreters, download tools, scripting languages, or encoding utilities. Hunt for unexpected PHP files in writable web directories, especially in upload paths. Correlate suspicious requests with outbound connections from web hosts, because a callback attempt may be the first sign that probing has moved into a more serious exploitation stage. If any suspicious artifact is found, preserve web logs, PHP-FPM logs, access logs, container logs, and disk images before remediation.

Finally, rehearse containment. If exploitation is suspected, isolate the host, block outbound traffic, rotate credentials and secrets accessible to the application, and inspect for persistence mechanisms, unauthorized users, modified cron jobs, and unexpected services. Because PHP exploitation often becomes a bridge to broader intrusion activity, responders should assume potential follow-on credential theft, webshell deployment, and lateral movement until evidence proves otherwise.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub