NGINX 1.31.7 and 1.30.6 fix five CVEs that only matter when specific directives are enabled

Five fixes, five preconditions

NGINX 1.31.7 and 1.30.6 close five security defects, and every one of them is conditional: the bug only matters when a particular configuration construct is in play. That is the central observation of an analysis published on dev.to, which walks through how to turn a version-driven advisory into a configuration-driven exposure assessment.

The five identifiers are CVE-2026-15176, CVE-2026-93479, CVE-2026-97205, CVE-2026-95101 and CVE-2026-97629, addressed in releases the analysis ties to an F5 NGINX security advisory dated 14 October 2026. The conditions it names are: alias used together with $request_filename, unnamed captures inside map blocks, ssi combined with aio, session ticket key handling, and — for CVE-2026-95101 — HTTP/3 request parsing. The session ticket flaw carries the identifier CVE-2026-97629. None of these constructs is exotic, but none is universal either, which is why a version number alone says little about whether a given server is exposed.

Why a scan cannot settle it

The author tried to size the exposed population with ZoomEye, but the API returned HTTP 502 errors for the whole research window, so the article was published with no counts. The failure is almost beside the point the piece goes on to make: internet-wide scans cannot see directives at all.

Two common queries describe different groups of machines. Matching app="nginx" returns assets the engine has fingerprinted as NGINX, while matching on the Server response header catches every deployment that left the default banner in place, including appliances that embed NGINX without advertising it. Each approach is broader than the other in some respect, and neither reports whether alias, rewrite, $request_filename, ssi, aio or ssl_session_cache is in use. A tally of NGINX assets, however large, is therefore not a tally of exposure to any of the five flaws.

The check that actually works

According to the analysis, the one dependable way to settle the question is to run nginx -T on each asset, from inside the team that controls it, because it prints the assembled configuration. The workflow it recommends treats scan output as an input to a request rather than a finding: assemble a candidate list of internet-facing NGINX hosts from a scan or from internal inventory, map each host to an owning team, and ask that team a handful of targeted questions about alias with $request_filename, unnamed map captures, ssi with aio, session ticket key handling, and whether QUIC is terminated.

The scan still earns its place through completeness. Internal inventories tend to miss servers stood up by project teams and never registered, and those are precisely the machines least likely to have had their configuration reviewed.

Role shapes the risk

An NGINX instance serving static files is a different proposition from one terminating TLS in front of an authentication boundary, and the session ticket defect matters most in the second role. The analysis offers signals for telling them apart: certificates issued for internal service names indicate a component in a chain, while a default welcome page often marks either a fresh install or a forgotten test environment — the latter being a recurring category in internet-wide data, often wide open and unwatched, and more heavily represented than chance among hosts that keep default banners.

It also sets ground rules for reporting: name the exact query, the field matched, the collection date and the units being counted; keep observation ("these hosts returned an NGINX header") separate from inference ("these hosts may run an affected version"), since a banner rarely carries version evidence; and resist using the sheer size of the NGINX install base as a severity argument, because that number predates and survives any individual advisory.

Why it matters

Conditional CVEs reward operators who know their configurations. Because all five flaws require a specific directive or protocol to be active, exposure can be established — or ruled out — with a configuration review rather than a blind fleet-wide emergency upgrade. The practical path for anyone running NGINX at the edge is to move to the fixed releases, but to sequence the work by first checking for the named constructs, with particular attention on TLS-terminating and QUIC-terminating front ends, and on the unregistered test servers that internet scans keep rediscovering.