On October 14, 2026, F5 released NGINX Open Source 1.30.6 (stable) and 1.31.7 (mainline). They fix five core vulnerabilities, and F5 scores three of them as critical heap-overflow or use-after-free bugs. Each one needs a specific, non-default configuration to trigger, so the first thing to find out is whether your nginx.conf uses alias with rewrite, regex captures in map, AIO with SSI, HTTP/3 or TLS session ticket rotation. If any of those apply, upgrade today. If none do, upgrade anyway at your next maintenance window, because the September HTTP/3 fix and these new ones are now bundled in the same releases.
The guide covers what was fixed, why the severity ratings conflict, how to check your own configuration in a few minutes, and what to do about Kubernetes ingress, distro packages and containers.
What F5 fixed on October 14
According to the nginx.org release announcement, the two releases fix five issues in the core server. The 1.31.7 changelog explains how each one is triggered:
| CVE | What goes wrong | Trigger condition | Vulnerable versions |
|---|---|---|---|
| CVE-2026-15176 | Heap buffer overflow in a worker process | alias directive, where the URI was changed by rewrite and then mapped to a file path |
0.1.29–1.31.6 |
| CVE-2026-93479 | Heap buffer overflow while evaluating string expressions with variables (document root calculation, request logging; http and stream) | Regex map capture references used prematurely, or certain non-cacheable variable expressions |
1.30.0–1.30.5, 1.31.2–1.31.6 |
| CVE-2026-97205 | Use-after-free | Asynchronous file I/O (AIO) plus SSI pages with include virtual |
0.8.11–1.31.6 |
| CVE-2026-95101 | Part of an unknown HTTP/3 frame treated as request body, so client_max_body_size can be bypassed or data injected into the proxied request |
HTTP/3 enabled | 1.25.0–1.31.6 |
| CVE-2026-97629 | One TLS session ticket key left uninitialized, which can allow session forgery | Automatic session ticket key rotation (shared ssl_session_cache without explicit key files) |
1.23.2–1.31.6 |
The version ranges come from the nginx security advisories page. For each CVE, versions 1.30.6+ and 1.31.7+ are not vulnerable.
F5 also released njs 1.0.2 on the same day. It fixes a memory exhaustion bug when parsing malformed XML (CVE-2026-101025) and inconsistent XML attribute values that affect signed XML validation (CVE-2026-101019). If you use njs's XML module for SAML or other signed documents, the second one is more important to you than the headline CVEs.
The full F5 advisory is larger
F5's out-of-band notice covers more than the core server. A Health-ISAC bulletin summarising the advisory counts 11 vulnerabilities: 3 critical, 6 high and 2 medium. Besides the core and njs bugs, it lists:
- Two NGINX Ingress Controller external-auth bypasses (CVE-2026-94197 and CVE-2026-104939), both CVSS 8.7.
- Two NGINX Gateway Fabric issues. One concerns authentication filter realm fields (CVE-2026-91184, 8.7). The other involves Gateway CRDs and NGINX Agent gRPC connections and, per the bulletin, may expose TLS private keys across namespaces (CVE-2026-96615, 6.5).
BleepingComputer lists the affected product families as NGINX Plus, NGINX Open Source, NGINX Ingress Controller, NGINX Gateway Fabric and NGINX Instance Manager.
Critical or medium? Why the ratings disagree
The two ratings conflict, and it affects how fast you should act. The nginx.org advisories page rates all five core issues as "medium." F5 gives the three memory-corruption bugs (CVE-2026-15176, CVE-2026-93479, CVE-2026-97205) a CVSS v4.0 score of 9.2, which is critical, as eSecurity Planet and the Health-ISAC bulletin both report.
The two ratings measure different things:
- The medium rating reflects reachability. Each bug needs a specific directive combination that most default installs don't have.
- The critical rating reflects impact once the bug is reachable. BleepingComputer quotes F5 as saying an unauthenticated remote attacker could crash worker processes and potentially "execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR."
In practice: if your config matches a trigger condition, treat the issue as critical. If it doesn't, treat it as routine but overdue. Most production NGINX fleets are large and old enough that somebody has used alias and rewrite together somewhere.
Exploitation status
As of October 20, 2026, F5 had not flagged any of these issues as exploited in the wild, according to BleepingComputer, and eSecurity Planet found no confirmed public exploitation either. Attackers do target F5 products, though. The same BleepingComputer report notes that CISA has flagged eight F5 vulnerabilities as actively exploited since November 2021, and that F5 disclosed in October 2025 that state-backed attackers had stolen BIG-IP source code. Patches that ship out of band usually get reverse-engineered within days.
How to check whether you're exposed
You can audit a server in about five minutes. Run the steps on every host or image that runs NGINX, including the reverse proxy someone set up two years ago and forgot about.
-
Get the version and build flags.
nginx -V 2>&1 | head -n 3If the version is below 1.30.6 (stable) or 1.31.7 (mainline) and the binary comes from nginx.org or a vendor image, you need to upgrade. Distro packages work differently; see the next section. -
Dump the effective configuration, including every
included file:nginx -T > /tmp/nginx-full.conf -
Search for the trigger directives:
grep -nE '\b(alias|rewrite|map|aio|ssi|include virtual|quic|http3|ssl_session_cache|ssl_session_ticket)' /tmp/nginx-full.conf -
Read the matches against the table above:
aliasandrewritein the same location path, especially with$request_filename, matches CVE-2026-15176.- A
mapblock with a regex key whose captures ($1,$2) are referenced outside the block that matched them matches CVE-2026-93479 (1.30.x/1.31.2+ only). aio onoraio threadsin a server wheressi onserves pages containing SSIinclude virtualcommands matches CVE-2026-97205.listen ... quicorhttp3 onmatches CVE-2026-95101.ssl_session_cache shared:...with session tickets enabled (the default) and nossl_session_ticket_keyfiles matches CVE-2026-97629.
-
Don't forget the stream module. CVE-2026-93479 also affects variable evaluation in
stream {}blocks, so check TCP/UDP proxies too.
Workarounds if you can't patch today
BleepingComputer and eSecurity Planet both report F5's interim mitigations. These buy you time but are not a fix:
| CVE | Interim mitigation | Trade-off |
|---|---|---|
| CVE-2026-15176 | Avoid alias in affected locations (use root where you can) and stop using $request_filename there |
Path layout may need changes; test file serving carefully |
| CVE-2026-93479 | Use named captures (for example (?'name'...)) instead of $1-style captures, and only reference them inside the block that matched |
Config edits across many maps |
| CVE-2026-97205 | Disable AIO or SSI | Disabling AIO can hurt large-file throughput; disabling SSI breaks pages that rely on it |
| CVE-2026-95101 | Disable HTTP/3 if you don't need it | Clients fall back to HTTP/2 over TCP |
| CVE-2026-97629 | Review TLS ticket settings, e.g. set ssl_session_tickets off; or supply explicit ssl_session_ticket_key files |
Slightly more full handshakes, or you take on key rotation yourself |
eSecurity Planet also recommends making sure backend application servers only accept connections from your proxies. That limits the damage from the HTTP/3 body-injection bug and is good practice anyway. Run nginx -t before every reload and watch error logs for unexpected worker exits (worker process ... exited on signal). A sudden rise in those is the most likely sign that someone is probing the memory bugs.
Kubernetes, distro packages and containers
NGINX Ingress Controller and Gateway Fabric
The NGINX Ingress Controller release notes show version 5.7.0, released October 14, 2026. It updates the bundled NGINX OSS to 1.31.7 and NGINX Plus to 37.2.0.1, and it includes security fixes for the external-auth bypasses CVE-2026-94197 (crafted X-Forwarded headers) and CVE-2026-104939. If you use ExternalAuth policies, upgrade the controller rather than just rebuilding the data-plane image.
This is F5's controller (nginx/kubernetes-ingress). The community kubernetes/ingress-nginx project is a separate codebase with its own advisories, so check which one your cluster runs before acting. For NGINX Gateway Fabric, follow F5's product advisory. The Health-ISAC summary doesn't give fixed versions, and we couldn't verify them independently.
Distro packages
If you installed NGINX from Debian, Ubuntu, RHEL, Alpine or similar, nginx -v may still report an older upstream version after you patch, because distributions often backport fixes without changing the version number. eSecurity Planet specifically advises checking for backported patches. Search your distro's security tracker for the five CVE IDs and compare the fixed package version with dpkg -l nginx or rpm -q nginx. If your distro hasn't shipped a fix yet, switching to the official nginx.org repository is the quickest route.
Container images
Rebuild your images; don't just restart pods. Pull the base image fresh, rebuild, and confirm with docker run --rm your-image:tag nginx -v. Pin to a tag at or above 1.30.6 or 1.31.7 so a stale build cache can't put an old binary back.
Why this keeps happening, and what to change
The October batch is part of a pattern. The nginx advisories page lists 26 entries with 2026 CVE IDs. These include a September 15 HTTP/3 buffer overflow (CVE-2026-90439, fixed in 1.30.5/1.31.6) and two issues rated "major" earlier in the year: a map/regex buffer overflow (CVE-2026-42533) and an HTTP/3 use-after-free (CVE-2026-42530). Several of these bugs sit in code paths that are more than a decade old. CVE-2026-15176 reaches back to 0.1.29, which suggests auditors and fuzzers, many of them now AI-assisted, are working through mature C codebases more thoroughly than before.
For small teams this has practical consequences:
- Expect NGINX releases roughly monthly. Automate upgrades through Renovate or Dependabot on your Dockerfiles, or with unattended upgrades from the nginx.org repo, so a security release doesn't need a person to remember it.
- Disable features you don't use. HTTP/3, SSI, AIO and njs XML parsing each show up in this year's advisories. If you don't rely on a feature, turning it off removes that attack surface in future releases too.
- Keep the config small. Long-lived
nginx.conffiles collectrewrite/aliascombinations and regex maps that nobody remembers adding. Runnginx -Tinto version control so you can grep the whole fleet in one place next time. - Know whether you're on stable or mainline. Both branches got the fix the same day, but they have different version numbers, and that confuses scanners and people alike.
What to do now
- Inventory every NGINX instance, including ingress controllers, sidecars, appliance-embedded builds and forgotten VMs.
- Upgrade to 1.30.6 or 1.31.7 (or the patched distro package), njs 1.0.2 if you use njs, and NGINX Ingress Controller 5.7.0 if you run F5's controller.
- Where you can't upgrade within 24 hours, run the
nginx -Taudit above and apply the matching mitigation. - Watch for CISA KEV additions or proof-of-concept code for CVE-2026-15176, CVE-2026-93479 and CVE-2026-97205. If any of these appears, every unpatched host with a matching config becomes an emergency.
- Check the nginx.org advisories page after each mainline release. Given how 2026 has gone, the next advisory may come within weeks.
Frequently asked questions
Which NGINX version fixes the October 2026 vulnerabilities?
NGINX Open Source 1.30.6 (stable) and 1.31.7 (mainline), both released on October 14, 2026, fix all five core CVEs. The njs fixes are in njs 1.0.2. NGINX Ingress Controller 5.7.0 ships NGINX OSS 1.31.7 and NGINX Plus 37.2.0.1.
Are the new NGINX vulnerabilities being exploited in the wild?
As of October 20, 2026, F5 had not flagged any of them as exploited, and no public exploitation had been confirmed. F5 products have been targeted before, though, and CISA has listed eight F5 vulnerabilities as actively exploited since 2021, so you should still patch promptly.
Why does nginx.org call these bugs medium while F5 calls them critical?
nginx.org rates all five core issues as medium, probably because each one needs a specific non-default configuration. F5 scores the three memory-corruption bugs at CVSS v4.0 9.2 (critical) because they are reachable remotely without authentication and could allow code execution if ASLR is disabled or bypassed. If your config matches the trigger, use the critical rating.
My distro's nginx -v still shows an old version. Am I vulnerable?
Not necessarily. Debian, Ubuntu, RHEL and other distributions often backport security patches without changing the upstream version number. Look up the CVE IDs in your distribution's security tracker and compare the fixed package version against what dpkg or rpm says you have installed.
Can I work around the NGINX flaws without upgrading?
Yes, as a stopgap. Avoid alias combined with rewrite and $request_filename, disable AIO or SSI where you use both, use named regex captures in map blocks, and turn off HTTP/3 or TLS session tickets if you don't need them. Upgrade as soon as you can, because these workarounds change behaviour and don't fix the underlying bugs.
Sources
- nginx.org — nginx 1.30.6 and 1.31.7 release announcement (October 14, 2026)— nginx.org
- nginx.org — nginx security advisories— nginx.org
- nginx.org — CHANGES (1.31.7 changelog)— nginx.org
- BleepingComputer — F5 releases out-of-band patches for critical NGINX vulnerabilities— bleepingcomputer.com
- eSecurity Planet — NGINX Patches 5 Security Flaws, Including 3 Rated Critical— esecurityplanet.com
- Health-ISAC via AHA — F5 Releases Out-of-band Security Updates for NGINX Flaws— aha.org
- F5 NGINX Ingress Controller release notes— docs.nginx.com