TL;DR: Scanners disagree about the same CVE because they examine different evidence: scan timing, access, detection methods, vulnerability data, and software components. Compare the endpoint, component, file path, version, timestamp, and vendor advisory instead of trusting the louder dashboard. Then remediate what's real and rescan.
One scanner flags a critical CVE. Another has nothing to report on the exact same endpoint. Don't just trust either one. Vulnerability scanner discrepancies usually come down to evidence you can check. They're about either presence (is the vulnerable software there?) or severity (how bad is it?), and each needs a different fix.
Why can scanners report different results for the same CVE?
Because scanners answer slightly different questions, calling every mismatch a false positive is a fast way to ignore a real finding. Vulnerability scan false positives happen, but they're one explanation among several. CVE detection depends on what each tool can see, and five factors cause most mismatches:
Scan timing. A scan captures one moment. Patch a device after Scanner A runs, and A keeps reporting the old state until its next pass.
Access. Authenticated scans inspect systems from the inside, while unauthenticated scans see only what's exposed. PDQ's guide to types of vulnerability scans covers the differences.
Detection method. One tool infers exposure from installed-software records. Another inspects files, registry entries, or services. PDQ, for instance, detects vulnerabilities in sources including processes, registry applications, drivers, and services.
Vulnerability data. Scanners use different feeds and product mappings. Microsoft Defender Vulnerability Management doesn't support software without a Common Platform Enumeration (CPE) entry, and NIST now prioritizes which CVEs it enriches, so some records carry thinner data.
Components examined. One scanner checks an application's version. Another checks what's inside its install folder.
A mismatch can be a false positive, a false negative, or two accurate answers to different questions.
What evidence should you compare?
Reduce both findings to the same facts. When you read vulnerability scan reports side by side, pull these fields from each tool:
Endpoint (confirm it's the same device, not a duplicate record)
Application or component
File path or registry location
Detected version
Scan timestamp
Vendor advisory and affected-version range
Example: Scanner A reports a desktop app as fully updated and lists no CVE. Scanner B flags the same endpoint for an older library file in the install folder. Both can be right. A checked the application's version, while B found a bundled component the update left behind. Sophos ran into this during Log4Shell, cautioning that its file query would miss Log4j bundled inside other JAR files. The real questions: does the advisory list that component, and does anything load the old file?
Severity is a separate argument. If both tools find the CVE but rate it differently, you're comparing scores, not findings. CVSS scores can come from National Vulnerability Database (NVD) analysts, CVE Numbering Authorities, or other sources, and v3.1 and v4.0 use different metrics. Check the source and vector prefix before you call it a conflict.
How do you resolve the disagreement?
Work through four steps:
Confirm the evidence. Check the path, version, and timestamp on the endpoint. Does the file exist, and does anything use it?
Check the vendor's affected-version guidance. Does the advisory cover this component, version, and platform? The vendor's word beats either scanner's summary.
Remediate where the evidence holds. Update or remove the vulnerable component, testing first.
Rescan and compare. Run both tools again.
If you can't settle it, don't quietly close the finding. Mark it as “needs investigation,” with the evidence, an owner, and a review date. If a scanner still looks wrong, send its vendor the path, version, and timestamp, and ask how it detects the issue. Some make that easy: Microsoft's portal offers a Report inaccuracy option on software pages.
How does PDQ help validate a CVE finding?
PDQ helps you validate a CVE finding by showing affected devices and vulnerable software, with inventory details you can compare against the vendor’s advisory. This helps bridge the gap between detection and remediation. Vulnerability details include a description, references, remediation steps where available, and impacted devices. A device's Vulnerabilities tab lists its vulnerable software, and software inventory shows what's installed, so you can compare versions against the advisory.
Once a finding checks out, deploy a package to impacted devices (PDQ recommends testing suggested remediations first). PDQ then rescans affected devices so you can confirm the fix.
Don't treat PDQ as the tiebreaker, though. If it disagrees with another scanner, run the same comparison. Its risk score also blends CVSS with business impact and exploitability, so it ranks urgency.
Final thoughts
Two scanners disagreeing isn't a crisis. It's a prompt to check the evidence. Compare the facts, check the vendor's advisory, fix what's real, and document what isn't settled.
Try PDQ free for 14 days to get vulnerability details, targeted remediation, and rescans in one place.
