SecurityScorecard’s Our STRIKE Threat Intelligence Team found that over 7.6 million at time of publication SecurityScorecard-observed internet-facing assets run PHP.
Widely used PHP components mean one unpatched flaw can expose dozens of agencies at the same time.
The PHP news is more than a patching problem. Two critical flaws in a commonly used programming language that emerged in recent days could take public services offline, and shared dependencies could multiply the damage.
Cloudflare’s chief technology officer (CTO) said early PHP attack attempts are emerging, and the company has deployed emergency web application firewall (WAF) rules. The security team behind PHP shipped patches, but for many organizations it will be a question of whether they are able to patch quickly enough to prevent abuse.
SecurityScorecard’s STRIKE Threat Intelligence Team found approximately six million SecurityScorecard-observed internet-facing assets run PHP. That’s a huge footprint, and when one flaw shows up, it can ripple across a lot of systems at once. Security teams need to know which services depend on vulnerable systems and how many agencies lean on the same hosting provider, MSP, or underlying tech.
What We Know So Far
PHP maintainers published a security release on October 20. The two vulnerabilities score 9.2 on the Common Vulnerability Scoring System (CVSS) v4 scale (see CVE Details for more information). Researchers at watchTowr reported possible Common Vulnerabilities and Exposures (CVE) identifiers and a scope that may reach every PHP version from 5 onward.
Public patches may give attackers a map of what changed, so defenders should expect exploitation attempts in the coming days.
Read more about the six million exposures SecurityScorecard’s STRIKE team observed in our technical blog.
What Running Our Own Response Taught Us
We didn’t just advise on this one — we worked it across our own assets. A few lessons worth passing on:
- “We only run one PHP app” is almost always wrong. Our first read was a single app. The reality was PHP spread across that app on managed hosting, self-managed VMs in several cloud accounts, containers still on end-of-life versions, and an orphaned demo box no current team owned. Your inventory should come from scanning and cloud telemetry, not from asking around. The forgotten assets are often the exposed ones.
- A WAF rule in front of a reachable origin is theater. Edge providers shipped emergency rules within hours, but those rules work only when traffic actually passes through the edge. Several of our highest-risk hosts resolved directly to their cloud origin IPs, so an attacker could skip the WAF entirely. Deploying the rule isn’t the control. Confirming the origin can’t be reached directly is.
- “Patch to 8.2.35” is not how patching actually works. On most managed Linux distributions the upstream version number won’t appear in your package manager; you’ll get a backported revision (for us, Ubuntu’s fix via USN-8948-1). Track your distribution’s advisory, not the upstream version number. Otherwise your team may waste time hunting for a release that isn’t in their repository. End-of-life doesn’t always mean rip-and-replace as well. Extended-support channels shipped backports even for 7.4 and 5.x.
- Who patches depends on who runs it, so split the work on day one. Our managed-site providers handled their own patch response, but we still opened a vendor ticket and verified they actually patched. Our self-managed hosts were our responsibility. “Out of scope” doesn’t mean “safe to ignore.” A subdomain outside your assessment scope is still part of your attack surface.
- This bug leaks memory, so patching isn’t the finish line. One of the two flaws can disclose process memory (tokens, keys, credentials). If you see any sign of probing on an exposed host, assume secrets may have been read and rotate them. Patching closes the hole, but it doesn’t undo what an attacker already took.
- Verify your own tooling’s output before acting on it. Even automated vulnerability reporting needed a second look during our response. Confirm findings against the source of truth, such as PHP’s advisory or your distribution’s security notice, before building the remediation plan. Tool output is a lead, not gospel.
Read more in our customer advisory blog here.
We found that about a day after PHP2Shell was disclosed, our honeypot sensors recorded a fully automated exploitation attempt that took under two minutes, chaining session poisoning with local file inclusion to run a shell downloader. We assess with moderate confidence that it came from RedTail, a Monero cryptomining botnet known for quickly adopting new PHP exploits. Read more about what we’re seeing here.
Start With the Public Services You Must Keep Running
Check your PHP versions first. PHP 8.1 and earlier reached end of life, so those versions will not receive an official fix. Confirm affected and fixed versions in PHP’s official notice, and plan upgrades for any unsupported system.
Then change how you prioritize. A patch backlog treats every vulnerable system the same. Agencies and many private sector companies cannot afford that approach. Start by asking what public services depend on these systems, and what happens if attackers compromise them or force them offline.
Then rank by mission impact. Which systems support public safety and emergency services? Or will health, transportation, benefits and payments, or elections and other essential citizen services be vulnerable?
Shared Dependencies Create Common Points of Failure
An often overlooked risk is concentration. Multiple agencies or critical infrastructure entities may rely on the same hosting provider, MSP, or underlying technology. A single compromise at one of those points could cascade across all of them at once.
That changes how you count. What looks like hundreds of separate exposures across agencies may trace back to far fewer shared points of failure. Each one can trigger cascading disruption across services that appear unrelated. The question isn’t only which systems are vulnerable. It’s which public services depend on them, and how many organizations share the same point of failure.
Map those dependencies now. Identify which providers sit behind your highest-priority services, and which of those providers also serve neighboring agencies.
Decide What Stays Online Based on Consequences
Whether a system stays online is a consequence-based decision. Score each service starting with these six categories, starting with the highest mission impact:
| Category | Question to ask |
| Exposure | Is the system reachable from the internet? |
| Exploitability | Are attackers already testing the flaw? |
| Mitigation speed | Can we patch or apply compensating controls quickly? |
| Data sensitivity | What data would attackers reach? |
| Lateral movement | Could attackers pivot from this system to others? |
| Public impact | Does an outage or a compromise case more harm? |
One caution from our own triage: don’t rank by finding count. Our noisiest host, with hundreds of findings, was not our most dangerous one. The one that mattered most was live, internet-facing, and had its full port range open, yet it had far fewer findings attached. Prioritize by reachable exposure and potential consequence, not by raw counts.
Taking a service offline may protect data but interrupt public services. Leaving it online keeps the service running but risks compromise. Decide in advance which outcome your agency can tolerate for each service.
Preparation is the best move today.
- List every production system that runs PHP, including sites owned by teams outside IT. Tag each as managed or self-managed (the fix and the owner differ) and build the list from scanning and cloud telemetry rather than from memory.
- Check each system’s PHP version, because PHP 8.1 and earlier no longer receive security fixes. Chase your distribution’s advisory, not the upstream number (for us, Ubuntu USN-8948-1).
- Tie each system to the public service it supports.
- Identify the hosting providers, MSPs, and shared technologies behind those services.
- Tier systems by mission impact, then apply the six consequence categories above.
- Assign an owner and a patch window to each system.
- Confirm your WAF provider has deployed rules, and treat them as temporary. Then confirm the rule is actually in the request path. An edge rule protects nothing if the origin is reachable directly.
- Check logs for signs of earlier attacks, such as memory-limit errors, repeated server errors, or unexplained PHP worker restarts. If you find any, assume process memory may have leaked and rotate exposed secrets.
- Re-check the official PHP notice after the release, because affected versions and identifiers may change.
What to Ask Hosting Providers and Vendors
Your exposure extends to the providers behind your services. Reach out today to key partners and ask:
- Do you run PHP on any system that supports our services or handles our data?
- Which PHP versions do you run?
- When do you plan to patch?
- Which compensating controls, such as WAF rules, protect those systems until then?
- Which of our services share infrastructure with other customers?
How to See Shared Exposure Across Your Providers
SecurityScorecard’s scanning capabilities find exposed infrastructure with telemetry that can identify vendors running exposed PHP. TITAN Secure customers can create a php2shell response workflow. See the walkthrough video for details.
Learn more about the six million exposures SecurityScorecard’s STRIKE team observed in our technical blog.
