Skip to content
CONAKRY · LAMBANYI — +224614686869 contact@visiodev.net
Français Request a quote
← All articles
DEVOPS 7 MIN

NGINX: five vulnerabilities fixed, three rated critical

On October 14, 2026, NGINX fixed five vulnerabilities, including three memory corruption flaws rated 9.2 out of 10 by F5. How dangerous they are depends on your configuration: here is how to tell whether your servers are exposed and how to update them.

VisioDev NGINX visual: annotated configuration linking each risky directive to its CVE

What happened

NGINX is the front door to a huge part of the web: web server, reverse proxy in front of APIs, load balancer, ingress controller in Kubernetes clusters. On October 14, 2026, nginx.org released versions 1.30.6 (stable) and 1.31.7 (mainline), which fix five vulnerabilities. The same day, F5, the company behind NGINX, issued an out-of-band security advisory covering NGINX Plus and its derived products, and the njs module received two separate fixes.

  • CVE-2026-15176 (9.2): memory overflow when alias is combined with a rewrite that modifies the URI and with the $request_filename variable. Present since version 0.1.29, in other words since 2005.
  • CVE-2026-93479 (9.2): memory overflow when evaluating expressions that use regular expression captures in a map block. This is a regression introduced by the July fix (CVE-2026-42533). Versions 1.30.0 to 1.30.5 and 1.31.2 to 1.31.6.
  • CVE-2026-97205 (9.2): use-after-free with SSI includes (include virtual) and asynchronous I/O (aio). An internal 8-bit counter wraps back to zero after 255 operations, and a request is freed while it is still in use. Present since version 0.8.11.
  • CVE-2026-97629 (8.3): TLS session forgery. Since version 1.23.2 (October 2022), automatic rotation of TLS ticket keys only copied two slots out of three; the third contained uninitialized memory.
  • CVE-2026-95101 (6.9): data injection into HTTP/3 request bodies, passed on to the application server while bypassing the client_max_body_size limit. Since version 1.25.0.

The scores are F5's, on the CVSS 4.0 scale.

Who found them, and how

  • CVE-2026-15176: F5's own teams, internally.
  • CVE-2026-93479: Matt Suiche (Tolmo) and Mateusz Gierblinski, while reviewing the fix published in July.
  • CVE-2026-97205: an independent researcher known as Cyberlanc3r.
  • CVE-2026-97629: PhiNode Labs.
  • CVE-2026-95101: Hansol Lee (GOTROOT).

These flaws come in a busy year. In May, "NGINX Rift" (CVE-2026-42945, in the rewrite module, sixteen years old) was fixed on May 13 and then exploited in the wild from the 16th, shortly after a proof of concept was published. In July, CVE-2026-42533 already affected regular expression captures in map. NGINX's code has never been scrutinized so closely, and one of the October flaws was born from the July fix.

How they spread

As of October 15, neither NGINX nor F5 reported any attacks, and the five CVEs were not in CISA's catalog of known exploited vulnerabilities. We have not found any report of confirmed exploitation since. Yet the NGINX Rift precedent is a reminder that three days can be enough.

What is spreading is the affected footprint, because the vulnerable code is embedded everywhere:

  • NGINX Open Source up to 1.30.5 and 1.31.6, in distribution packages and Docker images. Older branches, such as 1.28, get no fix from nginx.org: only your distribution's backport protects you.
  • NGINX Plus R33 to R37.
  • Derived F5 products: NGINX Ingress Controller 5.6.0 to 5.6.3, NGINX Gateway Fabric 1.5.0 to 1.6.2 and 2.1.0 to 2.7.2, NGINX Instance Manager 2.18.0 to 2.23.0, F5 WAF for NGINX 5.9.0 to 5.15.0, NGINX App Protect WAF, F5 DoS for NGINX. BIG-IP, BIG-IQ and F5OS are not affected.
  • Kubernetes: the community ingress-nginx controller has not been maintained since March 2026 and ships NGINX 1.27.1. It will not receive these fixes. In its default configuration, most of the flaws cannot be reached, but your scanners will flag them.

To give an order of magnitude, the ZoomEye search engine counted nearly 50 million NGINX responses on port 443 on October 26. That is the visible surface, not the number of vulnerable servers: it all depends on the configuration.

