NGINX 1.30.6 and 1.31.7: five fixes that need configuration context

One NGINX update closes five different classes of risk, but not every deployment reaches every vulnerable path. Exposure depends on alias and rewrite directives, HTTP/3, TLS session ticket key rotation, asynchronous I/O and the way scripts and variables are evaluated.

On October 14, the project released NGINX 1.30.6 on the stable branch and 1.31.7 on mainline. The official NGINX security advisories say these releases contain fixes for CVE-2026-15176, CVE-2026-93479, CVE-2026-95101, CVE-2026-97629 and CVE-2026-97205. The NGINX release log confirms both releases.

Breachroad’s conclusion: establish which features are active first, but do not turn configuration analysis into an indefinite reason to postpone the upgrade. Exposure can appear after a template change, a new application deployment or the enablement of HTTP/3.

Five vulnerabilities, five configuration questions

CVE-2026-15176: alias, rewrite and $request_filename

A buffer overflow can occur in a specific configuration combining alias and rewrite when the result uses $request_filename. F5 advisory K000162416 describes an unauthenticated attack using a crafted request and a potential denial of service. Code execution requires additional conditions, including disabled or successfully bypassed ASLR, so RCE should not be presented as the automatic outcome for every vulnerable server.

Review configurations that combine alias and rewrite, references to $request_filename in set or return, and access-log formats that use the variable. The official affected range is 0.1.29 through 1.31.6.

CVE-2026-93479: overflow during script evaluation

The second memory flaw affects script evaluation and complex values. Its affected range is narrower: mainline 1.31.2–1.31.6 and stable 1.30.0–1.30.5. Administrators should examine not just a repository file but the final configuration produced by an ingress controller, template or configuration-management system.

CVE-2026-95101: HTTP/3 request-body injection

This issue affects HTTP/3 handling in versions 1.25.0–1.31.6. If HTTP/3/QUIC is neither enabled nor exposed by the relevant layer, the vulnerable path may not be reachable. Verify that on the running system, including edge services, rather than inferring it from a single configuration file.

CVE-2026-97629: TLS session tickets

A flaw in TLS session ticket key rotation can allow session forgery. The official affected range is 1.23.2–1.31.6. When assessing impact, inspect TLS settings on every node, key sharing and the layer that terminates encryption. NGINX behind a load balancer is not necessarily the component terminating TLS.

CVE-2026-97205: use-after-free with AIO

The use-after-free issue arises with asynchronous I/O and covers the broad range 0.8.11–1.31.6. The relevant question is not only whether aio appears in a template, but whether the active configuration and operating system exercise that path while serving files.

Where inventory should begin

Do not limit discovery to virtual machines named “nginx.” The server may be present:

• inside an application image or sidecar container;
• in a Kubernetes ingress controller;
• in a vendor appliance, API gateway or hosting control panel;
• in an old test environment that remains internet-accessible;
• as a Linux distribution package with versioning that differs from upstream.

For operating-system packages, a lower-looking version does not always mean the fix is absent. A distribution may backport the patch while retaining its base version. Use the package vendor’s advisory and changelog. Conversely, a container tagged latest does not prove the running pod pulled a new image.

Build an instance list containing the owner, package source, actual nginx -V output, active configuration and the layer that accepts user traffic.

An upgrade plan without guesswork

1. Identify the software source. For upstream, move to at least 1.30.6 or 1.31.7. For distribution packages, NGINX Plus and managed appliances, use the release specified by their vendor.
2. Export the active configuration. Include every imported file, pipeline-injected value and controller-generated result.
3. Assess reachability for all five paths. Check alias/rewrite, $request_filename, HTTP/3, TLS tickets and AIO. Document the outcome instead of assigning one status to the whole fleet.
4. Test configuration and traffic. After building the new image or package, verify syntax, routing, static files, logging, TLS and HTTP/3 in staging.
5. Roll out in stages. Watch 4xx/5xx rates, worker restarts, memory, TLS handshakes and changes in QUIC traffic.
6. Confirm the running process version. An updated file on disk is not enough if an old process or pod continues to serve traffic.

If NGINX is embedded in a closed appliance or controller, do not replace its binary with upstream yourself. That can break support and product integrity. Ask the supplier for a patch identifier, delivery date and documented mitigations.

Does this require incident response

The official notices describe vulnerabilities and fixed releases, but they do not confirm active exploitation of all five issues. Finding a vulnerable version creates a vulnerability-management task; it is not automatic proof of intrusion.

Incident triage becomes appropriate when there are unexplained worker crashes, spikes in 5xx responses, unexpected HTTP/3 request behaviour, TLS session anomalies or correlation with crafted requests. Preserve logs and diagnostic evidence before a fleet-wide restart.

Source facts and our recommendations

CVE identifiers, affected ranges, fixed releases and configuration dependencies come from official NGINX and F5 advisories. Those sources do not say that every server in the range exposes the same path or has been compromised.

The reachability matrix, staged rollout and confirmation of the running process version are Breachroad recommendations. They complement our earlier analysis of CVE-2026-42533 in map and regex processing. Teams can clarify ownership for changes like these through cybersecurity training for organisations, while web application and API penetration testing can assess the gateway and the applications behind it.