PHP patching is an inventory problem before it is a patch problem
CISA and the NCSC urge immediate patching of two critical PHP flaws, now on the exploited list. Cyber teams must first find every PHP install, including those inside other software.
What happened
On 21 October 2026, CISA published an alert urging organisations to patch two critical vulnerabilities in PHP immediately. They are CVE-2026-109618 and CVE-2026-109619, known as "php2shell", and they allow unauthenticated remote code execution. The UK NCSC published its own alert the same day. CISA updated its alert on 26 October to say both CVEs had been added to its Known Exploited Vulnerabilities catalogue.
CISA says the flaws affect all PHP installations that serve web requests, including Apache with mod_php, which PHP regards as the highest risk, plus PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The PHP Foundation's account of the two flaws is specific. In CVE-2026-109618, a request that hits PHP's memory limit at the wrong moment can leave partially initialised internal data that PHP later treats as valid, corrupting memory. The Foundation says remote code execution was demonstrated on Apache with mod_php using default settings, and the issue was also confirmed on PHP-FPM through application-level code paths. In CVE-2026-109619, a fatal error at the wrong point can leave state pointing at memory from a previous request, so a later request on the same worker uses freed memory.
The Foundation also describes a messy disclosure. CVE identifiers leaked on 20 October with an incorrect release time and an incorrect score of 10.0, where it says the actual score is 9.2. The release moved forward from 22 October to 21 October. It says a proof-of-concept video was published by mistake and that a container image vendor published fixed images more than six hours before the coordinated release.
Why it matters
The hard part is knowing where PHP runs. CISA's first recommended action is to identify and inventory all systems running any PHP version, including PHP embedded in other software. The NCSC says the same and adds that appliances and services may bundle PHP. Many organisations can list the web servers they built. Far fewer can list the control panels, network devices and packaged applications that quietly carry a PHP runtime.
The exploited list changes the clock. Once a vulnerability is on CISA's catalogue, the question is no longer whether someone will use it but whether they already have. Your exposure window is measured from 21 October, not from the day your own patch cycle next runs.
Unsupported versions have no good answer. CISA's guidance for systems that cannot be updated, or that run PHP 8.1 or earlier, is to take them offline until they are patched or updated. That is a business decision with an outage attached, and it is better made now with a plan than at the point of compromise.
Disclosure chaos favours attackers. Leaked identifiers, a published proof-of-concept video and an early fixed image all shortened the time defenders had. Plan on the assumption that useful detail about a serious flaw will be public before your patch window opens.
What we would do
- Build the PHP inventory today. Start with internet-facing systems, then internal ones. Include web hosting, content management systems, admin panels and any appliance with a web console. Ask every relevant supplier in writing whether they bundle PHP and when their fix ships.
- Patch internet-facing systems first. Use the fixed releases CISA lists, 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and restart the services that load PHP so the new version is in use.
- Set a decision point for what cannot be patched. For each system, choose between the PHP mitigations, a web application firewall as a stopgap, or taking it offline, as the agencies advise. Record who made the call and when it will be revisited.
- Hunt for compromise, not just exposure. CISA suggests monitoring for PHP worker processes launching shells or downloading tools, and has added a SIGMA detection rule. Where a system was exposed and unpatched, check for backdoors before assuming it is clean.
- Rotate secrets on any system you cannot clear. Database credentials, API keys and session secrets held by a web process should be treated as exposed if the host may have been compromised.
- Plan the end of unsupported branches. Put PHP 8.1 and earlier applications on a migration schedule with an owner, because the next critical flaw will meet the same problem.
We would also treat this as a rehearsal. How long it took to produce a full PHP inventory is a good measure of how you would cope with the next flaw in a component you did not know you ran.
Questions we are asked
How do we find PHP that is embedded in other software?
Start from what you can see on the network, then ask suppliers. Scan internet-facing hosts for PHP response headers and admin panels, check your software and appliance inventory for products with web consoles, and request a statement from each vendor on whether they bundle PHP and when a fix will ship. The NCSC specifically advises monitoring third-party vendor updates because appliances and services may include PHP.
What if we cannot patch an affected system today?
Follow the order the agencies give. Apply the temporary mitigations PHP provides, and if those are not possible or would take too long, take the system offline. CISA also says a web application firewall may offer some protection while you patch. If a system must stay up, check it for signs of compromise and backdoors, and consider an assured incident response provider if you lack the skills in house.
Does being on PHP 8.1 or earlier change anything?
It makes your position worse. CISA lists fixed releases only for the 8.5, 8.4, 8.3 and 8.2 branches, and says to take PHP 8.1 and earlier systems offline if they cannot be updated promptly. The NCSC says all PHP versions are considered affected and advises moving older versions to a fully supported release. Treat an unsupported branch as a migration project with a date.