'You Can't Patch In Hours What Takes You Days To Find': Why PHP2Shell Is A Challenge For Midmarket IT

Two critical PHP vulnerabilities demand urgent updates, but for lean IT teams, the first challenge may be pinpointing where PHP is running and who is responsible for securing it.

(Image: Getty)

Two recent and critical vulnerabilities in the PHP runtime are forcing organizations to confront a familiar security problem: A patch can only protect the systems an IT team knows exist.

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, dubbed PHP2Shell, can allow an unauthenticated attacker to remotely execute code on affected systems. Both have CVSS v4.0 scores of 9.2. PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on Oct. 21 to address the vulnerabilities.

Unlike vulnerabilities that affect a specific app or plugin, PHP2Shell affects the actual PHP runtime. That means the potential exposure surface extends past the sites and apps that IT may immediately associate with PHP.

And for midmarket organizations with lean IT teams, finding those systems may pose a problem.

"Not knowing where PHP is running is the bigger risk, because it's the reason the patch doesn't happen," Tim Tipton, cybersecurity professional and author of the Tipton on Security newsletter, told MES Computing.

"Almost no midmarket team looks at a known PHP server and decides not to patch it. The server that gets compromised is the one nobody counted."

The PHP Server Nobody Counted

PHP2Shell affects PHP deployments exposed to untrusted web requests. According to Sophos, Apache mod_php deployments face the highest risk, although PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also affected.

Determining where PHP runs within an environment can be deceptively difficult for IT. PHP is often bundled into third-party products not just installed on standalone company web servers. In those cases, vulnerable PHP instances may not be so easy to detect and may not be part of an asset management system.

Vulnerable PHP instances may exist on "the marketing site a contractor built years ago, the control panel on a hosting account, or the management interface on a firewall," Tipton explained.

In fact, major infrastructure vendors have had to assess their own product portfolios for PHP2Shell. F5 identified impact within BIG-IP, while Palo Alto Networks confirmed affected PAN-OS releases and has been rolling out fixes across multiple supported branches.

All of this points to the need for organizations to determine where PHP exists across servers, containers, cloud environments, management UIs and any other systems built or operated by third parties.

Asset Visibility Becomes A Patching Problem

The needed alignment between asset management and vulnerability management becomes more critical when vulnerabilities like PHP2Shell emerge.

Tipton pointed to the speed of the PHP2Shell situation as evidence why.

"With PHP2Shell, attacks started before the fix existed, and the flaw turned up inside network appliances that IT never thought of as web servers," he said. "You can't patch in hours what takes you days to find."

Sophos, citing Amazon Threat Intelligence, reported an exploitation attempt on Oct. 17, four days before PHP published its fixes. Other security providers subsequently reported additional exploitation attempts -- evidence that the defense window has narrowed.

Add time required to hunt down every possible instance of PHP running within the operation, and you have organizations likely to fall behind in defense.

Five Questions IT Leaders Should Ask

Tipton recommends that midmarket IT leaders ask five questions of their teams and technology providers and, importantly, require written answers that are dated.

Inventory: Where is PHP running?

The inventory should identify PHP by host, container and application, including environments run by MSPs, hosting providers and SaaS vendors.

That means the question should not just be: Are our PHP servers patched?

Instead, it becomes: Where does PHP exist anywhere in the environment or in infrastructure operated on our behalf?

Sophos recommends identifying affected systems from runtime evidence rather than relying only on existing asset records, including looking for running php, php-fpm and php-cgi processes.

Version: What exactly is running?

IT teams should establish which PHP version and package exists on each system and determine whether the vendor's security information confirms that the package contains the fix.

Linux distributions and other vendors can backport security fixes without changing the underlying PHP version number in the way an administrator might expect. Sansec, for example, notes that a fixed package for an older PHP branch can retain its PHP version while carrying a new package release.

As Tipton put it: "Version banners can be misleading on backported builds."

Restart: Is the fixed code actually running?

Installing a patched package does not guarantee that every PHP process is using it.

"Has every PHP process restarted since the update?" Tipton advised IT leaders to ask. "A patched package on disk doesn't protect a process still running the old code."

Sansec also advises organizations applying updated packages to restart PHP-FPM or Apache.

Unsupported versions: Who owns legacy systems?

PHP currently provides supported releases beginning with PHP 8.2. Earlier branches are end-of-life under ordinary PHP support. The PHP project has made source patches available for some older releases, and some package maintainers have backported the fixes, but organizations should not mistake that for continued normal support of legacy PHP.

"What's still on PHP 8.1 or older, which gets no official fix, and who owns retiring it?" is what Tipton also advised IT leaders to consider.

Evidence: Did anyone check for compromise?

Finally, patching should not automatically mark the incident closed.

Tipton recommends asking whether anyone investigated for evidence of compromise dating back to Oct. 17, when the first exploitation attempt was observed, instead of looking from the Oct. 21 date forward.

When Your Vendor Owns The Patch

PHP2Shell sheds light on another important issue for the midmarket—technology running inside, or on behalf of, the organization that isn't directly under IT's control.

For example, if PHP is embedded in a firewall, appliance or other vendor product, an administrator should not attempt to replace the underlying PHP runtime unless the vendor specifically instructs customers to do so.

Vendors often provide the security guidance.

Palo Alto Networks, for example, has published affected and unaffected PAN-OS releases and remediation status for its product portfolio. F5 also published its own product-impact statement.

Midmarket organizations often have a veritable soup of partners including managed service providers, hosting providers and other third parties. IT leaders should establish who is tracking a vendor advisory, who is responsible for applying the update and who will verify that the affected system has actually been remediated.

For systems operated by MSPs and other third parties, IT leaders should require the same evidence they would expect from their internal teams. That includes asking about the affected asset, package or product version, the remediation status and date completed, as well as evidence that potential exposure was investigated.

"Written answers with dates," as Tipton recommends, turn "our provider handles that," into something that an IT leader can actually verify.

PHP2Shell Is An Asset Visibility Test

For midmarket leaders, P2PShell exposes an organizational vulnerability along with the software vulnerabilities.

IT teams cannot quickly patch a system they first have to ferret out. They can't validate third-party systems if no one has established patch ownership. And they certainly can't close an incident simply by checking if a patched package exists today if that system may have been exposed before the fix arrived.

The immediate PHP2Shell response is to find vulnerable runtimes and remediate them. But the longer-term lesson is simple: You can't patch what you don't know you have. And in a zero-day threat landscape, the time it takes to find it becomes part of your risk.