What an external website scan can't prove (and what can)

No. A website scan run from outside cannot prove that a site has no weaknesses, and no honest scanner says it can. It reports what your site shows to any visitor and what public records say about those versions. Proof that a fix is installed and running comes from the server or the host: a package identifier, a restart time, a log.

What does an external scan actually see?

It sees what you publish to the open internet. That is a lot: the technologies and versions your site announces, exposed .git and .env files, readable source maps, security headers, TLS settings, DNS records that point at services you no longer own, and ports reachable from outside. These are real findings, and a stranger could find them too.

Red's free scan reads the stack your site serves, the way Wappalyzer does, then looks each version up in public vulnerability records. It is a lookup. It can say a version is affected. It cannot say whether your setup is exposed.

The position it tests from is the limit. It stands where an anonymous visitor stands. Everything on the other side of that line is invisible to it, however good the scanner.

What can't it prove, and why?

Five things recur, and PHP2Shell shows each of them in one incident.

1. That a version is fixed

Version numbers lie in both directions. Debian's security FAQ says it backports security fixes to the version in the stable release instead of upgrading, and tells readers to check the package changelog. Red Hat says that looking at the version number of a package will not tell you whether you are vulnerable, and that tools judging by version alone produce false positives.

PHP2Shell makes this concrete. CloudLinux says its packages carry the fix as a backport, so ea-php84 is 8.4.26, not 8.4.27. Canonical lists Ubuntu 22.04's fixed PHP as 8.1.2-1ubuntu2.28. An outside scan reading "8.1" or "8.4.26" sees a number below the upstream fix. The server may already hold the fix.

2. That the version it read is the one serving the request

The PHP project says its scope is all PHP installations serving web requests, including PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. A server can run several PHP builds side by side. The header a scanner reads, the version your control panel shows and the php -v result in a terminal can each describe a different one.

3. That the fix is running, not just installed

A fixed package on disk changes nothing for a worker that started before the update. Canonical says the application that uses PHP would likely need to be restarted or the system rebooted. The PHP notice itself tells owners to restart every worker after a configuration change. No outside request can read when a process started, and restarting PHP-FPM after an update has its own steps.

4. That the stack hides nothing else

A scan matches what it identifies. A hidden version, a custom build or a component behind a proxy goes unmatched, and unmatched reads the same as absent. Aikido's PHP2Shell checker says on its own page that a negative result does not prove PHP is patched, and gives patched PHP, a raised memory limit, a rejected request and an untested path as other explanations. That is a checker vendor stating the limit of its own method; what a PHP2Shell checker can confirm is set out on its own page.

5. That nothing has already happened

Absence of findings today says nothing about last week. AWS reported a PHP2Shell attempt in its honeypots on 17 October, four days before disclosure, and said it was unclear whether any would have succeeded on real systems. If a site was reachable and unpatched in that window, a later patch removes the hole and not anything planted before. Sucuri states that its remote scanner only sees the browser level and will not detect anything on the server side. Compromise evidence lives in files, logs, accounts and scheduled tasks.

Can a "no findings" result ever mean something?

It means something narrow. It says that at the time of the scan, nothing the scanner knows how to recognise from outside matched. That is useful, and the sentence has a date and a scope in it. Why a clean free scan misleads people is worth a read.

It does not mean "secure". Red never reports a site as safe or secure. A vulnerability record also lags the world: a CVE can be exploited before it is in CISA's Known Exploited Vulnerabilities catalog. CISA describes that catalog as one input to vulnerability management, not an inventory of everything exploited. At our 24 October check, neither PHP2Shell CVE was among the entries shown for 8 to 23 October, while AWS had already reported attempts. Absence from a list is not evidence of absence.

Does the host's own message settle it?

Not always, and the confusion is documented. Namecheap's status update says it installed the fixes on all shared hosting servers as soon as CloudLinux released them, and that the initial patches lacked proper version number updates, which created confusion about fix status. A customer who read the version at the wrong moment, or a scanner that did, would have drawn the wrong conclusion.

So "we patched" is a claim, not a record. The record is a dated identifier and a restart time for your domain. The wording to send a host is in a message you can send your host, and the version trap is unpacked in the Debian and Ubuntu backport guide.

What evidence does settle it?

Evidence has to come from inside. This table pairs each thing a scan cannot prove with the evidence that can.

For the PHP steps in order, see the PHP2Shell fix guide. For the wider question of whether a WAF closes the gap, see does a WAF stop PHP2Shell.

Am I affected? Where you stand right now

What is an outside scan still good for?

Plenty, as a first look. It shows what a stranger sees before anyone has to log in anywhere. It finds files that should never be public, keys shipped in a bundle, a panel left online, a certificate about to expire. It gives you a short list of questions, and a dated note of what was and was not visible.

Red's free scan is one per domain with no card. You add one DNS TXT record so nobody can point it at a site that is not theirs. The full scan is $100 per scan: an AI red team lists what it can reach from outside, ranks the paths worth trying, links small findings into one path, proves access once with evidence, stops, and writes up the path and the fix. It is still an outside view, and the report states what was reached. It does not replace the server-side evidence above.

How should I use a scan result?

• Write down the date of the scan and which findings it gave.
• For every "unknown", name who holds the evidence: you, the host or the agency.
• Send that person the exact question, and ask for the package or build identifier and the restart time, in writing.
• Keep the reply with the scan. The pair is your record.
• Review the server for what happened before the fix, which no scan covers. The step-by-step compromise response guide lists what to look for.
• If you are unsure who owns the patching, read how patch ownership splits between you and the host.

For a consultant or auditor, the useful record has four items: the identifier, the restart time, the person who confirmed it and the date of any outside scan with what it could not see. A screenshot of a scan result is not that record.

Why not just ask for a different scanner?

A better scanner still tests from the same position, outside the server. NIST SP 800-115 treats security testing as a set of techniques, each with benefits and limitations, to be planned and combined. Credentialed scans, agent-based inventory and a host's own audit see more because they stand on the server. They need access you grant.

Pick the tool by the question. "What does a stranger see?" is an outside scan. "Is this server patched and restarted?" is a host or server question. "Could someone chain small findings into access?" is a tester question. Each is a different position, and none of them alone answers "is it secure". The other evergreen guides cover the basics.