Scanner Finding vs. Proven Exploitability
Lab / Educational
Why the distinction matters
A vulnerability scanner produces findings, not facts about your risk. A finding says “this version string or response pattern matches a signature associated with CVE-X.” It does not say the vulnerable code path is reachable, that the preconditions are met, or that exploitation leads anywhere useful. Treating every red row as a confirmed breach-in-waiting burns remediation budget, erodes trust with the teams you hand findings to, and buries the few findings that actually matter.
Anatomy of a scanner finding
Signature match. Most scanners infer a vulnerability from a banner, a package version, or a response fingerprint — not from executing the exploit. Backported security patches (common on Debian and RHEL) frequently leave the version string looking vulnerable while the code is already fixed. This is the classic false positive.
Severity (CVSS) is context-free. A CVSS base score describes the flaw in the abstract. Your environmental and temporal metrics — is it internet-facing, is there a compensating control, does a working exploit exist — are what turn a number into a priority. A CVSS 9.8 on an internal host behind mutual TLS with no reachable code path may matter less than a 6.5 on your public login page.
A triage workflow
# A pragmatic order of questions for each finding:
1. Is the version string actually the running code? (backport check)
2. Is the vulnerable component present AND loaded?
3. Is the vulnerable code path reachable by an attacker?
4. Are the preconditions met? (auth level, config flag, feature enabled)
5. What does successful exploitation actually grant?
6. Is there a compensating control already in the path?Only after these do you assign a real priority. Steps 1–2 kill most false positives; steps 3–5 separate “theoretically vulnerable” from “exploitable in our deployment.”
Reachability and preconditions
Reachability is the question scanners are worst at. A library can contain a notorious deserialization bug, but if your application never passes attacker-controlled data into the affected sink, the flaw is latent, not live. Conversely, a “medium” finding on an input that reaches an unauthenticated endpoint can be your single most important issue. Map the data flow before you map the CVE. For WordPress specifically, this is also where you distinguish compromise of the application from compromise of the underlying server: gaining admin in wp-admin is not the same as code execution as the web-server user, which is again not the same as root. State which boundary a finding actually crosses.
Proving it in a lab, not in prod
If a finding is plausibly exploitable and the impact justifies it, reproduce it in an isolated, disposable environment — never by firing exploits at production. The companion disposable web app lab exists for exactly this. Reproduction gives you three things a scanner cannot: a definitive yes/no on exploitability, a concrete remediation you can regression-test, and a sample of the telemetry the attack generates so your detection team knows what to look for.
Writing it up honestly
Label each finding as confirmed exploitable, exploitable with preconditions, not exploitable as deployed, or unverified / needs testing. Record exactly what you tested and what you only inferred. An assessment that honestly says “I could not reproduce this” is worth more than one that quietly launders scanner output into claimed compromise.