Skip to main content
On 21 October 2026 the PHP project released emergency fixes for two critical vulnerabilities, known as PHP2Shell: CVE-2026-109618 and 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.

​
Are you affected?

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

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?
In Devices, 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.
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

Software inventory gives you a rough picture of where PHP is installed, which helps you decide what to look at first.
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). 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:
To catch all of them:
*Php* also matches developer tools such as PhpStorm; ignore devices that only have those. In Software Inventory, search for php and each stack name, and expand a product to see each version and its device count.
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:
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 flow that tags your DMZ ranges, or an external attack surface tool, closes some of that gap.

​
Track the fix

  1. Run a query from step 1 or step 2 and click Track View. Choose Snapshot and set a Deadline. See Tracked Views.
  2. In Action Center, 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 and send a daily Scheduled Report 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: To see which applies, open the server in Devices, 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, 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.
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