NGINX 1.30.6 (stable) and 1.31.7 (mainline) fix five vulnerabilities. For identity teams the one to look at first is CVE-2026-97629: a session ticket bug that can let a forged TLS session resume without client-certificate verification. If NGINX enforces mTLS in front of your APIs or internal apps, that check may be weaker than you think until you upgrade.
What happened
The nginx.org security advisories page lists all five issues as fixed in 1.31.7+ and 1.30.6+, and links each one to an F5 knowledge article. NGINX rates all five as medium severity. F5 scores four of them higher, according to The Hacker News, which covered the release on October 15, 2026.
CVE-2026-97629 ("Session forgery when using TLS session tickets") affects versions 1.23.2 through 1.31.6. F5 gives it a CVSS score of 8.3. The Hacker News explains the root cause: each worker process keeps three session ticket key slots, but key rotation copied only two of them. The third slot was left with uninitialized memory, so tickets that referenced it could still decrypt and produce a forged session that skips client-certificate verification. F5 describes the forgery as non-deterministic and beyond the attacker's control. Per The Hacker News, the vulnerable setup is a shared session cache (for example ssl_session_cache shared:SSL:10m) with no ssl_session_ticket_key configured. Servers with ssl_session_tickets off are not affected. PhiNode Labs is credited with the find.
The other four, as reported by The Hacker News:
- CVE-2026-15176 (CVSS 9.2): heap overflow in a worker process when a location uses
alias, arewritethat changes the URI, and references$request_filename. Affects 0.1.29 through 1.31.6. - CVE-2026-93479 (CVSS 9.2): heap overflow tied to regex
mapcaptures referenced byrootorlog_format. Affects 1.30.0–1.30.5 and 1.31.2–1.31.6, and was introduced by a July fix. - CVE-2026-97205 (CVSS 9.2): use-after-free when
aiois enabled and SSI pages useinclude virtual. Affects 0.8.11 through 1.31.6. - CVE-2026-95101 (CVSS 6.9): HTTP/3 flaw that can inject extra bytes into proxied requests and let a body exceed
client_max_body_sizewhenproxy_request_bufferingis on, which is the default. Affects 1.25.0 through 1.31.6.
The three memory bugs can crash a worker or possibly lead to code execution. None of the five was in CISA's KEV catalog as of October 15, and neither NGINX nor F5 has reported exploitation. The Hacker News notes that NGINX Plus customers and users of F5's Ingress Controller, Gateway Fabric, Instance Manager and WAF products should check F5's advisories for their own fixed versions.
Why it matters
Client certificates are often the strongest authenticator in a service-to-service path, and NGINX is often what checks them. Upstream apps behind an mTLS terminator usually trust that the proxy did the verification. A resumed session that skips the check breaks that assumption without an obvious failure. The non-deterministic behavior lowers practical risk, but also means you can't easily test your way to confidence. And a shared session cache without explicit ticket keys is a common performance setting, so many terminators may match without anyone choosing that ticket behavior.
What to check in your environment
- Inventory NGINX instances that verify client certificates: API gateways, internal app proxies, zero-trust access front ends, and Kubernetes ingress. Record each version against 1.30.6 and 1.31.7.
- On each mTLS terminator, check for
ssl_session_cache shared:...withoutssl_session_ticket_key. Treat those as exposed until upgraded. - If you can't upgrade this week, use the workarounds reported by The Hacker News: remove the shared cache, load ticket keys from a file with
ssl_session_ticket_key, or setssl_session_tickets off. - For NGINX Plus and F5 products built on NGINX, check the linked F5 articles (K000162606 for the session ticket flaw) for your fixed release instead of assuming the open source version numbers apply.
- Search configs for the conditions behind the three 9.2 bugs (
aliaswithrewriteand$request_filename, regexmapcaptures,aiowith SSI) and patch matching internet-facing servers first. - Ask owners of apps behind mTLS proxies whether the client certificate is the only control. Apps that also require a token are less exposed.