The CVE Is Public. Why Hasn’t Your Scanner Found It Yet?

A critical vulnerability makes the news. Your team checks the scanner. No findings. Someone asks the inevitable question: "Are we affected?"

The empty report cannot answer that question on its own. Perhaps your systems are patched. Perhaps the affected software is absent. Perhaps the scanner has identified the product but cannot determine its version. Or perhaps the vulnerability is public, but the matching data or detection logic has not reached your tool.

These situations can look identical on a dashboard. They require very different responses. To understand the result, you need to understand the path from disclosure to detection.

A published vulnerability is only the beginning

A vulnerability advisory can be useful to a person before it becomes usable by a scanner.

An engineer can read a vendor's explanation, recognize the affected component, and investigate. Automated detection needs a more explicit connection between the advisory and the software running on a particular asset.

For a typical network-based, version-driven finding, the scanner needs to establish several things:

• The service is reachable.
• The product has been identified correctly.
• Its version is known with sufficient confidence.
• The vulnerability data describes the affected versions in a usable form.
• The installed build falls within those conditions.

Each step has its own failure modes.

A reverse proxy may obscure the backend. A response header may omit the version. Product naming may differ between the fingerprint and the vulnerability database. A distribution package may contain a fix that its upstream version number does not reveal.

The CVE identifier gives everyone a common reference. It does not complete this chain.

NVD provides machine-readable applicability information using CPE identifiers and configuration statements that describe affected products, versions, and combinations. Those conditions describe which products, versions, and combinations of software are considered affected. Their purpose is to help tools make the connection automatically. NVD's documentation explains how these configurations work.

If your scanner depends on that information, a public advisory and a detectable vulnerability are separate milestones.

"Updated feed" does not mean "ready to detect"

When a scanner misses a newly disclosed vulnerability, the first question is often whether its feed has updated.

That matters. But several different updates may be involved: the CVE record, affected-version conditions, distribution advisories, product fingerprints, and an active detection test.

A tool might have the CVE description while still lacking the information required to match it to your assets. It might have a working test that your scan profile does not run. It might know the affected versions but lack a reliable version for the target.

Not every scanner relies on NVD applicability data. Some use dedicated vulnerability tests, vendor advisories, authenticated package checks, or proprietary detection logic. These mechanisms have different update cycles and evidence requirements. A CVE may therefore be detectable by one method while remaining invisible to another.

Greenbone's documented CVE scanner provides a concrete example. It compares CPE information collected during an earlier scan with current vulnerability data. The documentation states that this mode requires the relevant CPE assignment in NVD and describes its results as predictions that can be verified through a vulnerability scan. It also identifies backported fixes as a source of false positives. These limitations concern that particular scanning mode, rather than every check the platform can perform. See Greenbone's CVE scan documentation.

A useful question for any vendor is therefore: What evidence does this detection require, and which of those inputs do we currently have?

The answer is more informative than the timestamp of the last feed update.

PHP2Shell shows why the package matters

The PHP2Shell disclosure offers a practical example of how quickly a simple question becomes an inventory problem.

On October 21, 2026, PHP released fixes for CVE-2026–109618 and CVE-2026–109619, two critical vulnerabilities that could allow unauthenticated remote code execution. The upstream fixed releases were PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP's advisory also directed Linux users to their distribution or LTS vendor for updated packages. PHP's official security advisory contains the release details.

Now consider two servers that expose the same upstream PHP version. One runs an unpatched build. The other runs a distribution package containing a backported security fix. An external observer who sees only the upstream version may be unable to distinguish them.

Ubuntu explicitly documents this problem: security fixes are commonly applied to existing package versions, and scanners that fail to examine the actual package version can produce false positives. Ubuntu's security FAQ explains the distinction.

The decision therefore depends on more than a header. You need the distribution release, package origin, full package version, and the corresponding security advisory.

A version string is evidence. Its meaning depends on how the software was packaged and maintained.

