NGINX patches five flaws, including a TLS bug that skips client-certificate checks
On October 14, 2026, NGINX released versions 1.30.6 and 1.31.7 to fix five vulnerabilities, including a TLS session-ticket key rotation bug that can let a forged session bypass client-certificate verification. Upgrade, or at minimum remove the shared TLS session cache if your server relies on client-certificate authentication.
October 14, 2026. NGINX ships versions 1.30.6 (stable) and 1.31.7 (mainline) to patch five vulnerabilities. Since May 2005. One of them, CVE-2026-15176, has been present in every release for twenty years. No exploitation. None of the five was in CISA’s KEV catalog as of October 15, and neither NGINX nor F5 reports any attack. Why it matters: one of the flaws, CVE-2026-97629, can defeat client-certificate verification — and it triggers precisely with the ssl_session_cache shared directive that NGINX’s own documentation uses as its example configuration.
The flaw that actually matters: a forged TLS ticket
Of the five, only one demands immediate attention for teams that gate a service behind client certificates — the classic mTLS API, a backend protected by mutual authentication, or an admin portal sitting behind a client-cert handshake. CVE-2026-97629 sits in the automatic rotation of TLS session ticket keys.
A session ticket lets a client resume a TLS session without a full handshake. Since version 1.23.2 (October 2022), a shared session cache — ssl_session_cache shared:SSL:10m — makes NGINX generate and rotate its own ticket keys unless you load them from a file via ssl_session_ticket_key. That exact setting is the one NGINX’s documentation uses in its example configuration.
The bug is a matter of an incomplete copy. Each worker process holds a copy of three key slots. Rotation copied only two, leaving the third slot holding whatever was previously in memory. A ticket naming that slot could then be verified and decrypted with that uninitialized key material, “allowing a forged session,” in the words of the fix commit. F5 says the forgery works “in a non-deterministic manner that is beyond the attacker’s control,” but that it can be used to bypass client-certificate verification. This is not a flaw in the TLS protocol itself: it is a residual key nobody ever wrote, yet one that is somehow enough to authenticate a ticket.
There is precedent. NGINX fixed a session-reuse flaw with the same consequence in February 2025, CVE-2025-23419. The same effect reappearing through a different path is a signal that session-key rotation is a sensitive area worth auditing first.
Three memory bugs, RCE possible under conditions
The other three flaws are memory corruptions. F5 scores them 9.2 (Critical) under CVSS v4.0, while NGINX rates them “medium” — the gap comes down to the exploit conditions, each of which requires a directive you added yourself.
CVE-2026-15176 is a heap overflow in a worker process, present since version 0.1.29 (May 2005). It triggers when a location combines alias with a rewrite that changes the URI, and anything reads $request_filename in that window — a return, set, if, add_header, or the access-log format. If the location’s prefix is longer than the rewritten URI, mapping the URI to a file path overflows a buffer.
CVE-2026-93479 is also a heap overflow, this time in the captures of a regex map. It fires when root or log_format references the map’s output variable before it is finalized. This one is the most interesting historically: it lives in the string-handling code NGINX already patched on July 15 for CVE-2026-42533, another 9.2 overflow. The July fix added protection against overrunning a buffer, but data could still spill into a reserved area, and a second July patch then sized the final string from that wrong length — so a machine patched in July is still inside the affected range. Researcher Stan Shaw warned in July that switching to named captures left a narrower path open, and that upgrading was “the only complete fix.”
CVE-2026-97205 is a use-after-free, triggered when aio is enabled with an SSI page using include virtual commands. Each pending asynchronous operation increments an 8-bit counter with no check: at 256 pending operations the counter wraps to zero, and the request can be freed while those operations still point at its memory.
The common thread: these are genuine memory corruptions, but the attacker must first achieve code execution in the worker — which makes them links in an exploit chain rather than a one-packet-to-root bug like the TLS flaw.
The fifth flaw, and which versions to track
CVE-2026-95101 concerns HTTP/3: when an unknown frame is split across two reads, the leftover byte count is treated as a request body and forwarded to the backend, bypassing the client_max_body_size limit. It is enabled by default with proxy_request_buffering on. An attacker can slip extra bytes into a proxied request. F5 rates it 6.9.
The same day, NGINX also published njs 1.0.2, fixing two medium-severity XML-handling flaws in its JavaScript module, CVE-2026-101025 and CVE-2026-101019.
The fix map is simple: the stable branch moves to 1.30.6, mainline to 1.31.7. NGINX only publishes fixes for those two branches, so older branches — 1.28, for instance — remain in the affected range, and a distribution package is only fixed if your distribution has backported the patches. NGINX Plus customers and users of F5’s Ingress Controller, Gateway Fabric, Instance Manager and WAF products should check F5’s advisories: several products had no fixed build as of October 15.
What to do, and in what order
Upgrading is the primary measure, but the order of priorities depends on your configuration. Start by identifying what your server actually enables, using nginx -T, then search for the five at-risk signatures.
nginx -T > /tmp/nginx-full.conf
# 1. TLS: shared session cache WITHOUT keys loaded from a file
grep -nE 'ssl_session_cache\s+shared' /tmp/nginx-full.conf
grep -nE 'ssl_session_ticket_key' /tmp/nginx-full.conf
# 2. alias + rewrite + reading $request_filename
grep -nE 'alias|rewrite|\$request_filename' /tmp/nginx-full.conf
# 3. aio + SSI
grep -nE '\baio\b|\bssi\b' /tmp/nginx-full.conf
# 4. HTTP/3
grep -nE 'listen.*quic' /tmp/nginx-full.confIf you cannot upgrade immediately, F5 publishes a workaround per flaw: do not use alias in the affected location; use named captures and reference them only inside the regex block; turn aio off or stop serving SSI pages; set proxy_request_buffering off; and for the TLS bug, remove the shared cache or load keys from a file with ssl_session_ticket_key. Servers with ssl_session_tickets off are not affected by CVE-2026-97629.
The priority is clear. If you use client-certificate authentication — mTLS, an internal API, an admin portal — treat the TLS bug as an emergency even without proof of exploitation: the consequence, a silent bypass of access control, is too severe to defer to the next maintenance window. Remember that the rewrite-module overflow fixed in May, CVE-2026-42945, was exploited within days of disclosure, according to VulnCheck. This is already NGINX’s eighth security release of 2026.
One practical note on the upgrade path: because NGINX only ships fixes for the stable and mainline branches, teams pinned to an older branch for stability reasons — a common choice in conservative environments — must either move to 1.30.6 or rely on their distribution to backport the patches. Check your distribution’s changelog rather than assuming the package version tells you which of these five CVEs is actually closed.
Verdict
The real workload reduces to a single question: does your configuration use ssl_session_cache shared without ssl_session_ticket_key? If it does, and you rely on client certificates, upgrade to 1.30.6 or 1.31.7 as soon as possible, or remove the shared cache in the meantime — this is the flaw that can bypass your access control without leaving an obvious network trace. If your fleet is standard — an HTTP/2 reverse proxy without SSI, without aio, without those directive combinations — the three memory bugs are theoretical risks to fix at the next cycle, not emergencies. Either way, run nginx -T and check the five signatures: the July fix for the map flaw was not enough, and a machine you consider “already patched” can still be inside the affected range.