NGINX 1.30.6: 5 Security Fixes You Need to Patch (2026)

On October 14, 2026, NGINX shipped security releases 1.30.6 (stable) and 1.31.7 (mainline) fixing five vulnerabilities — NGINX’s eighth security release of the year. Three of them are memory-safety bugs that F5 scores 9.2 Critical (CVSS v4.0); NGINX itself labels all five “medium”. If you run NGINX on a VPS, you need to know which of the five can actually reach you — because each one needs a specific configuration to trigger, and a 30-second config audit tells you whether to patch this afternoon or this week. This guide walks you through all five flaws, the audit, and the safe upgrade path on Ubuntu.

Table of Contents

What the NGINX 1.30.6 security update fixes

Here is the whole release in one view. F5 (NGINX’s owner) scored three of these; NGINX’s own advisory labels every one “medium” — the mismatch is explained below.

1. CVE-2026-15176 — buffer overflow with alias + rewrite (F5: 9.2 Critical)

A location block that combines alias with a rewrite that changes the URI, plus anything that reads the internal $request_filename variable (return, set, if, add_header, or an access-log format), can overflow a buffer. It affects every release from 0.1.29 through 1.31.6 — The Hacker News notes the bug is “present in every release since May 2005”, which makes it one of the longest-lived flaws NGINX has ever shipped. Found internally by F5.

2. CVE-2026-93479 — buffer overflow in script evaluation (F5: 9.2 Critical)

A regex map whose captures are referenced by root or log_format before the map’s output variable is used can overflow a buffer. Non-cacheable variables in string expressions are implicated too. Reported by Matt Suiche (Tolmo) and Mateusz Gierblinski. A related map/regex overflow landed three months earlier in July (CVE-2026-42533, which NGINX rated “major”) — this is a distinct advisory, but it is the second map/regex memory bug this year, so configurations leaning on clever map gymnastics deserve a look.

3. CVE-2026-97205 — use-after-free with AIO + SSI (F5: 9.2 Critical)

With asynchronous file I/O (aio) enabled, an SSI page using include virtual commands can trigger a use-after-free. Affects 0.8.11 through 1.31.6. Reported by Cyberlanc3r. Note: July had a different SSI use-after-free (CVE-2026-56434) — SSI is having a rough year.

4. CVE-2026-97629 — TLS session forgery with ssl_session_cache (F5: 8.3)

If you set ssl_session_cache shared:… without ssl_session_ticket_key, an attacker can forge a TLS session — and a forged session can bypass client-certificate checks. F5 stresses the forgery is non-deterministic and beyond the attacker’s control, but it is still the flaw most likely to bite ordinary servers, because the trigger is NGINX’s own documented example configuration: the ngx_http_ssl_module docs literally show ssl_session_cache shared:SSL:10m; and recommend “enable the shared session cache”. Setting ssl_session_tickets off means you are not affected. Reported by PhiNode Labs.

5. CVE-2026-95101 — request body injection in HTTP/3 (F5: 6.9)

On HTTP/3 with proxy_request_buffering on (the default), split unknown frames across reads could leave leftover length bytes that NGINX treated as request body — slipping extra bytes past client_max_body_size. Affects 1.25.0 through 1.31.6. Reported by Hansol Lee (GOTROOT).

Bonus: njs 1.0.2 fixes two XML flaws

Shipped the same day: CVE-2026-101025 (memory exhaustion parsing malformed XML) and CVE-2026-101019 (inconsistent XML attribute values that can affect signed-XML validation). Both are reported as medium severity in press coverage; upgrade njs to 1.0.2 while you are at it.

Why “medium” and “9.2 Critical” at the same time

This confuses everyone, so let’s settle it: they measure different things. A CVSS v4.0 score of 9.2 describes the worst-case technical impact assuming the bug is reachable: network-reachable, no authentication, high confidentiality/integrity/availability impact — the score for CVE-2026-15176 assumes the stars align. NGINX’s “medium” label is the vendor’s own triage judgement, discounted for exploitation prerequisites: every flaw needs a specific configuration, some conditions are beyond the attacker’s control, and real-world code execution would typically need ASLR to be disabled or bypassed. On a normal host, the realistic outcome of a successful attack is a worker-process crash — NGINX workers restart automatically, so that is a blip, not an outage.

