NGINX Patches Five Bugs, Including Possible RCE and a TLS Flaw That Can Skip Client-Cert Checks

NGINX shipped versions 1.30.6 (stable) and 1.31.7 (mainline) on October 14, closing five vulnerabilities. One of them had been present in every release since May 2005.

Three of the five are memory bugs in a worker process. F5, the company behind NGINX, says they could crash the process or, in specific setups, let an attacker run code. NGINX rates all five medium, yet F5's CVSS v4.0 scores are harsher: 9.2 (Critical) for each of the three memory bugs, 8.3 for the TLS flaw, and 6.9 for the HTTP/3 one. None of the five appears in CISA's Known Exploited Vulnerabilities catalog, and neither NGINX nor F5 reports any attacks.

What it takes to exploit

Each bug needs a specific directive: alias paired with a rewrite, a regex map, aio together with SSI, a shared TLS session cache, or HTTP/3. Awkwardly, NGINX's own documentation recommends several of these, and request buffering for HTTP/3 is on by default.

TLS: a third key from uninitialized memory

The most curious flaw (CVE-2026-97629) lives in the automatic rotation of session-ticket keys. Since version 1.23.2 (October 2022), a shared session cache makes NGINX generate and rotate three key slots itself unless keys are loaded from a file. Each worker keeps a copy of all three slots, but rotation copied only two — the third held whatever was in memory before. A ticket naming that slot could be verified and decrypted with the uninitialized material, allowing a forged session. F5 stresses the forgery is "non-deterministic and beyond the attacker's control," but in theory it bypasses client-certificate verification. The exposed setting, ssl_session_cache shared:SSL:10m, is the one the documentation uses as its example.

One flaw traces to July

The map bug (CVE-2026-93479) sits in string-handling code patched on July 15 for a different vulnerability. The July fix guarded against a buffer overrun, but data could still spill into a reserved area, and a later patch sized the final string from that spilled length. Back in July, researcher Stan Shaw warned The Hacker News that switching to named captures left a narrower path open and that upgrading was "the only complete fix."

The HTTP/3 flaw (CVE-2026-95101) came from one parser field doing two jobs: holding the remaining length of an unknown frame being skipped, and the number of DATA bytes to forward as body. When the frame was split across two reads, the leftover count was sent to the backend outside the client_max_body_size check.

What to do

Upgrade to 1.30.6 or 1.31.7; fixes land only on those two branches, so older ones such as 1.28 stay vulnerable. Run nginx -T to see which options are enabled. This is NGINX's eighth security release of 2026 — and the rewrite-module overflow patched in May was, per VulnCheck, exploited within days of disclosure.

Source: The Hacker News