SecurityScorecard’s STRIKE Threat Intelligence Team found that approximately six million 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.
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? |
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.
- Check each system’s PHP version, because PHP 8.1 and earlier no longer receive security fixes.
- 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.
- Check logs for signs of earlier attacks, such as memory-limit errors, repeated server errors, or unexplained PHP worker restarts.
- 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 with the Driftnet add-on can create a php2shell response workflow, as seen in this video.
