Which Security Products and IT Tools Run on PHP?

Yes, many tools your security and IT teams run are PHP applications. MISP, the threat sharing platform, is one, and Passbolt, a password manager, is another. So are GLPI, Zabbix, Cacti and phpMyAdmin. Some products you buy run PHP too, inside their management interface.

That matters because of PHP2Shell, two critical remote code execution vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. A vulnerability in the runtime reaches every application that runs on it, and each application gets its PHP patch by a different route. This post lists the tools and the commercial products, shows who ships the patch, and gives your vulnerability management team a plan.

Twelve Self-Hosted Tools and the PHP Versions They Need

The table covers twelve tools. Each row comes from the project’s own repository or documentation, not from a third-party list. The PHP column shows what the project requires for its current release line, so it changes with each release.

Each row follows the project’s own requirement page. Open it to check the line you run.

• MISP
• Passbolt
• GLPI
• Snipe-IT
• osTicket
• Zabbix frontend
• Cacti
• LibreNMS
• phpMyAdmin
• Nextcloud
• Roundcube
• Matomo

Read the table from right to left. The install route tells you who will patch PHP, which is the next question. Old minimums matter too: GLPI 10 and phpMyAdmin still accept PHP 7.2 to 7.4 lines that have been end of life for years.

We left out any tool whose own documentation did not state its PHP use. This list is a sample. It says these tools run PHP, not that any of them is exploitable. That depends on the PHP build and on what is exposed.

Which Commercial Security Products Run PHP Inside?

The twelve tools above are ones you install yourself. Products you buy can run PHP too, usually in the web interface that manages them. You cannot see that PHP, and you cannot patch it. The vendor ships it inside the firmware or the software image.

The UK NCSC tells organizations to watch for updates from vendors whose appliances may bundle PHP. The Dutch NCSC keeps a public inventory of software with a PHP dependency. It was our starting point. The table keeps only products where a vendor page confirms the status.

The table shows what each vendor said on 24 October 2026. These pages change daily, so open the vendor page before you act. Where a vendor does not say where the PHP sits, the table says so.

The vendor pages behind the rows:

• Palo Alto Networks advisory and our hotfix dates post
• Citrix advisory CTX697263
• Check Point sk1000302 and its IPS protection
• Netgate: critical PHP security update
• OPNsense team announcement and OPNsense frontend docs
• Cisco advisory
• Barracuda advisory
• HPE bulletin HPESBNW05171
• NetApp advisory NTAP-20261021-0021

What Does Check Point sk1000302 Cover?

Check Point sk1000302 is the vendor’s page for PHP2Shell. It lists Force, Spark and Cloud Firewalls as affected on R81.20, R82, R82.10 and R82.20, and Spark on R81.10.x and R82.00.x. The exposed part is the firewall web interface when a remote access or captive portal is on.

A hotfix came out on 23 October and needs a reboot. Until it is installed, the mitigation in sk1000302 blocks multipart requests to the firewall web portals.

Several vendors say their main platforms are clear. Fortinet lists FortiOS, FortiMail, FortiWeb and FortiManager as not impacted, but FortiDDoS and FortiSOAR were still under investigation on 23 October. WatchGuard says its first assessment found no affected product.

SonicWall found no PHP use in SonicOS, SMA 1000, NSM and Email Security, and was still evaluating its switches and SonicWave access points. Cisco lists Secure Firewall ASA, Threat Defense and Management Center as not vulnerable.

Sophos says none of its products are affected. Its advisory adds that a hosted licensing portal for end-of-life SG UTM ran an affected PHP version, and Sophos took it offline on 21 October. Barracuda lists CloudGen Firewall, Email Security Gateway and its web application firewall as not affected.

A “not affected” line is the vendor’s view of these two flaws. It does not promise that the product has no PHP.

F5 covers BIG-IP in article K000163821. An older F5 bug record shows PHP inside BIG-IP TMOS. The Dutch NCSC inventory, citing that article, says F5 confirms exposure in the Configuration utility and in APM and SSLO access profiles, with no fixed release listed yet.

Juniper’s 2024 bulletin shows that J-Web, the web interface of its SRX and EX devices, ships PHP. Juniper has a PHP2Shell status page for its products, so check it for J-Web.

For most products in the table, the action is the same. Limit the management interface to trusted internal addresses, then install the vendor update the day it ships. Palo Alto and Netgate both single out an exposed management interface. Check Point’s affected parts are its remote access and captive portals, so use its mitigation until the hotfix is in.

Who Ships the PHP Patch in Each Setup?

The same flaw sits in the same layer everywhere, but a different party fixes that layer. The diagram shows the stack from top to bottom.

For a tool installed from an archive, such as GLPI, Cacti or osTicket, you run the server, so you patch PHP. Adobe says the same about Adobe Commerce (Magento) on your own servers: its documentation lists security patching for PHP as the customer’s job.

For distribution packages, your distribution ships the fix. For Docker images, the maintainer must rebuild the image, and you must pull it. For appliances, the vendor decides.

On an appliance you cannot patch PHP yourself. In the table above, the fix is always the vendor’s own hotfix or package update. Palo Alto gave estimated hotfix dates in its advisory. We cover them in our Palo Alto status post.

The docs name the install method. The patch route follows from it, so check the route with your own team before you rely on it.

What Should a Vulnerability Management Team Do?

CISA and the UK NCSC both told organizations on 21 October to find every PHP system and patch the internet-facing ones first. The steps below turn that into a routine.

PHP says its workarounds close only some attack paths, so a control buys time but is not a fix. A WAF lowers the risk but does not change the PHP version either. See the PHP2Shell fixed versions post for the exact settings.

PHP 8.1 and older get no new official release, and PHP 8.2 reaches end of life on 31 December 2026. For these lines, ask your distribution or vendor for a backport, or move to a supported branch. A tool that allows an old PHP line can quietly stay on it.

How Does Brandefense Help Find PHP You Did Not List?

The routine above covers hosts you know. The hard part is the host nobody listed. Think of a forgotten test server or a tool a team installed on its own. Think of a firewall management page left open to the internet, or a service a vendor runs for you.

Our External Attack Surface Management (EASM) is built for that gap. It works from the outside, as an attacker would.

EASM runs continuously, unlike a periodic scan, and Brandefense EASM scans internet-facing assets within minutes. It does not replace the host inventory, because tools on internal networks stay out of its view. Use both: inside lists for what you know, outside discovery for what you missed.

For a single site, use the free Atlas PHP vulnerability check. It makes one request to your public homepage, reads the PHP version the server advertises and compares it with the fix. It is passive and sends no exploit traffic. If the server hides its version, the check says so, and a hidden version is not a patched one.

Old PHP is common. In our free check, 445 of 867 vulnerable sites ran PHP 8.1 or older, as of 22 October. The numbers are in our end of life post, and they show why the inventory matters. Start today: list the PHP in your security and IT tools, write the patch route next to each, and run the Atlas check on every public address you own.