What is php2shell?
On 20 October 2026 the PHP project gave rare advance notice of an emergency release for two critical flaws, CVE-2026-109618 and CVE-2026-109619, each scored 9.2 under CVSS v4.0. Details had leaked online before coordinated disclosure, and the security community christened the pair “php2shell”. The fixes shipped on 21 October as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with minimal source backports for PHP 7.4, 8.0 and 8.1 for anyone who builds PHP from source.
Mirko Zorz at Help Net Security reports that a working exploit has shown a single unauthenticated request can trigger the attack before any application code runs. Security researcher Kevin Beaumont called it “one of the biggest vulns in years”. Cloudflare’s chief technology officer, Dane Knecht, said the company was seeing early attacks, and Cloudflare deployed firewall rules for the known exploit vectors to all its customers.
How many systems does php2shell affect?
The scale is hard to overstate. W3Techs puts PHP behind 69.3 per cent of websites whose server-side language is known. Security researcher Silas Cutler, quoted in Tenable’s php2shell FAQ, roughly estimates that more than 1.3 million internet-facing hosts are potentially vulnerable. As forensics specialist Hal Pomeranz put it, “there will be a long tail for this one.”
Exploitation is not theoretical. Amazon Threat Intelligence recorded an exploitation attempt against its honeypot network on 17 October, four days before the fixes were published, and reported on 21 October that php2shell is now being broadly exploited in the wild.
Why should a Microsoft house care about PHP?
Because PHP is rarely something a business chooses. It arrives inside the WordPress marketing site an agency built three years ago, the client portal a software vendor bundled, the hosting control panel bought on a company credit card, the appliance quietly humming in the comms room. CovertSwarm makes the point well in its briefing: exposure may sit in software you never installed as PHP. In my experience, most asset registers are drawn inside out, listing what IT bought. Attackers draw theirs outside in, listing whatever answers on the internet. The gap between those two lists is where incidents are born.
Patching is not the hard part. Finding every system that needs the patch is. And once you have found it, the next question is who owns it. The agency assumes the host patches. The host assumes the client does. The managed service provider was never told the site existed. Everybody is responsible, which in practice means nobody is. I wrote recently about clients discovering that a previous provider held the keys to their estate; this is the same disease in a different organ. It is also why clear ownership should be settled before you sign with any provider, and why third-party dependencies need mapping before an incident rather than during one.
AJ Thompson, Northdoor’s Chief Commercial Officer, said: “PHP quietly powers a huge share of the web, from company websites and online shops to customer portals and software that businesses may not realise contains it. That is what makes this so serious. Details appear to have leaked before the fix was ready, so attackers have had a head start. For boards, the question is not whether the IT team has heard about it, but whether anyone knows where PHP sits across the business, including in suppliers’ products. Organisations that cannot answer that today should treat this as a wake-up call. The response is the same as always: patch quickly, check your providers, and assume nothing.”
What php2shell means for regulated firms
For regulated firms there is a compliance edge as well. Cyber Essentials requires updates that fix critical and high-risk vulnerabilities to be applied within 14 days of release, and it requires software to be licensed and supported, which rules out the many sites still running PHP 8.1 or earlier. Firms in scope of the EU’s Digital Operational Resilience Act (DORA) have ICT risk management duties that do not stop at the edge of the Microsoft tenant. A regulator will not accept “the website belongs to marketing” as a control. The NCSC’s guidance on php2shell is clear that discovery should not be limited to outdated versions: every PHP installation should be found and assessed.
What to do about php2shell this week
The steps below follow the NCSC’s priority actions. Every organisation should:
- find every internet-facing system that runs PHP, including the ones IT never bought, and the appliances and vendor products that bundle it;
- confirm, in writing, who patches each one and by when, and ask hosting providers and software vendors to confirm their own fixes;
- move anything on PHP 8.1 or earlier onto a supported branch, or take it offline until it is;
- check patched systems for signs of compromise, because a patch closes the door but does not evict anyone already inside.
That last point matters more than it sounds. Patching does not remove a web shell planted yesterday, nor does it un-steal the database password sitting in a configuration file. Amazon advises investigating from 17 October, the earliest exploitation it has seen, rather than from the date of the advisory. If you cannot evidence that a system was clean before you patched it, assume it may not have been, and bring in incident response and endpoint monitoring where you lack the capacity to check.
What this means for your organisation
“Do we run PHP?” turns out to be the wrong question. The real question is whether you know everything that speaks for your business on the internet, and who is listening when it does. For most firms, the honest answer this week is not yet. The language you don’t know you speak can still say a great deal on your behalf.
If php2shell has raised questions about your own estate, our managed security services team can help you find what is exposed, confirm who owns it and check patched systems for signs of compromise. Get in touch to talk it through.