“One of them present in every release since May 2005.” That terse, specific fact is the headline from NGINX’s October 14 release of versions 1.30.6 and 1.31.7: five vulnerabilities fixed, three memory bugs that can crash or possibly allow code execution under particular configurations, a TLS session-ticket weakness that can let a forged session bypass client-certificate checks, and an HTTP/3 parser issue that can leak extra request bytes to backends.
What NGINX and F5 released on October 14
NGINX published stable 1.30.6 and mainline 1.31.7 on October 14 to fix five flaws. F5 — the company behind NGINX — characterizes three of the defects as memory issues that could crash a worker process or “possibly let an attacker run code,” each requiring a specific configuration to exploit. The TLS session-ticket problem can allow a forged session that may bypass client-certificate verification; F5 calls that forgery “non-deterministic and beyond the attacker’s control.” The HTTP/3 bug permits an HTTP/3 client to slip extra bytes into a request that NGINX forwards to a backend.
None of the five was listed in CISA’s Known Exploited Vulnerabilities catalog as of October 15, and neither NGINX nor F5 reported active exploitation. NGINX rates all five as medium severity; F5 scores the three memory bugs 9.2 (Critical) on CVSS v4.0, the TLS flaw 8.3, and the HTTP/3 flaw 6.9. NGINX also released njs 1.0.2 that day, fixing two medium XML-handling flaws (CVE-2026-101025 and CVE-2026-101019).
Which configurations expose servers
Each flaw depends on a configuration choice. The affected combinations are:
- an alias together with a rewrite
- a regex map
- AIO (asynchronous I/O) used together with SSI
- a shared TLS session cache (ssl_session_cache shared:SSL:10m) without loading ssl_session_ticket_key from file
- HTTP/3 (QUIC) enabled
NGINX’s documentation uses the shared session cache in its example configuration and recommends session caching and request buffering; the condition for the HTTP/3 flaw is on by default. To see whether a running server enables these paths, NGINX advises printing the running configuration with nginx -T and searching for:
- alias beside a rewrite
- a regex map used by root or log_format
- aio together with ssi
- listen lines with quic
- ssl_session_cache shared without ssl_session_ticket_key
NGINX publishes fixes only for the two active branches; operators should note that older branches such as 1.28 remain inside the affected ranges unless a distribution has backported patches. NGINX recommends upgrading to 1.30.6 (stable) or 1.31.7 (mainline). NGINX Plus customers and users of F5’s Ingress Controller, Gateway Fabric, Instance Manager and WAF products should consult F5 advisories — F5 lists affected builds and, for several products, had no fixed build as of October 15.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogThe TLS session-ticket key rotation issue
The TLS flaw lies in automatic rotation of session ticket keys after NGINX began generating and rotating keys itself when a shared session cache is configured (behavior introduced in version 1.23.2, October 2022). Each worker process keeps three key slots; rotation logic copied only two slots, leaving the third with whatever uninitialized memory was present. A session ticket that names that third slot could be verified and decrypted using that uninitialized key material, “allowing a forged session,” the fix commit says.
F5 notes the forgery operates in a non-deterministic way “beyond the attacker’s control” and that an attacker could use it to bypass verification of client certificates. The exposed example setting is ssl_session_cache shared:SSL:10m, which appears in NGINX documentation. NGINX previously fixed a session-reuse flaw with the same consequence (CVE-2025-23419) in February 2025.
Memory and parser defects: map, alias, AIO, and HTTP/3
The regex map bug, CVE-2026-93479, traces to a July change that patched a different heap overflow (CVE-2026-42533). The July sequence of fixes introduced an unintended new overflow path: an initial patch prevented one buffer overrun but allowed data to spill into a reserved area; a subsequent patch sized the final string from that spilled length, enabling the string to outgrow its buffer. The commit now imposes limits: the overflow is at most the size of the reserved area on the document-root path, and a single null byte on the access-log path. F5 and NGINX list 1.30.0 and 1.31.2 as the earliest affected versions.
Researcher Stan Shaw told The Hacker News in July that switching to named captures left a narrower path open and that upgrading was “the only complete fix.”
F5’s commits describe the alias flaw as a narrow timing window: after a rewrite changes a request’s URI and before NGINX selects the next location, any reader of $request_filename can overflow a buffer when the chosen location’s prefix is longer than the rewritten URI. The AIO bug is a counter overflow: each pending asynchronous operation adds one to an 8‑bit field with no bounds check, so 256 pending operations wrap it to zero and a request may be freed while operations still reference its memory; SSI pages using include virtual can trigger parallel included requests. The HTTP/3 defect arose because one parser field tracked both the remaining length of an unknown frame being skipped and the number of DATA bytes to pass as a request body; when an unknown frame split across reads, leftover bytes could be treated as body and forwarded to the backend outside client_max_body_size checks.
Who found the flaws and the current exploit picture
F5 credits the discoverers: Matt Suiche of Tolmo and Mateusz Gierblinski for the map flaw, Hansol Lee of GOTROOT for the HTTP/3 flaw, PhiNode Labs for the TLS flaw, and a researcher named Cyberlanc3r for the AIO flaw; F5 found the alias flaw itself. This is NGINX’s eighth security release of 2026. The rewrite-module overflow patched in May (CVE-2026-42945) was observed being exploited within days of disclosure, VulnCheck found — a reminder in context even as F5 and NGINX report no active exploitation of these five issues as of October 15.
Operators should prioritize inventorying the specific configuration paths named above and plan upgrades to 1.30.6 or 1.31.7; where upgrades are not immediately possible, F5’s advisory lists workarounds per flaw. For NGINX Plus and affected F5 product users, check F5 advisories for build-level status. The combination of long-standing code paths, documented example settings, and narrowly scoped triggers makes these fixes both urgent and tractable: the next step for every administrator is to confirm whether those exact directives and modules are enabled in your running configuration and to apply the provided fixes or mitigations without delay.
