nginx 1.30.6: five CVEs, two severity ratings

The same five nginx bugs are rated medium by the nginx project and, according to reporting on F5's advisories, up to 9.2 critical by F5 — the company that owns nginx. If you are planning a patch window off nginx 1.30.6, you have to pick which of those two numbers to brief your change board with, and the advisory page gives you no help at all: it carries no CVSS scores, no release dates and no workarounds.

There is also a version trap. The advisories say the fix is in 1.31.7 on mainline. The download page now ships 1.31.8.

What nginx 1.30.6 and 1.31.7 actually fix

Straight from nginx's own advisories page, every one of the five entries reads "Severity: medium" and "Not vulnerable: 1.31.7+, 1.30.6+". The affected ranges are where the interest is, because they are wildly uneven:

CVE	nginx's title	Vulnerable range
CVE-2026-15176	Buffer overflow when using alias with rewrite	0.1.29–1.31.6
CVE-2026-97205	Use-after-free when using asynchronous file I/O (AIO)	0.8.11–1.31.6
CVE-2026-95101	Request body injection in HTTP/3	1.25.0–1.31.6
CVE-2026-97629	Session forgery when using TLS session tickets	1.23.2–1.31.6
CVE-2026-93479	Buffer overflow in script evaluation	1.31.2–1.31.6, 1.30.0–1.30.5

Note the last row. Every other bug sweeps back years — the alias one all the way to 0.1.29 — while CVE-2026-93479 exists only in a narrow band. Reporting on the release ties that narrow band to July's CVE-2026-42533 fix, implying a regression. nginx's own changelog does not support it: the 1.30.6 entry describes CVE-2026-93479 as a buffer overflow “while evaluating string expressions with variables” without mentioning map or regex, it credits a different researcher, and the range starts at 1.30.0 — which shipped in April, three months before the July fix landed in 1.30.4. We cover that discrepancy separately.

Two things the page does not contain, which matter if you are used to reading vendor advisories: there are no dates on any entry, and there is no mitigation or workaround text for any of the five. The njs flaws reported alongside this release do not appear on that page at all.

Why the severity depends on who you ask

nginx rates all five medium. Reporting on F5's advisories puts the three memory-corruption bugs at 9.2 and Critical on CVSS v4.0, the TLS session flaw at 8.3, and the HTTP/3 flaw at 6.9.

We could not read F5's advisory articles directly — they render as an empty application shell to anything without a browser session — so treat those figures as reported rather than quoted from the vendor, and verify them in your own F5 portal if that distinction matters to your process. The gap itself is not in doubt, though: medium to the project, critical to the vendor, for identical code.

Which should you use? Neither on its own. A CVSS score describes a bug's theoretical worst case, not your exposure, and this release is a clean illustration of why a CVSS 9.8 can sometimes wait while a medium cannot. None of the five was in CISA's Known Exploited Vulnerabilities catalogue as of 15 October, and neither nginx nor F5 reported attacks. Against that, nginx's May 2026 rewrite-module bug, CVE-2026-42945, was reportedly exploited within days of disclosure — so "medium, no known exploitation" has a poor track record here as a reason to wait a month.

The mainline version the advisory does not name

This is the practical catch. The advisories page says "Not vulnerable: 1.31.7+", and 1.31.7 shipped on 14 October. But nginx's download page now lists mainline as nginx-1.31.8, released a week later on 21 October with bug fixes rather than CVEs.

So a team following the advisory literally pins 1.31.7 and lands a release behind on day one. On mainline, go to 1.31.8. On stable, 1.30.6 is current and correct.

The download page also quietly answers a question it never addresses directly. It lists 1.28.3, 1.26.3, 1.24.0 and older under "Legacy versions" with no support statement anywhere on the page — and since the advisories only ever mark 1.31.7+ and 1.30.6+ as not vulnerable, every legacy branch stays inside all five affected ranges permanently. If you are on 1.28, there is no patch coming; there is a branch migration.

How to work out whether any of this touches you

Version alone will not tell you, because four of the five need a specific configuration to be reachable. Dump the effective config, including every included file, and search it:

nginx -T > /tmp/effective.conf
grep -nE 'alias|\$request_filename|ssl_session_cache|ssl_session_tickets|aio |ssi |http3|proxy_request_buffering' /tmp/effective.conf

Then map what you find: alias alongside rewrite for CVE-2026-15176, a regex map whose captures feed root or log_format for CVE-2026-93479, aio with SSI for CVE-2026-97205, HTTP/3 with proxy_request_buffering left at its default for CVE-2026-95101, and a shared ssl_session_cache with tickets enabled for CVE-2026-97629.

Per-CVE workarounds do exist in F5's articles, as described in the reporting above, and they are the usual shape: stop using the directive. Treat them as a bridge to a window, not a destination — the same conclusion a researcher quoted in that coverage reached about July's fix, calling upgrading "the only complete fix".

What we would do

Upgrade, and do not spend the week arguing about 9.2 versus medium. This is nginx's eighth security release of 2026 according to that coverage, which tells you the cadence to plan for: a reverse proxy you can upgrade in a routine window, not one you touch twice a year under pressure.

If every nginx upgrade is currently a bespoke event in your estate, that is the actual finding, and it is the thing worth fixing — the same argument as sequencing an Envoy Gateway upgrade properly rather than hand-patching edges. We build this into DevOps and cloud engineering work for exactly this reason: the config audit above is a one-off, but the eighth release of the year is not. And when the queue of mediums starts outrunning the windows, the problem has become deciding what to automate and what to keep.