PHP2Shell. Check Exposure. Hunt for Compromise.
A passive domain check for public signs of PHP, clear steps to patch and isolate, and a reactive hunt pack for MSPs who need to find abuse across client estates.
At a Glance
Facts from PHP's advance notice and public advisories. Last updated 21 October 2026, before PHP's 14:00 UTC (15:00 BST) security release.
9.2
CVSS v4.0, both flaws. Rated by the PHP security team.
Two RCEs
CVE-2026-109618 and CVE-2026-109619. Reported as remote code execution.
Patch pending
PHP release scheduled 21 Oct 2026, 14:00 UTC (15:00 BST).
None reported
Not listed in CISA's Known Exploited Vulnerabilities catalogue.
Leak of two PHP RCE flaws. PHP publishes advance notice the same evening.
PHP security release. Affected and fixed versions published with the release. Supported branches only (8.2 to 8.5).
Patch internet facing systems first. Hunt for PHP workers spawning shells. Isolate any end of life PHP you cannot upgrade.
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Tick both tracks.
Shrink exposure
- Inventory every PHP install, including vendor appliances, Windows bundles, cPanel and Plesk.
- Be ready to patch at 14:00 UTC. Internet facing first. Watch your distro and host for backports.
- Isolate end of life PHP (8.1 and older): upgrade, take off the internet, or put behind a VPN or WAF.
- Where you cannot patch, CERT-EU advises considering isolation of internet facing apps until a fix is available.
Hunt and respond
- Alert on php-fpm, php-cgi, httpd or apache2 launching shells, interpreters or download tools.
- Scan web roots for new .php files by mtime. Review access logs for odd POSTs and stalled uploads.
- Check outbound connections from PHP workers, new cron jobs, users and SSH keys.
- If you find something: isolate, preserve web and PHP logs, then look for webshells and persistence.
Check a Domain
Enter a domain you own or manage. We make one normal request to its home page and look for public signs of PHP. Nothing else is sent. Exact versions and raw headers are never shown.
A passive check cannot prove a server is safe. Many servers hide their PHP version, and PHP can run on paths, subdomains or servers this check does not see. Results are a starting point; confirm on the server with the steps below.
Proactive: Check Your Servers
The only reliable answer comes from the server. Work through these on every host that runs PHP.
Check the PHP version
On each server, run:
php -vThe command line can use a different PHP build from the web server, so also check the version your sites run under. On Windows, run php -v from the PHP install folder, and remember PHP can be bundled inside vendor software.
Use phpinfo safely
A phpinfo() page shows the exact version and the Server API (SAPI) the site uses, but it also exposes configuration that helps attackers. Prefer:
php -i | grep -iE "PHP Version|Server API"If you must use a web page, give it a random file name, restrict it to your IP, and delete it straight after.
Check how PHP runs: PHP-FPM, CGI or module
Find which PHP processes and handlers are in use. PHP has not yet said whether a particular way of running PHP is required, so record every SAPI you find.
ps aux | grep -E "php-fpm|php-cgi|httpd|apache2" | grep -v grep
systemctl list-units --type=service | grep -i php
php-fpm -v
apachectl -M 2>/dev/null | grep -i php
grep -Rni "fastcgi_pass" /etc/nginx 2>/dev/nullList installed PHP packages
Distribution packages often backport fixes without changing the upstream version number, so check your distribution's security tracker as well as the version string.
# Debian / Ubuntu
dpkg -l | grep php
# RHEL family
rpm -qa | grep -i php
# Alpine
apk info | grep -i php
# Docker
docker images | grep -i phpCheck hosting control panels
On cPanel, open MultiPHP Manager to see the PHP version set for each domain. On Plesk, check Tools and Settings, then PHP Settings, and each subscription's Hosting Settings. Shared hosting and managed WordPress platforms set PHP per site, so check every site, not just the server default.
Reactive: How to Hunt
Hunt on behaviour: look for the activity that follows successful exploitation of a PHP server. CybaOps can run these hunts across every client estate.
PHP workers spawning shells
Exploitation of PHP RCE flaws usually shows as a web server process starting an unexpected child process. Alert when php-fpm, php-cgi, httpd or apache2 starts a command shell, a scripting interpreter, or a network download utility. Also watch for recon commands run from the web stack.
# Live process tree (Linux)
ps -ef --forest | grep -E "php-fpm|php-cgi|httpd|apache2" | head -80
# Children of PHP workers (example with audit logs)
ausearch -i -sc execve 2>/dev/null | grep -E "php-fpm|php-cgi|apache2|httpd" | grep -Ei "bash|curl|wget|python|perl" | tail -50New .php files in web roots
Look for recently changed PHP files under document roots and upload directories. Review any unexpected file before you delete it.
# Last 48 hours of .php under common roots (adjust paths)
find /var/www /home/*/public_html /usr/share/nginx/html -type f -name "*.php" -mtime -2 -printf "%T+ %p\n" 2>/dev/null | sort
# Review recently changed PHP in upload dirs
find /var/www -type d -iname "*upload*" -o -iname "*tmp*" 2>/dev/null | while read d; do
find "$d" -type f -name "*.php" -mtime -2 -ls 2>/dev/null
doneSuspicious requests in access logs
Watch for unusual multipart POSTs, stalled uploads, odd User-Agents, and bursts of POSTs to the same path. Until PHP publishes the root cause, treat long multipart POSTs with session cookies as worth reviewing.
# Recent POSTs (nginx / apache style)
grep -E ' "POST ' /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null | tail -200
# Multipart or session-cookie heavy traffic
grep -Ei "multipart/form-data|upload_progress|PHPSESSID" /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null | tail -100
# Unusual or empty User-Agents
awk -F\" "$6==\"\" || length($6)<3 {print}" /var/log/nginx/access.log 2>/dev/null | tail -50Outbound from PHP workers
PHP workers should rarely open long lived outbound sockets to the internet.
# Established connections involving PHP workers
ss -tpn | grep -E "php-fpm|php-cgi|apache2|httpd" || true
lsof -nP -iTCP -sTCP:ESTABLISHED 2>/dev/null | grep -E "php-fpm|php-cgi|apache2|httpd" | head -50Persistence: cron, users, SSH keys
# New or odd cron
ls -la /etc/cron.* /var/spool/cron 2>/dev/null
crontab -l 2>/dev/null
# Recent users and authorised keys
getent passwd | awk -F: "$3>=1000 {print}"
find /home /root -name authorized_keys -mtime -7 -ls 2>/dev/nullSigma-style rule (generic)
Generic behavioural rule you can adapt in CybaOps or any Sigma-capable SIEM. Tune parent process names for your estate.
title: Web Server Process Spawns Shell or Download Tool
id: cv-php2shell-web-spawn-shell
status: experimental
description: PHP or web server worker launches a shell, interpreter or download utility.
logsource:
product: linux
category: process_creation
detection:
selection_parent:
ParentImage|endswith:
- /php-fpm
- /php-cgi
- /httpd
- /apache2
selection_child:
Image|endswith:
- /bash
- /curl
- /wget
condition: selection_parent and selection_child
falsepositives:
- Legitimate maintenance scripts invoked from the web stack
level: high
tags:
- attack.execution
- attack.t1059PHP2Shell FAQ
Short answers based on PHP's notice and public advisories as of 21 October 2026.
What is PHP2Shell?
PHP2Shell is the name researchers use for two critical PHP vulnerabilities, reported as CVE-2026-109618 and CVE-2026-109619. PHP rates both 9.2 on CVSS v4.0 and researchers say they allow remote code execution. The name is the researchers', not PHP's.
Which PHP versions are affected?
PHP will publish affected and fixed versions with its release on 21 October 2026 at 14:00 UTC (15:00 BST). Until then, CERT-EU and ASD's ACSC say all versions from PHP 5 onwards may be affected. No configuration or feature requirement has been confirmed by PHP.
Is there a patch?
PHP scheduled an out of cycle security release for 21 October 2026 at 14:00 UTC. Only the supported branches 8.2, 8.3, 8.4 and 8.5 can receive the fix. PHP has published no workaround.
Is PHP2Shell being exploited?
As of 21 October 2026, ASD's ACSC says it is not aware of active exploitation.
What if I run PHP 8.1 or older?
PHP 8.1, 8.0, 7.x and 5.x are end of life and get no PHP fix. Upgrade to a supported branch, or take the system off the internet or put it behind a VPN or web application firewall until you can.
Does a clean result from the checker mean I am safe?
No. The checker only reads what a site shares publicly on its home page. Many servers hide the PHP version, and PHP can still run on other paths, subdomains, admin panels or behind a proxy or CDN. Always confirm on the server itself.
What does the checker send to my site?
One normal web request for the home page, over HTTPS first and then HTTP, the same as a browser visit. It sends no exploit code or attack traffic, and IP addresses and private or internal names are refused.
Detect and Remediate PHP2Shell Across Every Client
CybaOps finds vulnerable PHP across your MSP estate, runs hunts like the Sigma rule above through the SOC, and drives remediation through to a verified fix, so proactive patching and reactive hunting land in one place.