Vulnerabilities

F5 rushes out NGINX fixes for three critical memory flaws

F5 patches 11 NGINX flaws, three critical 9.2 memory bugs plus a TLS client-certificate bypass. What UK teams should check and fix now.

Server rack illustration with the headline NGINX critical flaws patched by F5

F5 has shipped out-of-band fixes across its NGINX product family for 11 vulnerabilities, three of which it scores as critical memory corruption bugs reachable by unauthenticated attackers. Nothing is known to be exploited yet, but NGINX’s track record this year suggests the window before attacks begin will be short.

What happened

The NGINX open source project released 1.30.6 on its stable branch and 1.31.7 on mainline on 14 October 2026, closing five security holes. F5, which owns NGINX, published an advisory (K000163408), reported on 16 October, covering 11 defects across the wider product set, and on 19 October BleepingComputer reported that F5 had released out-of-band patches for NGINX Plus, NGINX Open Source, NGINX Ingress Controller, NGINX Gateway Fabric and NGINX Instance Manager.

Three of the flaws, CVE-2026-15176, CVE-2026-93479 and CVE-2026-97205, carry a CVSS v4.0 score of 9.2 from F5. The NGINX project itself rates its five fixes as medium, which tells you something about how much the outcome depends on configuration. Two further bugs stand out: CVE-2026-97629, a TLS session flaw scored 8.3 that can undermine client certificate checks, and CVE-2026-95101, an HTTP/3 flaw scored 6.9 that can slip extra data into proxied requests.

Neither F5 nor the NGINX project has reported exploitation in the wild, and none of the CVEs was in CISA’s Known Exploited Vulnerabilities catalogue when the fixes landed. This is the eighth NGINX security release of 2026, according to The Hacker News.

The technical picture

All three critical bugs corrupt memory inside an NGINX worker process. The guaranteed outcome is a crash and restart of that worker, which is a denial of service. Code execution is described as possible, but only where address space layout randomisation (ASLR) is switched off or the attacker can defeat it, a condition SecurityWeek notes is outside the attacker’s direct control.

What matters most is that each bug needs a specific, non-default configuration to be reachable:

  • CVE-2026-15176 is a heap overflow that appears when a location uses the alias directive, a rewrite changes the URI, and something then reads the $request_filename variable. It affects versions as far back as 0.1.29 and was found by F5 internally.
  • CVE-2026-93479 is a heap overflow in regex-based map blocks where root or log_format uses the capture groups ahead of the variable the map produces. It follows on from CVE-2026-42533, a July overflow in the same area whose two earlier patches did not fully close the gap.
  • CVE-2026-97205 is a use-after-free triggered when asynchronous file I/O (aio) is enabled and Server Side Includes pages use include virtual. A small counter of pending operations can wrap round to zero, freeing a request while work still points at it.

The TLS bug is the one I would worry about most in a regulated environment. When ssl_session_cache shared is configured without an explicit ssl_session_ticket_key, NGINX’s automatic key rotation copies only two of its three key slots, leaving one uninitialised. F5 says forging a session this way is non-deterministic, but the result could be a resumed session that skips client certificate verification. The shared cache line appears in NGINX’s own example configuration, so it will be in plenty of production files.

Checklist of six steps for patching and auditing NGINX after F5's October 2026 security fixes

Why it matters for UK organisations

NGINX sits in front of a very large share of UK web estates, from public sector portals to e-commerce platforms, and it is a common Kubernetes ingress. It is also embedded quietly in appliances, container images and vendor products that teams do not always think of as “running NGINX”.

Three practical problems follow. First, NGINX only ships fixes for the 1.30 and 1.31 branches. Anything older, including the 1.28 branch, stays vulnerable unless a Linux distribution has backported the patches, so a routine package update may not be enough. Second, as of 15 October F5 had not listed fixed builds for several of its commercial products, so Ingress Controller and Gateway Fabric users need to check the advisories rather than assume. Third, mutual TLS is common in UK financial services and in supplier and API integrations; a flaw that can weaken client certificate checks touches exactly the controls auditors and the FCA expect to work.

The history is not reassuring. CVE-2026-42945, a rewrite module overflow fixed in May, was exploited within days of disclosure according to VulnCheck. BleepingComputer also notes that eight F5 flaws have appeared in CISA’s exploited catalogue since late 2021, and half of those were linked to ransomware.

Expert view

The gap between F5’s 9.2 and the NGINX project’s “medium” is not a contradiction. It reflects the fact that these are configuration-dependent bugs: severe if your files match the pattern, irrelevant if they do not. That makes this a configuration review exercise as much as a patching one, and it is where many organisations are likely to fall short.

In my experience, very few teams can say with confidence what directives are live across their NGINX fleet. Configurations accrete over years and get copied between environments. When we test web estates we routinely find alias blocks, legacy SSI and inherited TLS settings that the current owners did not know were there.

I would also caution against reading “needs ASLR bypass” as “safe”. A reliable crash on a busy reverse proxy is an outage in its own right, and the May exploitation of CVE-2026-42945 shows that NGINX memory bugs can attract attention quickly. The repeated fixes in the map code are a further sign that this area deserves scrutiny rather than a single tick in the change log.

Finally, remember that load balancers, WAFs, container images and suppliers’ edge tiers may all carry vulnerable builds, so ask key suppliers for a written statement.

What to do now

  1. Inventory every instance. Include containers, ingress controllers and appliances, not just hosts with an nginx package. This maps directly to the Cyber Essentials requirement to know and manage your devices and software.
  2. Upgrade to 1.30.6 or 1.31.7, or confirm your distribution has backported the fixes. Move anything on 1.28 or older to a supported branch. Cyber Essentials expects critical and high-risk updates within 14 days of release.
  3. Check F5 product advisories for NGINX Plus, Ingress Controller, Gateway Fabric and Instance Manager, and track any that still lack a fixed build.
  4. Dump and search the running configuration with nginx -T for alias alongside rewrite, regex map captures used by root or log_format, aio together with ssi, and ssl_session_cache shared without ssl_session_ticket_key.
  5. Apply interim workarounds where patching must wait: drop alias or $request_filename in affected locations, switch to named captures inside the regex block, disable aio or SSI, and either load ticket keys from a file or set ssl_session_tickets off.
  6. Confirm ASLR is enabled on every host and container runtime, as part of secure configuration.
  7. Watch for exploitation news and add worker crash and restart alerts to your monitoring, since repeated crashes may be the first sign of probing.

Bottom line

These are not drop-everything internet-wide bugs, but they are serious for anyone whose configuration matches, and NGINX flaws have been weaponised quickly this year. Patch the supported branches now, treat the configuration audit as the real work, and do not overlook the TLS fix if you rely on client certificates.

Sources

Related Posts