PHP Site AuditHosting and runtime checks
How do I check every PHP site in a hosting account?
Create an inventory that maps each public hostname and PHP workload to its web handler, package source, installed build, owner and patch evidence. A single domain banner, dashboard or command-line version cannot establish the status of every site on an account or server.
Inventory hostnames and workloads
Start from authoritative account records: DNS zones, web-server virtual hosts, hosting-panel domain lists, load balancers and deployment repositories. Include apex and www names, subdomains, staging hosts, tenant or customer domains, APIs and alternate regions. Then list non-browser PHP workloads such as queue consumers, cron jobs, import tools and administrative scripts; a public website scan will not discover all of them.
For each item record the owner, business purpose, environment, hostname, PHP SAPI or handler, package or image source, deployed build, and restart/rollout evidence. Mark unknown values as unknown rather than inferring them from a neighboring site. Shared infrastructure often has more than one runtime, pool or image, so the mapping should be explicit.
Prioritize according to exposure and evidence
PHP's October 21 advisory covers PHP installations serving web requests and says distributions and long-term-support vendors may backport fixes. PHP 8.1 and older no longer receive project releases, although some vendors may provide fixes. Use the related fixed-version guide for the upstream release list, and request each package advisory instead of labeling every lower number vulnerable.
Prioritize internet-facing runtimes and systems with high-value data, then identify unsupported versions and owners who cannot patch. The NSA recommends taking a system offline if an immediate update is not feasible. A business should make that decision with its security and service owners, balancing the operational impact against exposure and documenting interim measures and the patch deadline.
Track completion without a false all-clear
A row is not complete merely because a ticket says “updated.” Attach package/build evidence, map it to both CVEs, record deployment and worker restart time, and test a representative web request or workload. If the provider uses backports, record the vendor package revision and advisory. Retest after failover, autoscaling or redeployments if those could reintroduce an older image.
Use an explicit status vocabulary such as verified fixed, vendor confirmation pending, not applicable with evidence, unsupported, or unknown. A missing banner can be deliberate; an old banner can be stale; a web response does not inventory private workers. Keep uncertainty visible so leaders can distinguish completed remediation from unresolved scope.
Common questions
Is one public scan enough for ten subdomains?
No. It samples only its declared host and paths; enumerate each runtime and related workload separately.
Can the hosting dashboard show all runtimes?
Sometimes it helps, but confirm that the inventory covers actual web handlers, background workers and vendor package versions.
When may I call the fleet patched?
When each applicable workload has evidence for the fix and the running process uses that build, or a documented exclusion is reviewed.