One thing “medium” does not mean: that NGINX never rates things higher. It rated July’s CVE-2026-42533 “major” — so the medium rating here is a deliberate down-rating, not house style. Take the CVSS scores as the technical ceiling, take NGINX’s label as triage guidance, and use the audit below to decide your own urgency.

The 60-second audit: is your server affected?

First, check which NGINX you are actually running:

nginx -v

If you see 1.30.6 or 1.31.7 already, you are done — you patched, or your distro backported the fixes. Anything in the affected ranges (roughly: any 1.30.x below 1.30.6, any 1.31.x below 1.31.7) needs the patch. Important caveat: NGINX published fixes for the 1.30 and 1.31 branches only. Older branches like 1.28 get no official fix — a distro package is safe only if the distro backported the patches, so check your distro’s changelog, not just the NGINX version number.

Next, dump your effective configuration and hunt for the five triggers:

nginx -T 2>&1 | less

nginx -T tests the config and prints the entire effective configuration, includes and all — it is the single most useful command for this audit. Search the output for each trigger:

CVE-2026-15176: a location block containing alias and a rewrite that changes the URI, combined with anything reading $request_filename (return, set, if, add_header, or your log format). Note that alias beside rewrite is a combination config-lint tools already flag as suspicious.
CVE-2026-93479: a regex map whose captures are referenced by root or log_format before the map’s own output variable.
CVE-2026-97205: aio enabled together with SSI pages using include virtual.
CVE-2026-97629: ssl_session_cache shared:… anywhere without ssl_session_ticket_key. Remember: this is NGINX’s own documented example config, so check even if you “just followed the docs”.
CVE-2026-95101: any listen line with quic (HTTP/3) in front of a proxy.

Quick one-liner to start the hunt:

nginx -T 2>&1 | grep -E -n "alias|rewrite|ssl_session_cache|ssl_session_ticket_key|quic|aio|include virtual"

If none of the triggers match, your urgency drops: patch on your normal cadence. If any match — especially ssl_session_cache shared without ticket keys, or alias beside rewrite — patch today.

Upgrading to NGINX 1.30.6 on Ubuntu

Ubuntu’s own repositories ship an older NGINX, so for the official packages you want NGINX’s own repo. These commands come straight from the official NGINX Linux-packages documentation:

sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
  | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
  https://nginx.org/packages/ubuntu `lsb_release -cs` nginx" \
  | sudo tee /etc/apt/sources.list.d/nginx.list
# mainline alternative: https://nginx.org/packages/mainline/ubuntu
sudo apt update && sudo apt install nginx

The official docs also recommend pinning the repo so NGINX.org packages take priority over distro ones (/etc/apt/preferences.d/99nginx, Pin-Priority 900) — otherwise a routine apt upgrade can pull you back to the distro’s older build.

If you prefer containers, the official Docker image already tags 1.30.6-alpine:

docker pull nginx:1.30.6-alpine

NGINX Plus users should target 37.0.5.1 (for the 37.0 line) or 37.1.0.1.

After upgrading, verify before you reload traffic:

nginx -v        # should show 1.30.6 (or 1.31.7 on mainline)
nginx -t        # syntax check — never skip this
sudo nginx -s reload

A reload swaps the worker processes with zero downtime — no need to restart the service.

If you can’t patch today

There is exactly one clean workaround in this set: for CVE-2026-97629, ssl_session_tickets off in your server blocks means you are not affected — session tickets are disabled entirely, so there is nothing to forge. The other four flaws have no documented vendor workaround; the only fix is the patch. If you are pinned to an older branch (1.28 and below have no official fix), check whether your distro backported the patches; if not, consider moving to the official NGINX repo so you are not waiting on a downstream timeline.

Don’t sit on this: the May precedent

As of October 15–16 press coverage, none of the five October CVEs is in the CISA KEV catalog, and no public proof-of-concept or in-the-wild exploitation has been reported (I could not inspect the live KEV catalog directly, so treat that as “no reported activity yet”, not a guarantee). Here is why “yet” matters: May’s NGINX rewrite-module overflow (CVE-2026-42945) was being exploited within days of disclosure — VulnCheck tied that to roughly 5.7 million exposed servers. Security releases for a web server that serves a third of the internet compress the window between disclosure and automated scanning very fast. The audit above takes a minute; the patch takes five.

NGINX 1.30.6 Security Update: Patch the 5 Flaws That Can Reach Your Server (2026)