nginx alias rewrite vulnerability: audit the config

The nginx alias rewrite vulnerability disclosed this month, CVE-2026-15176, is listed by nginx as affecting "0.1.29-1.31.6" — effectively every nginx release ever shipped until this one. That range changes the question you should be asking. "Are we on a recent version?" has no useful answer here, because until 14 October the answer was no for everybody. The question is whether your configuration contains the pattern that makes the overflow reachable, and that you can settle in about ten minutes.

It is also, notably, the one bug in this release that F5 found in its own code rather than receiving from an outside researcher.

The nginx alias rewrite vulnerability, as nginx describes it

The entry on nginx's security advisories page is four lines long. The title is "Buffer overflow when using alias with rewrite". Severity: medium. Vulnerable: 0.1.29-1.31.6. Not vulnerable: 1.31.7+, 1.30.6+.

That is the entire upstream description. There is no explanation of the mechanism, no CVSS score, no date, and — this is the part that trips people up — no workaround. nginx publishes none for any of the five October CVEs.

The mitigation guidance that is circulating comes from F5's advisory articles, as relayed in coverage of the release: do not use alias in that location, and do not use $request_filename. Reporting also puts F5's own score for this one at 9.2 Critical on CVSS v4.0, against nginx's medium. We could not open F5's articles directly — they serve an empty application shell without a browser session — so treat both the score and the workarounds as reported rather than quoted from the vendor.

The directive combination that makes it reachable

Three ingredients have to meet: an alias directive, a rewrite affecting the same request, and $request_filename being evaluated. A location that serves static files with root and no rewriting is not the shape described.

Dump the effective configuration — not the file you think is live, the whole thing including every include — and search it:

nginx -T > /tmp/effective.conf

# Locations that use alias
grep -n -B4 -A10 '\balias\b' /tmp/effective.conf

# Anywhere $request_filename is evaluated
grep -n '\$request_filename' /tmp/effective.conf

Then read each hit rather than counting them. You are looking for an alias and a rewrite inside the same location, or a $request_filename used in a try_files, a log format or a proxy header within such a block. Where the three do not co-occur, that location is not the pattern, and you can say so in your assessment with a line number rather than a shrug.

Two practical notes. nginx -T prints secrets that sit in your config, so treat the dump as sensitive and delete it afterwards. And run it on every node: config drift between an old appliance and a freshly provisioned one is exactly where a stray alias survives.

Why old estates collect alias blocks

This is the part a version table will not tell you. alias exists to map a URL prefix onto a filesystem path that does not match it, which is precisely what you need when you bolt a new path onto a site whose directory layout you cannot change. So it accumulates for a predictable reason: every time someone had to serve /legacy-reports/ out of a directory that was never called that, alias was the shortest route, and rewrite usually arrived in the same change to keep old URLs working.

The result is that the configurations most likely to contain this pattern are the ones nobody has rewritten in years — the same estates where a nginx upgrade is least routine. We see this shape constantly in legacy modernisation work: the vulnerability is not evenly distributed across versions, it is concentrated in the configs that grew by accretion.

If an audit turns up alias blocks you cannot explain, that is a finding worth more than this CVE. An unexplained alias is also a path-traversal risk in its own right, independent of any overflow, because of the well-known trailing-slash asymmetry between location and alias.

Is a medium worth a patch window?

Give the counter-argument its due. nginx rates it medium, the memory-corruption impact on a modern build with full hardening is unproven, there was no exploitation reported at disclosure, and the fix means moving a reverse proxy that everything behind it depends on. Deferring to the next scheduled window is a defensible call.

Two things argue the other way. First, this release also fixes a TLS session-forgery bug and an HTTP/3 request-injection bug, so you are not scheduling a window for one medium — you are scheduling it for five, all rated medium by nginx and three of them scored critical by F5 in the reporting above. Second, nginx's May 2026 rewrite-module overflow, CVE-2026-42945, was reportedly exploited within days of disclosure, which is a poor precedent for treating "medium, no known exploitation" as a reason to wait.

Upgrade to 1.30.6 on stable, or 1.31.8 on mainline — not the 1.31.7 the advisory names, which the download page has already superseded. If the proxy sits in a path everything else depends on, stage it the way you would sequence an Envoy Gateway upgrade: one node, verified, before the fleet.

What this is worth beyond the CVE

The durable output of this exercise is not the patch. It is an effective-config dump you have actually read, per node, with the alias blocks explained or removed. Most teams have never had that, which is why the next advisory with a config precondition will cost them the same ten minutes again — the same reason checking a GHES patch number twice turns out to be a process problem rather than a lookup problem.

Do the audit once, keep the output, and the next release in what is now nginx's eighth security cycle of the year becomes a diff instead of an investigation.