An unknown version is a gap to resolve

Sometimes the scanner can identify PHP but cannot determine its version.

A site may expose a recognizable cookie or another technology fingerprint while withholding the runtime version. That leaves the scanner with partial evidence: the product is likely present, but its patch state remains unknown.

The operational response should preserve that uncertainty. "No version detected" should lead to an inventory check, a package inspection, a hosting-provider inquiry, or an appropriate active test. It should not silently become "unaffected."

The same discipline applies when a version is visible. A header might come from a proxy, a different backend, or an outdated configuration. External observations are valuable because they show what is exposed, but some questions require access to the system itself.

A useful assessment can distinguish at least four states:

• Affected: The installed build is affected, or an appropriate check confirms vulnerable behavior
• Fixed: Package or runtime evidence establishes that the relevant fix is present
• Potentially affected: Product and version evidence indicate exposure, with important conditions still unresolved
• Unknown: There is insufficient evidence to decide

Unknown assets need an owner and a next action. Leaving them outside the finding count does not resolve them.

This is where external attack surface monitoring tools such as SeguriScan fit into the process: helping teams identify internet-facing assets and investigate potential exposure. When an external observation leaves the patch state unresolved, the next step is to connect it with package-level evidence from the system owner.

Severity and confidence need separate treatment

A critical severity rating describes the consequences and characteristics of a vulnerability. It does not establish that a particular server contains it.

FIRST makes this distinction explicit: the CVSS Base score measures vulnerability severity and should not be used alone to assess risk. The CVSS v4.0 user guide explains the intended use of the score.

Detection confidence adds another question: how strong is the evidence behind this finding?

Compare a critical finding inferred from a response header with one supported by an authenticated package inspection. Both may refer to the same CVE. The evidence is different.

A useful report should let the reader trace the conclusion:

• What product or package was observed?
• Where did the version come from?
• Which advisory or matching condition was applied?
• Were distribution fixes considered?
• Did a test confirm vulnerable behavior?
• What remains unresolved?

That detail determines the next action. Strong package evidence may justify immediate remediation. A header-based match may require a quick verification first. An unreachable target may require fixing scan coverage before anyone can assess its security.

An unsuccessful test needs an explanation

An active check can sometimes provide stronger evidence than a version comparison. Its result still depends on the test reaching the relevant component and receiving an interpretable response.

A proxy might intercept the request. Authentication might block the path. A timeout might prevent a conclusion. The application might suppress the response the test relies on.

In those circumstances, "the test did not confirm the vulnerability" is an accurate statement. Whether it also supports "the system is unaffected" depends on the test's design and coverage.

For operational purposes, it helps to distinguish confirmed vulnerability, a result supporting remediation, and an inconclusive test.

Otherwise, uncertainty disappears into a reassuring status while the underlying question remains open.

What to do while detection catches up

When a critical advisory arrives, begin with the affected product and the assets you operate.

Read the vendor advisory to establish the affected branches, relevant conditions, available fixes, and any temporary measures. Then identify where that software runs: virtual machines, containers, managed services, appliances, and less visible internal deployments.

For distribution packages, compare the full installed package version with the distribution's advisory. For containers, establish which image is deployed and whether the running workload has been replaced with the corrected build.

At the same time, ask what the scanner can currently establish. Does it have a matching rule? An active test? Recent inventory? A successful authenticated scan? Which assets remain unknown?

Record those gaps alongside confirmed findings. Give each one an owner, a verification method, and a deadline.

After remediation, verify the running service. Installing a corrected package is one step; the process serving requests must also be using the corrected code. Retain the evidence that allowed the finding to be closed.

Your scanner remains central to this work. It helps discover assets, correlate evidence, identify exposure, and repeat checks across an environment. Its results become more useful when the team understands how each conclusion was reached.

The next time a critical CVE appears and the report stays empty, ask:

What did we actually establish about our systems — and what do we still need to find out?