Five NGINX CVEs are conditional. Here is how to measure the conditions, not just the version

NGINX 1.31.7 and 1.30.6 fix five defects, and every one of them requires a particular directive to be active. For an exposure assessment, that is a gift: the vulnerable population is defined by configuration, and configuration questions can be answered more precisely than version questions.
ZoomEye queries for this article did not run to completion. The API returned HTTP 502 for the duration of the research window, so no counts appear below. The query designs and their limits are reproducible, and the reasoning stands independently of whether a particular day's scan succeeds.

What a scan can and cannot see about NGINX

app="nginx" returns assets ZoomEye has fingerprinted as running NGINX. http.header.server="nginx" returns assets whose Server response header contains that value. These are different populations, and the difference is instructive.
Header matching finds every deployment that left the default banner in place, including reverse proxies, ingress controllers, and appliances that embed NGINX internally and never advertise it as the product. Fingerprint matching is broader in some respects and narrower in others: it can identify NGINX where the banner is stripped, and it can miss deployments where the fingerprinting engine is unsure.
Neither field reports which directives are enabled. alias, rewrite, $request_filename, ssi, aio and ssl_session_cache are configuration constructs. They do not appear in a scan response. A count of NGINX assets, however large, is therefore not a count of CVE-2026-15176 exposure.

Starting queries and what each one describes

app="nginx"
http.header.server="nginx"
http.header.server="nginx" && port=443

The third query is the most useful starting point for a TLS-terminating edge deployment, because it restricts to the role where the conditions tend to cluster. The second query's overlap with the first describes how much of the population retains default banners, which correlates loosely with how much of it is managed by generic deployment tooling rather than by a team that customises its configuration.
A fourth query is worth running where HTTP/3 is in use:

app="nginx" && service="http"

combined with port evidence for 443/UDP where the field supports it. CVE-2026-95101 concerns HTTP/3 request parsing, so the relevant population is deployments that terminate QUIC, which is a smaller and more specific set than the general NGINX estate.

The step that actually answers the exposure question

A scan can produce a candidate list. Answering whether those candidates are exposed requires reading configuration, and the only reliable mechanism is nginx -T on each asset, executed by whoever controls it.
That makes the scan output an input to a request rather than a finding report. The workflow that works: pull the candidate list of internet-facing NGINX assets from ZoomEye or from internal inventory, map each to an owning team, and ask each team for four specific answers about alias with $request_filename, unnamed map captures, ssi combined with aio, and session ticket key handling.
The value of the scan in that workflow is completeness. Internal inventory tends to miss assets stood up by a project team that never registered them, and those are exactly the assets least likely to have had their configuration reviewed.

Distinguishing the roles that matter

An NGINX instance serving static assets has a different risk profile from an NGINX instance that terminates TLS in front of an authentication boundary or fronts an mTLS-protected control plane. CVE-2026-97629, the session ticket defect, matters most in the second role.
Fields that help separate roles include the certificate content and the response body. A deployment using a certificate issued for an internal service name is likely a component in a chain. A deployment returning a default welcome page is likely a fresh install that may not be doing anything important, and may also be a forgotten test environment with a wide-open configuration.
The second case is worth its own pass. Forgotten test instances of a web server, left with permissive configurations and no monitoring, are a recurring finding in internet-wide data, and they are disproportionately represented in the population that retains default banners.

Reporting that survives scrutiny

State the query, the field, the collection date and the units. A count of app="nginx" assets is a count of fingerprinted assets, not a count of servers, websites or vulnerable deployments.
Separate observation from inference explicitly. "These assets returned an NGINX header" is observation. "These assets may run a version affected by CVE-2026-15176" is inference requiring version evidence that a banner rarely provides.
Avoid the temptation to use the size of the NGINX population as a severity argument. It is large, it has been large for a decade, and the number does not change with any individual advisory.

References

• F5 NGINX security advisory, 14 October 2026, for CVE-2026-15176, CVE-2026-93479, CVE-2026-97205, CVE-2026-95101 and CVE-2026-97629
• NGINX 1.31.7 and 1.30.6 release notes
• ZoomEye official MCP search syntax reference for app, http.header.server, port and service