cybersecurity

PHP2Shell: what to do now, and how to find it with Tenable

22/10/2026 · 6 min read · Owen Robbins, Summit Cyber Group

Current as at 22/10/2026. We will update this page as vendor guidance changes.

Two critical vulnerabilities in PHP, known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2), were disclosed on 21/10/2026. They are in the PHP engine itself, not in any particular application, so a well-built website is still exposed if the PHP underneath is not patched.

This page pulls together what Tenable, Wiz, Check Point and CISA are advising, in the order we would work through it. If you run Tenable, there is a section below on finding every affected system, including a Hexa AI prompt Tenable has shared.

What it is

  • The risk: a crafted multipart (file upload) request pushes PHP into an out-of-memory error that leaves its internal state corrupted. Follow-on requests can use that to run code on the web server, or to read worker memory containing credentials, keys and session tokens. No login is needed.
  • What is affected: essentially every PHP version since 5.4, including PHP-FPM. That covers WordPress, Drupal, Joomla, Magento and WooCommerce sites, and any custom PHP application.
  • Status: details leaked before the patch was released. Cloudflare and watchTowr are reporting early attacks and exploitation attempts. At the time of writing it is not on CISA’s Known Exploited Vulnerabilities list.

Fixed versions

PHP released fixes on 21/10/2026.

Running Upgrade to
PHP 8.5.x 8.5.12
PHP 8.4.x 8.4.27
PHP 8.3.x 8.3.36
PHP 8.2.x 8.2.35
PHP 7.4 to 8.1 No official fix (unofficial source backports only). Upgrade, or isolate
PHP 5.4 to 7.3 No fix (end of life). Upgrade, or take offline

What to do, in order

  1. Find where PHP runs, internet-facing systems first. Include sites hosted by third parties and web agencies, and ask those providers in writing for their PHP version and patch date.
  2. Patch to the versions above, internet-facing first. Restart PHP-FPM, Apache or IIS afterwards so the fix takes effect, and rebuild and redeploy any container base images.
  3. If you cannot patch straight away, apply Tenable’s interim settings (below).
  4. Put a web application firewall in front and turn on your vendor’s PHP2Shell rules in prevent mode.
  5. Take unsupported PHP (8.1 or earlier) offline, or isolate it, until it is upgraded. This is CISA’s advice.
  6. Restrict outbound traffic from web servers, so a compromised server cannot download tools or call home.
  7. Monitor for the signals listed below.
  8. Re-scan to confirm, and get written confirmation from third-party providers.

Finding it with Tenable

Tenable has published an FAQ on php2shell and released detection coverage.

  • Nessus plugin 369483, PHP < 8.2.35 / 8.3.x < 8.3.36 / 8.4.x < 8.4.27 / 8.5.x < 8.5.12 Multiple Vulnerabilities (Critical). Make sure your scanners have pulled the latest plugin set, then scan web-facing assets first.
  • It is a remote check based on the PHP version the server reports. Servers that hide their version (headers removed, or behind a reverse proxy or CDN) can be missed. Pair it with a credentialed scan and the local inventory plugins: 216936 (PHP installed, Unix), 200476 (PHP installed, Windows), 48243 (PHP version detection) and 58987 (unsupported PHP).
  • Web App Scanning: plugins 115719 to 115722 cover PHP 8.5, 8.4, 8.3 and 8.2.
  • Tenable One and Vulnerability Management: Explore → Software, filter Product is equal to PHP, and compare versions against the table above.
  • Attack Surface Management: search Programming Languages contains PHP to find internet-facing PHP you may not know about.

A Hexa AI prompt for Tenable One

If you have Tenable One with Hexa AI, paste this prompt into Hexa. It lists every asset seen in the last 14 days running a vulnerable PHP version, one row per instance, including systems where the CVE-specific plugin has not fired yet. That covers the gap in the remote check.

Query Tenable Exposure Management for ALL assets running a PHP version vulnerable to CVE-2026-109618 or CVE-2026-109619 (php2shell) that have been observed within the last 14 days.
Consider the following PHP versions vulnerable:

PHP 5.x
PHP 6.x
PHP 7.x
PHP 8.0.x
PHP 8.1.x
PHP 8.2.x versions earlier than 8.2.35
PHP 8.3.x versions earlier than 8.3.36
PHP 8.4.x versions earlier than 8.4.27
PHP 8.5.x versions earlier than 8.5.12
Exclude:

PHP 8.2.35 and later within the 8.2 branch
PHP 8.3.36 and later within the 8.3 branch
PHP 8.4.27 and later within the 8.4 branch
PHP 8.5.12 and later within the 8.5 branch
FILTER:

Asset Last Seen >= current date minus 14 days
Detected/running PHP version matches one of the vulnerable versions above
RETURN ONE ROW PER VULNERABLE INSTANCE WITH:

DNS Name / FQDN
IP Address
Asset Last Seen
Detected/Running PHP Version
Tenable Plugin ID
Plugin Name
Plugin Output
CVE, if associated with the finding
Recommended/Fixed PHP Version
REQUIREMENTS:

Return ALL matching vulnerable PHP installations, not a sample or summary.
Include vulnerable PHP installations even if the specific CVE has not yet been directly detected by a CVE-specific Tenable plugin, provided the detected PHP version falls within the vulnerable version ranges above.
Do not aggregate multiple assets.
Preserve separate findings for each asset.
Preserve Plugin Output exactly as recorded by Tenable.
If multiple Tenable plugins identify PHP on the same asset, include the evidence necessary to determine the actual installed/running PHP version.
If a requested field is unavailable, return "Not Available".
Sort by PHP version, then DNS Name, then IP Address.

Finding it without a scanner

From the outside, check each public site for PHP:

curl -sI https://site.example | grep -iE 'x-powered-by: php|set-cookie: phpsessid'

On servers you manage:

# Linux
ps aux | grep -E 'php-fpm|php-cgi|httpd|apache2'
php -v
dpkg -l | grep -i php        # Debian / Ubuntu
rpm -qa | grep -i php        # RHEL / Rocky / Amazon Linux

On Windows, run where php and check IIS FastCGI handler mappings for php-cgi.exe. For containers, check image registries for PHP base images, not just what is currently running.

Interim settings if you cannot patch yet

These are Tenable’s recommended workarounds. They reduce risk; they do not replace the patch.

memory_limit = -1                      ; CVE-2026-109618. Use container or cgroup limits as the boundary
session.upload_progress.enabled = 0    ; CVE-2026-109619
fatal_error_backtraces = 0             ; PHP 8.5 only

Check Point customers: set IPS protection CPAI-2026-15172 (PHP Remote Code Execution) to Prevent, and make sure gateways are pulling IPS updates automatically. CPAI-2021-0286 (PHP Webshell Upload Over HTTP) adds coverage for follow-on activity.

What to monitor

  • Multipart (upload) requests followed by memory-limit errors or bursts of HTTP 500 responses
  • Unexpectedly large or malformed PHPSESSID cookies in responses
  • Unexplained PHP worker crashes or restarts
  • PHP or web server processes (php-fpm, php-cgi, w3wp) starting a shell or downloading tools

If you see signs of compromise, isolate the server, rotate any credentials, keys and secrets it held, and rebuild it from a known-good image rather than cleaning it.

Need a hand?

If you would like help working out where you are exposed, running or checking Tenable scans, or turning the monitoring signals above into detections in your SIEM, get in touch.

Sources

Have a question this raises for your own environment?

We would rather tell you it is not a problem than sell you something you do not need.