NGINX's October fixes: five CVEs, one very old bug, and the configuration questions that decide your exposure

NGINX published 1.31.7 and 1.30.6 on 14 October 2026 with fixes for five security defects. Three are memory-safety bugs rated 9.2 under CVSS v4.0, one affects TLS session tickets, and one can inject request bytes toward a backend under HTTP/3. All five share a property that makes triage harder than the version number suggests: each requires specific directives to be in use.
That property is the practical problem for anyone running NGINX as an edge proxy, a sidecar, or a Kubernetes ingress. Installing the patched version is easy. Deciding whether your particular configuration was ever reachable is a separate exercise, and it determines both the urgency of the upgrade and what to look for afterwards.

What the five defects are

CVE-2026-15176 is a heap buffer overflow. The vendor description is narrower than some secondary reporting suggests: the vulnerable path needs a location that uses alias together with rewrite and a set or return directive referencing $request_filename, or the same variable used in an access log format. The affected range runs from 0.1.29 through 1.31.6, so configurations written years ago remain in scope if they use that pairing.
CVE-2026-93479 is a heap overflow in the map directive's regular-expression capture handling, affecting 1.31.2 to 1.31.6 and 1.30.0 to 1.30.5.
CVE-2026-97205 is a use-after-free in the core module. It appears when asynchronous file I/O is enabled and a Server Side Includes page containing include virtual is processed. It affects 0.8.11 through 1.31.6 and is rated 9.2.
CVE-2026-95101 is an HTTP/3 parsing defect that can cause NGINX to add extra bytes when forwarding to a backend. It is rated 6.9 and affects 1.25.0 through 1.31.6.
CVE-2026-97629 concerns TLS session ticket key rotation. With a shared TLS session cache enabled and keys not loaded manually, session forgery becomes possible, and the advisory describes a non-deterministic risk of bypassing client certificate verification. It is rated 8.3 and affects 1.23.2 through 1.31.6.

Reading the ratings correctly

The 9.2 scores are CVSS v4.0 values, not v3.1. Comparing them against a v3.1-based internal severity scale without conversion will misrank these items against older entries in the same backlog, and the mistake is easy to make because both scales produce a number between 0 and 10.
The affected-version strings matter more than usual here, because three of the five defects have conditional trigger paths. A build that never enables SSI with AIO cannot reach CVE-2026-97205 through that path. A configuration without alias plus $request_filename does not expose CVE-2026-15176 in the way the advisory describes.
None of that makes the patch optional. Conditional exposure lowers the probability of exploitation. It does not create a supported mitigation, and it does not survive the next configuration change made by someone who has never read this advisory.

Confirming which configuration you actually run

nginx -T dumps the full expanded configuration, including every included file. That output is the only reliable way to answer the directive questions, because a repository search will miss files generated by a deployment tool or mounted from a ConfigMap.
Four questions worth answering from that dump:

  • Does any location block combine alias with $request_filename?

  • Does any map block use unnamed captures from a regular expression?

  • Are ssi and aio both enabled in the same server context?

  • Do ssl_session_cache settings rely on automatic ticket key rotation?
    For teams that cannot patch immediately, the documented workarounds map to those questions: avoid     alias with $request_filename, switch to named captures scoped to the matching block, disable AIO or SSI, and review session ticket key handling. Each workaround removes one path while leaving the vulnerable code in place, which is why they are stopgaps rather than fixes.

The TLS item deserves separate treatment

Session ticket forgery is not a memory-safety bug, and its consequences differ from the other four. If client certificates are part of your authentication model, CVE-2026-97629 sits directly on that assumption. Environments that treat mTLS as an internal trust boundary, such as service mesh control planes and administrative endpoints, should confirm that ticket keys are explicitly configured and rotated rather than left to whatever the default does.
Rotating keys after upgrading is worth the extra step. A ticket forged before the patch does not become invalid merely because the binary changed.

What to check after upgrading

Upgrade first, then look for evidence that the window was used. The useful questions are narrow enough to answer with logs you already have:

  • Are there requests whose URI would resolve differently under alias handling than under the equivalent root configuration?

  • Did any NGINX worker crash and restart in the days before patching? Both CVE-2026-15176 and CVE-2026-93479 cause worker crashes as a side effect, and a crash loop dismissed as a resource problem may have been something else.

  • For HTTP/3 deployments, do backend logs show requests with unexpected additional bytes or duplicated request lines?

  • For mTLS-fronted services, are there authenticated sessions whose client certificate details do not match your issued inventory?
    Worker crash investigation is the cheapest of these. A worker that dies and is replaced within the same second looks like normal resilience from the outside, and it is exactly the signature several of these defects produce.

References

  • F5 NGINX security advisory, 14 October 2026

  • NGINX 1.31.7 and 1.30.6 release notes

  • NVD entries for CVE-2026-15176 and CVE-2026-97205

  • The Hacker News, "NGINX Fixes 5 Flaws Including a Possible RCE", October 2026

  • InfoQ, analysis of the October 2026 NGINX release, 22 October 2026