PHP2Shell is two critical vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, disclosed by the PHP project on October 21, 2026 and rated 9.2 on CVSS v4.0 by its security team. Both allow unauthenticated remote code execution. Because the flaws live in the interpreter rather than in any one application, every application on a vulnerable version inherits them, however carefully that application was written.
Every PHP installation that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Under mod_php an unauthenticated request can trigger exploitation before any application code runs, so a login page is no protection. Exploitation attempts were recorded four days before disclosure, and working public exploits followed within days.
PHP ships inside medical products more often than their SBOMs admit: device-embedded configuration and service interfaces, gateways and middleware, fleet dashboards and central stations, vendor appliances, and the cloud backends behind connected devices. A device whose embedded web server runs PHP, reachable on a hospital network, is remotely exploitable without credentials. Fielded firmware carries whatever PHP version it was built with, and PHP 7.3 and older get no fix from the project. ELTON rates this Critical for any product that serves web requests through an unpatched PHP.
The PHP project describes the two flaws this way:
Four separate bugs sit behind the two identifiers. The triggers are conditions an attacker controls from outside: request size against memory_limit and post_max_size, the session upload-progress feature, and fatal errors or timeouts the attacker can provoke. None of them needs an account.
Fixed releases, published October 21, 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The project published minimal source backports for 7.4, 8.0 and 8.1, which are out of support, for teams that build from source or have no LTS vendor. PHP 7.3 and older receive nothing from the project; a product on those versions is fixed only by upgrading the interpreter or by a vendor backport. Linux distributions and LTS vendors have shipped backported packages for the branches they support.
The vulnerable code had been in the interpreter for well over a decade. More than one research team reached the bugs independently in August 2026 using frontier AI models. The first report went to PHP on August 24 and was acknowledged on September 21. Details leaked on October 20, a day before the planned release, and the first exploitation attempt was recorded by Amazon's honeypots on October 17, while the flaws were still under embargo.
A product is affected when both of these hold:
Where it hides in a medical product:
| Component | Typical PHP use | Who can reach it |
|---|---|---|
| Device-embedded web interface | Configuration, service and diagnostics pages served by lighttpd or Apache with php-cgi or mod_php | Anyone on the device's network segment |
| Gateway or middleware | Protocol bridging, local dashboards | The clinical network |
| Fleet or central-station software | Web dashboards for biomedical engineering | Hospital IT network, sometimes a VPN |
| Vendor appliance or server image | Management consoles the vendor maintains, not the hospital | Hospital IT network |
| Cloud backend and companion portals | Customer portals, device registration, telemetry APIs | The internet |
Network appliance vendors have already confirmed embedded exposure. Palo Alto Networks reports all PAN-OS and Panorama versions affected, and Cisco rates Expressway Critical with a fixed release. A medical device that embeds PHP is in the same position, with a slower patch cycle.
Not affected: a product that uses PHP only from the command line with no web-serving SAPI, a product on a fixed release, and a product with no PHP in its SBOM. Confirm the last one. PHP arrives inside vendor images and third-party components without anyone choosing it.
Unauthenticated, remote, low complexity. The attacker sends crafted requests to the PHP endpoint. No credentials, no user interaction and no prior access are required. Under mod_php the vulnerable path runs before the application's own code, so authentication in the application is irrelevant. Working exploits are public, and exploitation has been observed in the wild since October 17.
What it yields: code execution as the web server user on the host. On a device, that is the device itself: its configuration, its stored data, the service functions behind the web interface, and a foothold on the clinical network. On a fleet server, it is every device that reports to it.
Exploitability on a specific product still depends on the build: the SAPI, the memory and request limits in effect, and whether the vulnerable paths are reachable through the interface as shipped. That is a test, not a version check.
Section 524B asks for a plan to monitor, identify and address postmarket vulnerabilities, and for patches as soon as possible, out of cycle, for critical vulnerabilities that could cause uncontrolled risks. A publicly exploited, unauthenticated remote code execution in a component of the device meets that description wherever the interface is reachable.
PHP is an SBOM component. A submission in review that ships an affected version will be asked for its assessment and its plan. A submission that ships a version the project no longer fixes will be asked how the manufacturer intends to keep it patched. Fix it before sending it in.
Postmarket, the plan needs the exposure assessment per product: which products ship PHP, which SAPI and version, where the interface listens, the test result, and for products that will not be patched, the compensating controls communicated to customers.
Findings on a covered product arrive in days, not after the next scheduled test. See exploitability verification and the week this landed in, MedDevice AI Security Weekly, Issue 20.
Find out which products in your portfolio serve web requests through PHP.Inventory from the digital twin, exploitation evidenced on the real build, disposition per product.
PHP2Shell is the name for two critical vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026 and rated 9.2 on CVSS v4.0 by the PHP security team. Both allow unauthenticated remote code execution on any PHP installation that serves web requests, through PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed. ELTON tracks it as exploitability notification ELTON-EN-2026-002.
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026. The project published minimal source backports for the out-of-support 7.4, 8.0 and 8.1 branches, and Linux distributions and LTS vendors ship backported packages for the branches they support. PHP 7.3 and older receive no fix from the project, so a product on those versions is fixed only by upgrading the interpreter or through a vendor backport.
PHP runs inside device-embedded configuration and service interfaces, gateways, fleet dashboards, vendor appliances and the cloud backends behind connected devices. A device whose embedded web server runs an unpatched PHP, reachable on a hospital network, is remotely exploitable without credentials, and under mod_php the exploit runs before the application's login code. Fielded firmware carries whatever PHP version it was built with, and a device fix goes through verification and release, so the exposure window is months where a web server's is hours.
Apply the PHP project's temporary measures, which reduce exposure without replacing the patch: disable session.upload_progress and restart workers, set memory_limit per the project's guidance so applications cannot override it, lower post_max_size, set fatal_error_backtraces to 0 on PHP 8.5, and turn expose_php off. Then take the interface off networks that do not need it, with a management VLAN, firewall rules, or a reverse proxy carrying the published WAF rules.
From the digital twin and the SBOM, ELTON lists which products ship PHP, in which component, which SAPI and version, and where the interface listens. It then tests reachability on the device's real network interfaces and attempts exploitation against the real product build, so the disposition is an evidenced result rather than a version match. Each product gets a disposition, direct vulnerability, conditional, or weakness, with the evidence attached for the 524B plan or the submission.