The risks

  • Denial of service. For the three memory corruption flaws, the most reliable outcome is a crash of the worker process. Repeated, the attack makes the service unstable.
  • Code execution. F5 considers it possible when ASLR protection is disabled or bypassed and the vulnerable configuration is present. Since NGINX sits in front of everything else, compromising it means seeing all the traffic go by: certificates, credentials, session cookies.
  • Bypassing client certificate authentication. With CVE-2026-97629, a forged session could get past the mTLS check that protects B2B APIs, back offices or connected devices. F5 notes that this forgery is not deterministic.
  • Bypassing limits. Over HTTP/3, injected data reaches the application server without going through the size checks.

"Medium" for NGINX, "critical" for F5: who to believe?

NGINX rates all five flaws as medium severity, because the default configuration is not exposed to them. F5, the CVE numbering authority, scores the worst plausible case: an unauthenticated remote attacker with a crafted request. Both readings are correct. Your real level of risk depends on your configuration, and that is what needs auditing.

Available fixes

  • NGINX Open Source: 1.30.6 (stable) or 1.31.7 (mainline), or later. Version 1.31.8 was released on October 21.
  • NGINX Plus: 37.1.0.1 or 37.0.5.1.
  • Derived F5 products: fixed versions listed in F5 advisories K000162416, K000162607 and K000162608.
  • Linux distributions: backported packages, to be checked in your distribution's security bulletin.
  • Community ingress-nginx: no official fix. Plan the migration to Gateway API or a maintained controller; extended support offers exist in the meantime.

How to apply them, step by step

  • 1. Identify the version: nginx -v on each server, docker run --rm <image> nginx -v for each image.
  • 2. Audit the configuration. Display the full configuration and look for the triggers: sudo nginx -T | grep -nE 'alias|request_filename|map|ssi on|aio|ssl_session_cache|ssl_session_ticket_key|quic'. A server showing any of them becomes top priority; the others must be fixed too, with slightly less urgency.
  • 3. Update. On Debian or Ubuntu: sudo apt update && sudo apt install --only-upgrade nginx. On Red Hat, Rocky or AlmaLinux: sudo dnf upgrade nginx. With Docker: move to nginx:1.30.6 or later, rebuild and redeploy.
  • 4. Test, then restart: sudo nginx -t && sudo systemctl restart nginx. Be careful: a simple reload rereads the configuration but keeps the old binary in memory. To avoid any downtime, NGINX can replace its binary on the fly (USR2 signal).
  • 5. Check the running version, and that ASLR protection is active: cat /proc/sys/kernel/randomize_va_space should return 2.

If you cannot update right away, F5 offers workarounds, flaw by flaw:

  • CVE-2026-15176: avoid alias in location blocks that rewrite the URI, and stop using $request_filename, including in your log formats;
  • CVE-2026-93479: replace numbered captures ($1, $2) with named captures, used only in the block that contains the regular expression;
  • CVE-2026-97205: aio off; or disable SSI;
  • CVE-2026-97629: ssl_session_tickets off;, or load your own keys with ssl_session_ticket_key;
  • CVE-2026-95101: proxy_request_buffering off; for HTTP/3 traffic, or temporarily disable HTTP/3.
These workarounds reduce exposure, they do not eliminate it. One researcher has already reported that a narrower attack path remains for CVE-2026-93479. Only the update fixes it.

Our takeaways

Your configuration is your attack surface. For these flaws, two servers on the same version do not carry the same risk. Version your NGINX configuration in Git and review it like code.

One fix can lead to another. CVE-2026-93479 was born from the July fix. That is no reason to delay updates, but it is a reason to test them and keep an eye on the next ones.

An abandoned component is security debt. ingress-nginx will no longer be patched: migrating is no longer a nice-to-have.

Is NGINX on the front line in front of your websites and APIs? We audit its configuration, apply updates without service interruption and support the migration of your Kubernetes clusters to Gateway API. Tell us about your project.

Sources: nginx.org, F5 (advisories K000162416, K000162607, K000162608), CSA Singapore, The Hacker News, BleepingComputer, HeroDevs, SecurityWeek (advisories published October 14 to 26, 2026).

Share

Further reading