Skip to main content
founders-corner

php2shell: Find Vulnerable PHP in Your Environment with ORDR

Two critical flaws in the PHP interpreter itself let unauthenticated attackers run code, and patching is the only fix. Here is how to find every PHP copy in your environment and read versions correctly.

Pandian Gnanaprakasam

November 4, 2026
6 min read

PHP itself is the vulnerability this time

Most PHP security news is about a plugin, a framework or one badly written app. php2shell is different. CVE-2026-109618 and CVE-2026-109619 are flaws in the PHP interpreter, rated critical at CVSS v4.0 9.2, and they let an unauthenticated attacker run code with the web server's privileges.

The details leaked on 20 October, a day before the PHP team shipped fixes. Cloudflare and watchTowr have already reported exploitation attempts. Reports indicate every version from PHP 5 onward is affected, and no configuration change mitigates it. Patching is the only fix.

That puts one question in front of every security team this week: where is PHP running, and which of those copies are still vulnerable?

This post comes with two companion documents. The ORDR php2shell Security Bulletin is a hands-on how-to guide for finding and fixing vulnerable PHP with ORDR AI Protect’s Installed Software inventory. The case study, How a Midwest Health System Mapped Its Exposure to Two Critical PHP Zero-Days with ORDR IQ, shows what that answer looks like when the data is already in place.

Why that question is harder than it looks

PHP rarely announces itself. It sits behind admin consoles, monitoring tools like Zabbix, building-management front ends, vendor appliances and the forgotten internal wiki nobody owns. In connected-device environments, a lot of it was never on the server team's list in the first place.

Even when you find it, the version string can mislead you. Three traps show up again and again:

  • Metapackages. On Ubuntu and Debian, a package named php with a version like 1:7.2+60ubuntu1 only points at the default branch. It says nothing about whether PHP is patched.
  • Backports. Ubuntu and Debian ship security fixes without changing the upstream number. 7.2.24-0ubuntu0.18.04.17 can be patched or vulnerable; the distro revision decides, not the 7.2.24.
  • Name matches. A search for “php” also returns things like python3-phply, a Python library that parses PHP code. It is not PHP and is not at risk.

Read a version wrong in one direction and you close a finding that is still exploitable. Read it wrong in the other and you burn a change window on a host that was already fixed.

Where the versions come from: ORDR Software Inventory Collector (OSIC)

The PHP versions in Installed Software come from the ORDR Software Inventory Collector, OSIC. It reports every installed package and its exact version string, including the distro revision you need to judge a backport.

OSIC is a lightweight, OS-driven script, not a traditional agent. It runs with read-only permissions, sends device details to your ORDR instance, and doesn't consume device CPU or affect operations. Scripts are available for Windows and Linux/macOS, and you can deploy them from ORDR AI Protect or from a sensor.

That matters for php2shell in three ways:

  • Exact versions, not guesses. OSIC reports strings like 7.2.24-0ubuntu0.18.04.17, so you can compare the whole build against your distro's fixed version.
  • Devices scanners can't touch. Many IoT, IoMT and OT systems run Windows or Linux but can't tolerate an active scan. OSIC inventories their software without one.
  • Instant answers for the next zero-day. Because the inventory is already collected, a new CVE becomes a search, not a scanning project. In the bulletin's screenshots, OSIC is the integration source behind each PHP finding. The accompanying case study shows the payoff: a Midwest health system that already had OSIC data flowing asked ORDR IQ about its exposure and got back 21 affected devices, 5 high-risk, across 2 sites, on day one.

If a device you expect to see is missing from Installed Software, deploying OSIC to it is usually the fastest way to close the gap. See the OSIC datasheet (opens in a new tab) for supported platforms.

What the how-to bulletin walks you through

The ORDR php2shell Security Bulletin is a step-by-step how-to guide for ORDR AI Protect customers, with screenshots for each step. It uses the Installed Software inventory to go from “do we have PHP?” to a routed, prioritized fix list:

  1. Find every PHP package. Search Installed Software for “php” and review the full result, including the versioned runtimes and web-server modules further down the list. (Bulletin, p. 3)
  2. See which devices have it. Open the device list for each package, export it for tracking, and check the Last Update column for stale inventory. (Bulletin, pp. 4–5)
  3. Read the version correctly. A package-pattern table tells you which results carry the real PHP version, which ones serve web requests, and which ones to ignore. (Bulletin, pp. 6–7)
  4. Decide whether it is fixed. A fixed-version table by source covers php.net builds, Ubuntu, Debian, RHEL-family distros, end-of-life PHP and vendor appliances. (Bulletin, pp. 8–9)
  5. Confirm on the host. One-line changelog checks for Debian/Ubuntu and RHEL settle the backport cases the version alone can't. (Bulletin, p. 9)

Because each device record carries its business context and network location, you also see who owns the fix and whether the host is reachable from the internet, guest or partner networks.

If you use ORDR IQ, you can also ask the question in plain language, for example “Which devices run PHP, and which versions?” The case study shows how one health system turned that question into a ready-to-share executive brief for leadership, complete with risk charts and a prioritized list of the riskiest devices.

What to do this week

Treat every unpatched PHP version as vulnerable, and work in this order (the bulletin’s “Prioritize and act” page, p. 10, has the full checklist):

  • Patch exposed web servers first. Devices with mod_php, PHP-FPM or php-cgi that are reachable from the internet, guest or partner networks go to the top of the list.
  • Contain what you can't patch. End-of-life PHP (8.1 and older has no upstream fix) and appliances waiting on a vendor update should come off the internet and be segmented so only known admin hosts reach their web interface.
  • Look for compromise. Patching doesn't evict an attacker who got in first. On exposed hosts, look for shells spawned by PHP workers, new files in web roots, new cron jobs or accounts, and unusual outbound connections going back to at least June 2026.

One honest caveat: inventory only shows what your data sources report. Many embedded and IoT devices run PHP in their web interface without reporting any installed software, and PHP bundled inside an application folder or container image may not appear as a package. For those, check vendor advisories and fingerprint web interfaces on the network. The bulletin covers this too.

Companion documents

Download the ORDR_php2shell_HowTo_Bulletin (opens in a new tab): the how-to guide for finding PHP in Installed Software, reading versions correctly and deciding what to patch. Published 22 October 2026.

PHP_Zero_Day_ORDR_IQ_Case_Study: How a Midwest Health System Mapped Its Exposure to Two Critical PHP Zero-Days with ORDR IQ. How one health system scoped its php2shell exposure on day one, and why connecting software inventory made it possible.

Fixed versions are still moving as distributions publish updates, so confirm against your vendor's advisory before closing a finding. If you want help running the search across your environment, reach out to your ORDR team.

Found this useful? Share it.