PHP2Shell is a pair of critical flaws in PHP that allow unauthenticated remote code execution (RCE) on a server running a vulnerable build. It was disclosed on October 21, 2026, and CISA added both flaws to its Known Exploited Vulnerabilities (KEV) catalog on October 26, which means they are being exploited in the wild. Most organizations are watching this flaw in general IT. The blind spot is clinical systems and IoT in healthcare, where PHP sits inside many of the web interfaces hospitals depend on, from clinical systems to building systems and telephony.
What PHP2Shell is
PHP2Shell covers CVE-2026-109618 and CVE-2026-109619, two memory-safety flaws in PHP core. Exploited over the network without credentials, they allow RCE or disclosure of process memory. Both score 9.2 under CVSS v4.0 (9.8 and 8.1 under v3.1). Both are in CISA's KEV catalog, so exploitation is already happening, and their EPSS score above 99.9% means it is close to certain to continue over the next 30 days. The fix is a patched PHP release (8.2.35, 8.3.36, 8.4.27 or 8.5.12 and later). PHP 8.1 and earlier are end of life. Because PHP is usually compiled into a product or shipped as one of its dependencies, the patch has to come from the product vendor, not from the system administrator.
Bedside medical devices are largely unaffected; the systems around them are not
Most bedside and point-of-care devices run purpose-built or embedded software that does not include PHP. Several manufacturers that have published assessments say the same: their patient-facing devices do not use it, and the exposure is limited to a smaller set of products. That is reassuring, but it is easy to over-read. A device that is not affected does not mean the clinical workflow around it is safe.
Where the exposure is: management servers with web interfaces
Here, clinical systems means the servers and web consoles behind imaging, pharmacy, drug-library and device-management workflows, and IoT means building automation, cameras, access control and telephony. Where PHP appears, it is usually inside a web interface. Systems that centrally manage devices, store images, run pharmacy or drug-library workflows, or connect clinical systems often have a browser-based console, and some of those consoles are built on PHP. These servers tend to be on-premise, reachable from many parts of the network, and run by a mix of hospital IT and the vendor. An RCE here can change configuration, expose patient data or disrupt the workflow that depends on the server, even when the devices it manages are untouched.
OT and telephony are in scope too
The same flaw shows up outside clinical systems. Building automation controllers and their web front ends, IP cameras, access control platforms and the management software for each of them appear in vendor notices. So do telephony and unified communications platforms, which hospitals rely on for day-to-day communication. These systems are often owned by facilities or telecom teams and sit outside the clinical engineering process, so a review that only covers medical devices will miss them. Patches have been released for many of these products, and fixes for others are still pending.
Why it is hard to answer quickly
The fix for PHP is a patched release. Products that bundle PHP need their vendor to ship that fix. Where the vendor hosts the product as SaaS, the fix is applied centrally, and these solutions have generally been patched quickly. Many manufacturers have said their assessments are still under way, and several share product-level details only with customers. Some advise against updating PHP independently, because that can break a validated configuration. Hospitals end up waiting for vendor statements while the flaw is being exploited. Statements are also being revised as assessments finish, so an early answer for a product may change. For on-premise products the wait can be long: we have seen a vendor give a patch ETA of Q1 2027, so hospitals will need to consider compensating controls in the meantime.
What we are doing
We are monitoring PHP2Shell and providing intelligence to our customers as vendors publish and update their assessments. Our Cylera platform is identifying impacted devices by manufacturer and model, so teams can see which systems are affected and prioritize them as vendor guidance arrives. This is a developing situation, and we will keep our guidance current as vendors assess their products.
What to do now
- Find the systems that have a web administration interface, including servers that manage clinical devices, building systems and phone systems. Note which are reachable from outside their own network segment.
- Ask each vendor whether the product bundles PHP, and which version, and get the answer in writing. A public notice that names no products is not an answer.
- Apply vendor patches and mitigations as they arrive. Do not update PHP yourself on vendor-managed systems unless the vendor says to.
- Put compensating controls in place in the meantime: remove internet access to admin interfaces, restrict them to a management network or an allow list, and keep these servers off the general user network.
- Watch for signs of exploitation: a web server process starting a shell, unexpected new files in web directories, and outbound connections from management servers.
The wider point
PHP2Shell is a reminder that risk in a connected hospital sits in software that ships inside many products, not only in the products themselves. A device-by-device review misses a flaw in a shared component. General IT teams usually have tooling to find and patch a flaw like this. Clinical systems and healthcare IoT usually do not, which is why they are the blind spot. Knowing which servers, controllers and phone systems exist, what they run and who manages them is what shortens the time between a disclosure like this one and a clear answer.
See where your hospital stands
Cylera runs a free 30-day evaluation at one hospital site. Your team sees the connected devices on that site's network, including the clinical systems, building systems and phone systems, matched by manufacturer and model against published vendor advisories such as those for PHP2Shell. Request your free 30-day evaluation.
