> ## Documentation Index > Fetch the complete documentation index at: https://docs.threataware.com/llms.txt > Use this file to discover all available pages before exploring further. # PHP2Shell: find affected devices > Find the servers and workstations your vulnerability scanner is missing, spot likely PHP installs, and track the fix for CVE-2026-109618 and CVE-2026-109619 Available on Each plan helps in a different way. See What ThreatAware can do on your plan, below. On 21 October 2026 the PHP project released emergency fixes for two critical vulnerabilities, known as **PHP2Shell**: [**CVE-2026-109618**](https://nvd.nist.gov/vuln/detail/CVE-2026-109618) and [**CVE-2026-109619**](https://nvd.nist.gov/vuln/detail/CVE-2026-109619). The PHP project rates both as critical (CVSS 4.0 score 9.2). Both let an unauthenticated attacker run code on a server through the PHP runtime itself, so keeping your application up to date doesn't protect you. Attackers started trying to exploit them on the day of release. **Your vulnerability scanner is the best way to find vulnerable PHP.** ThreatAware helps most by showing the servers and workstations that scanner isn't covering, where a vulnerable PHP install could go unnoticed. | At a glance | | | - | - | | **Disclosed** | 21 October 2026 | | **Severity** | Critical (CVSS 4.0 score 9.2) | | **Affects** | PHP installs that serve web requests, on any OS | | **Exploited** | Yes, attempts started on the day of release | | **Fix** | Upgrade PHP to a fixed release | ## Are you affected? | PHP branch | Fixed in | | - | - | | 8.5 | 8.5.12 | | 8.4 | 8.4.27 | | 8.3 | 8.3.36 | | 8.2 | 8.2.35 | | 8.1 and older | No official release. End of life, so treat as vulnerable unless your OS vendor says otherwise. | Any version below the fixed release for its branch is vulnerable: 8.2.34 is vulnerable, 8.2.35 is fixed. The PHP project lists every installation that serves web requests as affected, including PHP-FPM, Apache mod\_php and php-cgi. Then check your scanner for findings on CVE-2026-109618 and CVE-2026-109619: * **A finding for either CVE:** vulnerable. * **Recent credentialed scan, no finding:** likely fixed. * **No recent credentialed scan:** unknown. Treat it as vulnerable until it's scanned. A scan from before 21 October 2026 can't confirm the fix. ## What ThreatAware can do on your plan | Plan | What you can do | | - | - | | **Connect** | Find servers and workstations your vulnerability scanner doesn't know about. | | **Discover** | Also find scanner agents that have silently stopped working or are misconfigured. | | **Protect** | Also use software inventory to spot likely PHP installs, prioritise the ones with scanner gaps, and drive alerts and tickets. | By vulnerability scanner we mean any tool that reports vulnerabilities on your devices, such as Microsoft Defender Vulnerability Management, Qualys, Tenable or Rapid7. ## Find affected devices ### 1. Find the gaps in your scanner's coverage The question to answer is: how many of your servers and workstations aren't in your scanner at all, or are in it but not being scanned properly? **Connect** In [Devices](https://docs.threataware.com/device-management.md), the integration columns show which tools know about each device. A server or workstation with no tick under your scanner isn't being scanned. Save it as a view so you can come back to it, or [export it](https://docs.threataware.com/device-management.md). **Discover** [Vitals](https://docs.threataware.com/vitals-configuration.md) tell you whether the scanner is deployed, working and configured correctly on every device that needs it. Make sure your scanner is required on your servers and workstations (its **Scope**), then search for each problem. For example, with Microsoft Defender as your scanner: | Find devices where the scanner is | Query | | - | - | | Not deployed | `system.microsoft_defender_atp.required:true AND system.microsoft_defender_atp.deployed:false` | | Deployed but not working | `system.microsoft_defender_atp.deployed:true AND system.microsoft_defender_atp.functioning:false` | | Misconfigured | `system.microsoft_defender_atp.functioning:true AND system.microsoft_defender_atp.configuredCorrectly:false` | Swap in your scanner: type `system.` in the query bar and autocomplete lists your integrations. Some network scanners report **Detected** and **Not Detected Recently** instead, so look for devices they haven't detected recently. See [Vitals states](https://docs.threataware.com/reference/vitals-states.md). **Protect** Everything in Discover, plus add a [Custom Vital](https://docs.threataware.com/vitals-configuration.md#custom-vitals) for any check your scanner's built-in Vitals don't cover, and use Tracked Views and Action Center to [alert and raise tickets](#track-the-fix) for every gap. > [!WARNING] > > **Qualys: check that agents are collecting vulnerability data.** If you run out of Qualys licences, you can still deploy agents, but they don't collect any vulnerability data. Qualys doesn't alert you when this happens. So make sure a Vital checks that the vulnerability management module (VMDR) is enabled on every agent. If your Qualys Vitals don't include one, add it as a Custom Vital (Protect). ### 2. Spot likely PHP installs with software inventory Available on Software Inventory is on Protect. Software inventory gives you a rough picture of where PHP is installed, which helps you decide what to look at first. > [!NOTE] > > **Treat it as a guide, not a vulnerability check.** A software query only matches where a connected tool lists PHP as installed software, so many installs never appear (see [Blind spots](#blind-spots)). Software data refreshes about every two days, so a device patched yesterday can still show the old version. The query bar is case sensitive, so the queries below check `php`, `Php` and `PHP`. Confirm with your scanner or the server's owner before you tell anyone it's vulnerable. The most useful query combines it with your scanner gaps from step 1. A device with PHP **and** no working scanner is where a vulnerable install is most likely to go unnoticed: ```text theme={null} (software:{product:*php*} OR software:{product:*Php*} OR software:{product:*PHP*}) AND (system.microsoft_defender_atp.deployed:false OR system.microsoft_defender_atp.functioning:false) ``` > **Names PHP is reported under** > > | Where it comes from | Names to look for | > | - | - | > | PHP itself | `php`, `php-cli`, `php-common`, `php*-fpm`, `php*-cgi` | > | Apache module | `libapache2-mod-php*`, `apache2-mod_php*` | > | Hosting panels and web servers | `ea-phpXX-*` (cPanel), `plesk-phpXX-*` (Plesk), `lsphpXX` (LiteSpeed), `frankenphp` | > | Bundled stacks | XAMPP, WampServer, Laragon, MAMP, Herd. The stack's version isn't the PHP version inside it. | > > To catch all of them: > > ```text theme={null} > software:{product:*php*} OR software:{product:*Php*} OR software:{product:*PHP*} OR software:{product:*XAMPP*} OR software:{product:*Wamp*} OR software:{product:*Laragon*} OR software:{product:*MAMP*} OR software:{product:*Herd*} > ``` > > `*Php*` also matches developer tools such as **PhpStorm**; ignore devices that only have those. In [Software Inventory](https://docs.threataware.com/software-inventory.md), search for `php` and each stack name, and expand a product to see each version and its device count. > **Checking versions** > > The version shown is reliable for end-of-life branches and for php.net builds, which most Windows installs use. It isn't reliable for **Linux distribution packages**: distributions backport fixes without changing the version number, so a fixed package can still report something like 8.2.20. > > The query language matches with wildcards only, so it can't ask for "version below 8.4.27". To list devices with PHP that aren't on a fixed release: > > ```text theme={null} > (software:{product:*php*} OR software:{product:*Php*} OR software:{product:*PHP*}) AND NOT software:{product:*php* AND version:8.2.35*} AND NOT software:{product:*Php* AND version:8.2.35*} AND NOT software:{product:*PHP* AND version:8.2.35*} AND NOT software:{product:*php* AND version:8.3.36*} AND NOT software:{product:*Php* AND version:8.3.36*} AND NOT software:{product:*PHP* AND version:8.3.36*} AND NOT software:{product:*php* AND version:8.4.27*} AND NOT software:{product:*Php* AND version:8.4.27*} AND NOT software:{product:*PHP* AND version:8.4.27*} AND NOT software:{product:*php* AND version:8.5.12*} AND NOT software:{product:*Php* AND version:8.5.12*} AND NOT software:{product:*PHP* AND version:8.5.12*} > ``` > > If PHP 8.5.13, 8.4.28 or later comes out, add it to the query. Internet-facing hosts can help you decide what to fix first, but not what's in scope. Public IP addresses from your cloud platforms show instances exposed directly, but miss hosts behind load balancers, NAT, CDNs and DMZ port forwarding. A [Logic Engine](https://docs.threataware.com/logic-engine.md) flow that tags your DMZ ranges, or an external attack surface tool, closes some of that gap. ## Track the fix Available on Tracked Views and Action Center are on Protect. 1. Run a query from step 1 or step 2 and click **Track View**. Choose **Snapshot** and set a **Deadline**. See [Tracked Views](https://docs.threataware.com/tracked-views.md). 2. In [Action Center](https://docs.threataware.com/automation.md), build a flow triggered by that tracked view to email the device owners, or open tickets in ServiceNow or another tool with an **HTTP request** step. 3. [Save the query as a view](https://docs.threataware.com/device-management.md#saving-a-view) and send a daily [Scheduled Report](https://docs.threataware.com/scheduled-reports.md) of it to your security lead until it's empty. Scanner gaps (step 1) make the most reliable tracked views, because Vitals refresh with your integrations. Views built on software inventory (step 2) lag by up to two days. There's no ready-made view, because the right one depends on your integrations, tags and Logic Engine flows; your Customer Success Manager can help you build one. ## Blind spots Expect a lot of PHP that ThreatAware can't see, including on servers it knows about. If another tool shows PHP on a server that the queries above don't match, it's usually one of these: | Reason | When ThreatAware can see the PHP | | - | - | | None of the server's tools report installed software | Never. ThreatAware knows the server from your directory, CMDB, cloud platform or network tools, but has no software list to search. | | PHP isn't registered with the OS: a source build, a zip extract, Homebrew, or bundled inside another application | Only if a vulnerability scanner detects it from files on disk | | Appliances, NAS devices, firewalls and management consoles | Only if a vulnerability scanner or network discovery tool detects them | | Docker containers and container images | Only if a container or image scanning tool is connected | | Shared and managed hosting | Hosting panel servers you own are visible. Sites on third-party platforms are outside your estate. | | The tool that found PHP isn't connected to ThreatAware, or doesn't report installed software to it | Never | To see which applies, open the server in [Devices](https://docs.threataware.com/device-management.md), check which tools report on it under **Vitals**, then click **Details** and **Software** to see the software list ThreatAware has for it. For anything ThreatAware can't see, use your [scanner's findings](#are-you-affected), ask the teams that run it, or check the vendor's advisories for appliances. ThreatAware can't apply the temporary mitigations or check for signs of compromise. Those belong to your EDR and incident response teams. > [!WARNING] > > **An empty list doesn't mean you're done.** Before you close this off: > > * Check the blind spots above by hand. > * Confirm each patched server restarted Apache, PHP-FPM and any long-running PHP workers. They keep running the old code until they do. > * If you're moving devices onto PHP 8.2, go to 8.2.35 at least and plan the next upgrade. PHP 8.2 reaches end of life on 31 December 2026. ## Sources * NVD: [CVE-2026-109618](https://nvd.nist.gov/vuln/detail/CVE-2026-109618) (out-of-memory handling) and [CVE-2026-109619](https://nvd.nist.gov/vuln/detail/CVE-2026-109619) (stale request state), both leading to remote code execution * Coverage: [Help Net Security](https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/), [The Hacker News](https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html), [Huntress](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.