PHP2Shell went from disclosure to mass exploitation attempts within hours. Cloudflare saw thousands of attempts across its network in the 10 hours before the October 21 announcement, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours and millions since. The NSA advised every organization using PHP to be ready to update immediately, and to take systems offline if they couldn’t.
Others gave the same advice. NHS England told affected organizations to patch or take vulnerable systems offline and AWS saw exploitation attempts before the flaws were made public. In Europe, government agencies in France, Finland and the Netherlands took websites offline as a precaution, along with hospital sites, the Port of Rotterdam and the Dutch soccer federation. Those shutdowns were preventive and don’t show that anyone was breached.
Downtime is the smaller problem. PHP2Shell can let an attacker run code on a server without logging in or read sensitive data from its memory.
For PE firms
Start with sites that handle sensitive data. Keep each finding open until the PHP fix is verified, even if an update is scheduled or a temporary block is in place.
Understanding the issue and its scope
PHP2Shell is two critical flaws in PHP, the language behind a large share of the web, including sites built on WordPress, Drupal and Joomla. They’re tracked as CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10 and both involve how PHP handles memory when a request fails. The flaws are in PHP itself so updating plugins or application code won’t fix them.
Wiz Research showed that passwords, authentication tokens and API keys can be read from PHP’s memory without taking over the server first. Patching closes the hole. It doesn’t make leaked credentials safe again.
PHP released fixes on October 21 for supported branches only.
For portfolios with legacy or acquired businesses, that last row will be the hard part.
Attempts are now in the millions, but how many succeed is still unclear. AWS saw an attempt against its decoy systems on October 17, before the fixes were out. On October 21, the PHP Foundation said it had seen only incomplete exploits. Security firm Tolmo said it built a working one in less than a day with help from AI. Assume working attacks exist now or will soon.
Exposed isn’t the same as breached. A vulnerable PHP version tells you a system was exposed. Finding out whether it was breached takes a separate investigation.
The risk across portfolio companies is real: what we see in our data
To see what exposure might look like across PE-owned companies, we looked at our TechLens diligence data for assessments conducted in the last few years.
PHP tends to sit at the edge of a company’s technology: a marketing site, a customer portal, an acquired product still on its original stack. Our assessors’ records show why those systems get missed.
How to read these figures
- We detected PHP from source files. That shows the code exists, not that it’s deployed, internet-facing or vulnerable.
- Version figures cover only engagements that declared a version. Companies using containers are overrepresented.
- Each figure reflects our most recent scan or assessment. Some companies will have upgraded since.
- Assessor records cover a partly different set of engagements than code scans (not every assessment includes one), so those percentages use their own base.
The systems most likely to be exposed are the least likely to have an owner or a patch schedule. A request sent only to the head of engineering will miss them. So will an inventory built from a keyword search.
What to ask each portfolio company
A typical portfolio relies on several hosting providers, development agencies and internal teams. Sending every company the same request with the same deadline is the fastest way to learn who owns what and where the gaps are. Ask each company to work through five steps:
- Find every internet-facing PHP system and name an owner
Include sites run by agencies and hosting providers. They’re the ones most often overlooked. - Patch in order of risk
Start with Apache servers usingmod_php, which PHP rates as the most exposed setup, then other internet-facing systems, prioritizing those that handle personal, financial, health or confidential data. Install the fixed version, restart the affected services and confirm the new version is the one actually running. Some hosts and Linux distributions backport the fix without changing the version number, so get the provider’s confirmation in writing. - Handle systems that can’t be patched
Anything on PHP 8.1 or earlier has no fix. Upgrade it, shield it with temporary protection such as web application firewall rules while the upgrade happens, or take it offline. Temporary protection isn’t a fix, so the system stays on the follow-up list until it’s upgraded. - Rotate credentials on exposed systems
Change passwords, API keys, database credentials and session or authentication tokens on any system that ran a vulnerable version while exposed to the internet. - Look for signs of compromise
Review web and server logs from October 17 onward for suspicious requests, unexpected processes and file changes as AWS recommends. Escalate anything credible through the company’s incident response process.
Tracking it on the PE side
Give each company one status:
For each, record the sites checked, the owner, the completion date and the evidence. Anything mitigated, unanswered or unresolved stays on the follow-up list until it’s closed with evidence.
A request you can send today
Copy and send the text below to portfolio company leadership.
To portfolio company leadership:
Please check your internet-facing PHP systems for PHP2Shell using https://scanner.crosslaketech.com/, including any sites managed by agencies or hosting providers. Patch to a fixed PHP version, starting with mod_php servers and sites that handle sensitive data. Tell us about any system running PHP 8.1 or earlier, since these can’t be patched, and your plan for each one. Rotate credentials on any system that was exposed. By [DEADLINE], please send us the systems assessed, their owners, their status and written evidence of the fix. Escalate any suspected compromise immediately through your incident response process.
Using the scanner across the portfolio
The Crosslake PHP2Shell scanner provides a starting point for checking potential exposure across your portfolio. It relies on publicly visible website information, which may not tell the whole story or reflect patches your hosting provider has already applied. Treat results as a prompt to check with your web team or hosting provider, not as confirmation that a site is vulnerable or fully patched, before agreeing on required changes.
- Scan only what you’re authorized to test. Agree on the target list with each company, including third-party-hosted sites, and confirm permission first.
- Check the production impact. Have the technical owner review how the scanner works before it runs against live systems.
- Record what was checked. Keep targets, scan time, tool version and any failed or skipped checks with the results.
- Rescan after fixing. A clean rescan plus the provider’s confirmation is good evidence the patch is in place.
Crosslake’s security practice brings AI security and governance, penetration testing, security diligence, fractional CISO leadership and ISO 27001, SOC 2, PCI and NIST audit readiness to help your portfolio close out PHP2Shell and stay ahead of the next one. Drop us a note at info@crosslaketech.com if you’d like to connect.