Lessons from PHP2Shell Part 3: The Software You Can’t Touch

Many firewalls, storage devices and business systems contain their own copy of PHP, which only the vendor can update.

This is the final article in the series Lessons from PHP2Shell, which uses the critical PHP flaws disclosed on 21 October 2026 as a case study in how organisations track and patch shared software. Part 1 covered servers and the UK patching timescales, and Part 2 covered containers and developer machines. This part deals with software built into other people’s products, such as firewalls, storage devices and hosted services. Because PHP2Shell sits in PHP itself, it affected the web-based management pages of many such products, and in these cases an organisation may know perfectly well that it is exposed yet be unable to fix the problem until the vendor releases an update.

Why appliances behave differently

An appliance is a device or virtual machine sold as a finished product, such as a firewall, VPN gateway or network storage unit, and most are managed through a web page that is often built with PHP. Appliances differ from servers in three respects. There is usually no way to inspect the software inside, so the organisation relies on the vendor to say which version of PHP is present. Vendors often keep the same PHP version across several years of firmware, which is how a flaw disclosed in 2026 can affect a device bought in 2021. And any fix has to pass through the vendor’s own process of integrating, rebuilding and testing before it reaches customers, a process the customer cannot shorten.

Installing a newer PHP package on the device or running a community script may look like a shortcut, but it is not a supported fix, and NCSC-NL’s advice is to apply the vendor’s own update as soon as it is available.

The extent of the problem

NCSC-NL, the Dutch national cyber security centre, maintains a public list of products with a PHP dependency. By 23 October it held 751 entries, of which 389 were under investigation, 220 were marked as vulnerable and 109 had a fix. Many of the vulnerable entries reflect only the fact that a product uses PHP, so the figures indicate scale rather than a precise count. The table below is a sample of vendor positions reported between 22 and 26 October, and many will have changed since.

Two features stand out. Security products feature prominently, since devices bought to protect the network carried the flaw in their own administration pages. Response times also varied widely, with Synology releasing fixes within days while several other vendors had given no release date a week after disclosure.

Vendor-built containers, hosting and cloud services

Containers built by a vendor behave much like appliances, since the customer can only rebuild once the vendor has published a fixed image. Nextcloud’s All-in-One container and Bref’s images for running PHP on AWS Lambda both embed PHP, and both were awaiting rebuilds in the days after disclosure.

Managed hosting and cloud services take this a step further. Plesk, a widely used hosting control panel, fixed current PHP versions on Linux early in the week while fixes for older versions and Windows were still pending, and the many online services that run on PHP cannot be patched by their customers at all. In these cases the only available step is to ask the supplier, in writing, whether it was affected and when it was fixed.

Compliance when the fix depends on a vendor

Part 1 explained that Cyber Essentials requires high and critical updates, including firewall and router firmware, within 14 days, and that the NCSC recommends shorter targets. For vendor products there is a further gap: the 14 days run from the date the vendor releases its fix, not from public disclosure. An organisation running Cisco Expressway on 25 October could therefore have been fully compliant while its device waited for a patch with no release date.

Other guidance covers this period. The NCSC’s PHP alert advises applying temporary mitigations where an update is not possible and, failing that, considering taking the system offline, while Australia’s Essential Eight asks for “patches, updates or other vendor mitigations” within 48 hours when an exploit exists. The NCSC also states that the organisation must own the risk of not updating, so keeping an unpatched firewall in service while waiting for a vendor should be a recorded decision by someone with authority to accept the risk. Under UK GDPR’s requirement for security appropriate to the risk, waiting for a vendor is defensible, but taking no compensating measures in the meantime may not be.

Keeping an inventory of appliances and services

The inventory methods described in Parts 1 and 2 rely on inspecting the software directly, which is rarely possible here. Instead, the inventory has to be built from records: every device with a web-based management interface, including virtual appliances and equipment in comms rooms and branch offices, together with every hosted service and the supplier responsible for it. Each entry should note the firmware or service version, the support end date and where the vendor publishes security advisories. When a flaw like PHP2Shell is announced, the list can be checked against vendor advisories and the NCSC-NL inventory, bearing in mind that absence from that list does not mean a product is safe, and any vendor that has said nothing can be asked directly.

Managing the risk while waiting for a fix

The most effective single step is usually to remove management interfaces from the internet. In most appliances PHP runs the administration pages rather than the core function of the device, so restricting access to them removes much of the risk, and Palo Alto’s own interim advice was to limit its management interface to trusted internal addresses. Where remote administration is needed, it can be routed through a VPN or a jump host, a single closely controlled machine that administrators connect through. Any interim protections the vendor offers should be applied, and monitoring on affected devices increased, with any device whose management page was reachable from the internet after 17 October treated as possibly probed.

Where none of this is possible, the choice is between taking the device offline and formally accepting the risk, with a named owner and a review date. When the vendor’s fix arrives, it should be applied as urgently as an internal patch, since the exposure has already lasted as long as the vendor took to respond.

Lessons for procurement

An organisation has little influence over a vendor once a device is installed, so the time to address these issues is during procurement. Three requests are worth making. The first is a software bill of materials, or SBOM, listing the components inside the product, which allows the organisation to establish within minutes whether a device contains an affected component. The second is a stated target, in days, between an upstream fix and the vendor’s own release; the NCSC notes that its timescales can be used when drawing up contracts, and its five-day target for internet-facing systems is a reasonable reference. The third is a clear end-of-support date, since a device beyond it will never receive a fix and unsupported software in scope fails Cyber Essentials automatically. PHP2Shell also provides a record of how each existing vendor performed, which is worth noting for the next renewal.

Regulation is also moving in this direction. Since 11 September 2026, the EU Cyber Resilience Act has required manufacturers of products with digital elements to report actively exploited vulnerabilities within 24 hours. Many vendors that sell in the UK also sell in the EU, so customers can expect clearer and earlier disclosure over time.

PHP2Shell will not be the last serious flaw in a widely shared component, and Log4Shell showed the same pattern in 2021. Across this series, the recurring lesson has been that the fix itself is rarely the hardest part. The harder work lies in knowing where affected software is running, patching it quickly, confirming that the patch worked and, for products the organisation cannot patch itself, being clear about who will deliver the fix, how quickly, and how the organisation will know that it has arrived.