In October 2026, the PHP security team released emergency patches for two critical vulnerabilities, collectively known as PHP2Shell. Both allow an unauthenticated attacker to run code remotely on a vulnerable web server, and attacks were already being observed before the fixes landed. Applying a patch is the easy part. The question many organisations cannot answer is the one that comes first: where is our PHP?
PHP Vulnerability – what happened?
The two flaws, CVE-2026-109618 and CVE-2026-109619, were discovered by researchers at Calif, OpenAI and Wiz. Both allow remote code execution without authentication, and both affect PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
They stem from the same root cause: PHP can be left with corrupted memory when a request ends abnormally. The PHP security team rates the risk highest for mod_php, where a demonstrated exploit allows an unauthenticated request to trigger the attack before any application code even runs. Once exploited, the threat actor gains remote code execution with elevated privileges.
The response has been swift and serious. Cloudflare reported early attacks targeting the flaws before patches were available, and the UK’s National Cyber Security Centre advised organisations to update immediately, or take affected systems offline until they could be patched.
Why this one mattered?
PHP is estimated to power 75 to 80 per cent of all websites, including those built on WordPress, Joomla and Drupal. VirusTotal estimates that more than 5.1 million PHP hosts are exposed to the internet. That is a very large target surface, and threat actors have already shown they are willing to use it.
But for most organisations, the patch itself is rarely the difficult part. Knowing where PHP is running is. It tends to hide in places like:
- A legacy intranet nobody has touched in years
- A campaign microsite that was never decommissioned
- A customer portal run by a supplier
- A plugin quietly installed years ago
A system nobody remembers owning is a system nobody patches.
What to do now?
The PHP project has released fixed versions for each supported branch. Teams running PHP 8.x should move to the relevant release as soon as possible.
- Running PHP 8.1 or older? These versions are end-of-life and no longer receive updates from the project. Either upgrade to a supported release, or ask your distribution or LTS vendor whether they have provided a backported fix. The PHP team has also published minimal source backports for PHP 7.4, 8.0 and 8.1 for those building from source.
- Cannot patch immediately? The PHP team has shared temporary mitigations, such as tightening request size limits and disabling session upload progress. These reduce exposure to some attack paths only. A core PHP developer was clear that no mitigation fully blocks these attacks, and that applying the official patches is the only permanent defence.
The window keeps shrinking
The PHP team gave administrators advance notice. A few days before release, it urged teams to prepare to install updates the moment they were available, and reserved the right to release earlier if details became public or exploitation appeared in the wild.
This is how critical disclosures now work. Defenders get a short window, often measured in hours, between the warning and the point where threat actors start probing. Cloudflare had already deployed WAF rules against known exploitation methods, and still stressed that they were a stopgap, not a substitute for patching.
The uncomfortable truth
PHP2Shell is a reminder that vulnerability management is only as strong as your asset inventory. You cannot patch what you do not know you have. Four questions are worth putting to your team this week:
- Do we have a current list of internet-facing systems that run PHP?
- Which of those are on unsupported versions?
- How quickly could we patch a critical flaw, and who owns that decision?
- Do our suppliers and hosting providers have answers to the same questions?
If any of these are difficult to answer, that is a useful finding in itself. It is far better to discover the gap during a calm review than during an incident.
Your first 48 hours
For teams working through this now, a practical order of play looks like this:
- Find it – List every internet-facing system running PHP, including those run by suppliers, hosting providers and agencies on your behalf.
- Rank it – Prioritise systems that serve requests directly to the internet, particularly those using mod_php, which the PHP team rates as highest risk.
- Patch it – Move to a fixed release, or confirm in writing that your vendor has applied a backported fix.
- Contain what cannot be patched – Apply the published mitigations as a temporary measure, and consider taking exposed systems offline if the NCSC’s advice applies to you.
- Record it – Note what was affected, when it was fixed, and who signed off. This evidence matters for audits and for any later incident review.
The question for the board
Events like this are a good test of how vulnerability management works in practice, not on paper. Standards such as ISO/IEC 27001 expect organisations to maintain an asset inventory and a process for acting on technical vulnerabilities. Boards and executives are increasingly asking the same thing in plain language: how fast can we respond when something critical is announced?
The organisations that answer confidently tend to share a few traits. They know what they own, they know who is responsible for each system, and they have rehearsed the decision to patch, mitigate or isolate before they need it.
Morrisec’s external attack surface reviews and penetration testing help organisations identify what they are exposing to the internet, including the systems they have forgotten about. Combined with a structured vulnerability management process, this turns an emergency like PHP2Shell into a routine patch cycle rather than a scramble.
If you would like to speak to a Morrisec Consultant about your own exposure CLICK HERE!
0 Comments