Summary
- NGINX 1.30.6 and 1.31.7 fix five security vulnerabilities disclosed on 14 October.
- The flaws affect separate modules and conditions, including alias rewrites, HTTP/3, and session tickets.
- Maintainer advisories rate the issues medium severity and do not establish a widespread exploitation campaign.
NGINX has released updated stable and mainline web-server versions addressing five security vulnerabilities spanning memory handling, HTTP/3 requests, and TLS session management.
Versions 1.30.6 and 1.31.7, released on 14 October, contain corrections for flaws that affect different combinations of configuration directives, protocol modules, and software releases. NGINX lists the issues as medium severity. Its notices do not support describing the release as an emergency response to five universally exploitable remote code execution flaws.
The first reported problem, CVE-2026-15176, concerns a buffer overflow when alias processing is combined with rewrite behaviour. Another, CVE-2026-93479, relates to the evaluation of string expressions using variables. Both affect memory handling in particular code paths rather than every ordinary static-content request.
CVE-2026-95101 involves request body injection in HTTP/3. HTTP/3 is a different transport and protocol implementation from conventional HTTP/1.1 or HTTP/2 connections, so whether a deployment enables the affected module is central to assessing exposure. A site that does not use the vulnerable feature should not be described as having the same reachable attack surface.
The fourth issue, CVE-2026-97629, concerns session forgery when TLS session ticket keys are rotated. Session tickets support resumption of secure connections, reducing the need for repeated handshakes. Correct handling of keys is essential because the mechanism can affect the trust placed in resumed sessions.
Finally, CVE-2026-97205 is a use-after-free vulnerability under conditions involving the server-side include module and asynchronous file input/output. That combination again narrows the circumstances in which the bug can be exercised. The maintainer’s version tables identify affected ranges separately for every issue.
NGINX is widely deployed as an application web server and reverse proxy. It can terminate TLS connections, serve content, route traffic to application services, and form part of a larger ingress stack. A flaw at this layer may affect several applications that share the same proxy even where the applications themselves have no corresponding vulnerability.
At the same time, deployment inventories can overstate risk when they classify every process carrying an NGINX version as exposed to each advisory. Packages built by Linux distributors, container images, vendor appliances, and managed services can have different patch backports or configuration defaults. Operators need to establish both actual code status and whether the affected behaviour is enabled.
Upgrading a reverse proxy also creates change-management considerations: configuration compatibility, TLS settings, upstream health checks, and service restarts can affect availability. A controlled deployment should preserve the intended routing and authentication model rather than treating a successful package installation as proof that the service has returned to its previous behaviour.
NGINX maintains separate fixed-version information for each defect, reflecting different histories across the stable and mainline releases. The buffer overflow associated with string expressions, for example, has a narrower affected range than the flaw involving alias rewriting. Some users may also obtain patched NGINX builds through their operating system supplier instead of installing upstream packages directly. In those cases a distribution package number can appear older than the upstream fixed release while incorporating a backported correction. A version string alone is insufficient to resolve that difference; the distributor’s changelog or vendor advisory is the more relevant evidence of patch status.
The release also follows a September correction to the HTTP/3 module for a different vulnerability. Although both disclosures involve web infrastructure, they are separate changes with different affected ranges and should not be counted together. The October package addresses the five problems listed in the new advisories, while the NGINX security index retains earlier entries for operators checking an installation that has skipped several maintenance releases.
The advisories are a bounded software-maintenance development rather than evidence of an active intrusion campaign. They identify corrected upstream branches and the vulnerable module conditions. NGINX has also released a separate njs update addressing XML parsing and validation concerns; that is not included in the five web-server vulnerabilities patched in 1.30.6 and 1.31.7.
