PT0-002 Practice Question: A penetration tester is using a vulnerability…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The scanner used an outdated vulnerability database that does not match the application's patches

  Why it's wrong here

  An outdated vulnerability database commonly produces false negatives because newly published CVEs are absent, not false positives. Although a stale database can in principle flag a CVE that was already patched in an update the scanner does not recognize, such a mis-match would affect many hosts with the same software equally and does not explain why a custom application would be singled out; the more precise cause is version-based detection that ignores custom code modifications.

• ✗

  The scanner identified the application version from the HTTP response header, but the vulnerability was already patched in that version

  Why it's wrong here

  Reading the application version from an HTTP response header can cause a false positive when a backported security fix is applied but the version string remains unchanged, or when the banner reflects a generic framework instead of the exact patch level. While possible, this mechanism is less common in custom applications because enterprise scanners typically corroborate header fingerprints with multiple additional signatures, so the more probable explanation is a vulnerable bundled library whose code path is not actually reachable.

• ✓

  The scanner detected a vulnerable library used by the application, but the application's implementation does not expose the vulnerable code path

  Why this is correct

  This is the classic false-positive scenario: a scanner identifies a third-party library (such as a JavaScript framework or open-source component) by its version string and matches it against known CVEs, but it cannot determine whether the application's code ever calls the vulnerable function or passes attacker-controlled data into it. Even when a library has a security flaw, if the custom application either implements the code path safely or never exposes it, the finding is not actually exploitable. A penetration tester must manually trace the application's logic and confirm reachability before reporting a confirmed vulnerability.

• ✗

  The scanner performed an exploit attempt that succeeded on a different service on the same host

  Why it's wrong here

  If an exploit attempt succeeds against a different service on the same host, that outcome is a true positive for that co-located service, not a false positive for the custom application. The scanner might have presented the finding under the application's asset, but the exploit actually affected a separate component such as an adjacent database or API endpoint, meaning the finding needs to be re-attributed to the proper service. By definition, a confirmed successful exploit proves a real vulnerability exists, so it cannot be labeled a false positive in any context.

Go deeper

Related to this question