How to verify a vulnerability is fixed: 5 proofs to ask for

To verify a vulnerability is fixed, collect evidence from the running service, not from the dashboard. You need the fixed package or build that names the CVE, a restart or redeploy after it, and a check that the process serving your domain is the one you updated. A version number or a clean outside scan alone proves little.

This page uses PHP2Shell as the running example because it is the live case this month. The method works for any server-side fix, and the other evergreen guides cover the neighbouring questions. For the PHP specifics, see the PHP2Shell fix guide.

What does "fixed" actually mean?

Three things have to be true at once. The fixed code is on the machine, the process that answers your visitors is running that code, and the request path to your domain reaches that process. Most "we patched" messages cover only the first.

That gap is where owners get misled. A host dashboard shows the package state. A changelog shows the vendor shipped a fix. Neither shows what is running right now for your domain.

Which five pieces of proof should I ask for?

Ask for as many as the situation allows. Each one closes a different gap, and each has a blind spot.

Proofs 1 to 3 come from the server or the host. Proof 4 is the only one you can collect without them, and it is the weakest. The next sections take them in order.

How do I read the package proof?

Read the package changelog for the CVE id. Do not read the version alone, which is the backport version trap in short. Debian explains that it backports security fixes to the version shipped in the stable release rather than moving to a new upstream version. AlmaLinux tells customers to confirm a patched build with rpm -q php-common and not to rely on php -v, because its fixes are backported.

CloudLinux gives a concrete case. At its 23 October 2026 update it said most packages carry the fix as a backport, so the fixed ea-php84 build is 8.4.26-2 and not 8.4.27. A reader comparing numbers would call that unpatched. The changelog entry naming both CVE ids is what settles it.

The vendor tracker is the next place people stop. At our check on 24 October 2026 the Debian tracker listed bookworm fixed at 8.2.35-1~deb12u1 and trixie fixed at 8.4.27-1~deb13u1. That tells you the package exists. It does not tell you that your server installed it.

How do I prove the service restarted?

A fixed package on disk does nothing for a process that loaded the old code before the update, and restarting PHP-FPM after an update is the step most often skipped. Canonical's notice says the application that uses the PHP interpreter would likely need to be restarted, or the system rebooted. PHP's own notice tells operators applying its settings to restart every worker.

These checks need shell access and only read state:

• Compare the package install time with the service start time. systemctl show <unit> -p ActiveEnterTimestamp reports when the unit last entered the active state, per the systemd interface documentation. The start must be later than the install.
• Ask the system which services still run old code. On Debian and Ubuntu, needrestart checks which daemons need a restart after library upgrades. On RPM systems, dnf needs-restarting with -s lists the affected services.
• Look for a replaced binary. Per the proc(5) manual, a link to an unlinked executable carries the string (deleted). A PHP process showing that predates the update.
• If you run PHP-FPM, read the pool's own start time. The FPM status page exposes a pool "start time" and, in full mode, a per-process start time.

For containers there is no restart to prove. The container is replaced, so compare the running container's image digest with the image you built after the base image changed. On managed platforms, the instruction is usually a redeploy, as Heroku's changelog says: redeploy your apps to pick up the fixed versions.

What does a scan from outside prove?

Less than most people hope. An outside check reads what the site volunteers: headers, a version string, known paths, exposed files. It cannot see the package changelog, which runtime serves a given virtual host, or when workers last started.

A competitor's own checker page makes the same admission. Aikido's PHP2Shell checker says a clean result does not prove PHP is patched, and that a version in X-Powered-By is a hint that may not account for vendor backports. A clean result can mean the fix is installed, but also a rejected request, an untested path or a proxy in front.

The same logic applies to a firewall. Cloudflare says customers should still patch their PHP installations, with WAF protection as an extra layer. A blocked probe means the edge did its job (what a WAF does and does not cover). It says nothing about the origin.

Outside checks still earn a place. They catch the cases where nothing needs asking: a visible version already below the fix, an exposed .env, a forgotten service. They are a first filter, not the finish.

Am I confirmed? A three-state self-test

What exact question gets a usable answer from a host?

Vague questions get vague replies. "Is it patched?" invites "yes, fully deployed". Name the CVE, the domain and the two pieces of evidence you want.

For [your domain], is the runtime that serves web requests fixed for [CVE ids]? Please give the fixed package, build or backport identifier, the time all workers serving it were restarted or replaced, and whether I need to redeploy or change a setting.

Then read the reply against this table.

Who is responsible for patching, host or site owner, is covered separately. For the PHP-specific wording to send a provider, see questions for a shared host.

How do I check a fix on a fully managed platform?

You usually cannot see the process, so you verify the platform's output instead. Read the deploy or build log for the resolved runtime. Confirm the running release is newer than the redeploy. Ask support for the deployed build or image digest. Heroku's PHP support instruction is a redeploy, and a rebuild that reuses an unchanged lock file can resolve the same old runtime, so the log matters more than the fact that you deployed.

Does verification need a retest by a tester?

Sometimes. The OWASP Web Security Testing Guide says focused penetration testing can be useful for detecting whether specific vulnerabilities are fixed in the deployed code. That fits flaws in your own application, where the fix is a code change and the proof is that the attack path no longer works.

It fits server-side runtime bugs less well. A failed attempt against a patched-looking server does not prove a fix, because the attempt may have missed the condition. Use a retest as one more piece of evidence, never as the only one. A request-level test also needs the owner's permission, and nobody should run one against a host they do not control.

What should the record say?

A fix is easier to defend when it leaves a note. Keep one short record per site, and date it.

• The CVE ids and the vendor advisory link
• The fixed package or build identifier, from the changelog
• The install time and the restart or redeploy time
• The check you ran on the running service, and its result
• What you could not see, such as other pools or the origin behind a proxy
• The date, and who ran the checks

That note answers the question clients and managers ask next: how do you know. It also keeps patch state apart from a different question, whether anything entered before the fix. For that, see the step-by-step incident checklist and, for PHP2Shell, whether your site was exploited.

If you want an outside view of what your own site shows, the free scan reads the stack your site serves and matches each version to known vulnerabilities. It is a lookup. It can say a version is affected, not whether your setup is exposed. For the wider list of this month's fixes, the month's incidents and patches in one list links each one.