The October 2026 NGINX CVEs and Ingress NGINX

On October 14, 2026, nginx 1.31.7 and 1.30.6 fixed five CVEs, three of them scored 9.2 on CVSS 4.0. None of the five can be exploited on a stock, now long-past EOL Ingress NGINX deployment, provided you use the default configuration. Two are not reachable at all, and the other three need a feature you would have to turn on yourself. You should still care. Your scanner does not read nginx.conf, two earlier 2026 nginx CVEs do reach Ingress NGINX, and Ingress NGINX stopped receiving security fixes in March 2026.

NGINX, Ingress NGINX, and NGINX Ingress Controller are three different things

The names are confusing enough that it is worth getting this straight before talking about CVEs.

NGINX is the web server and reverse proxy. The open source project lives at nginx.org and is developed by F5.

‍Ingress NGINX (kubernetes/ingress-nginx) is the community Kubernetes ingress controller maintained under Kubernetes SIG Network. It is a Go controller that watches Ingress objects, renders an nginx.conf from a template, and runs it on its own build of nginx with a handful of patches and Lua modules. The final upstream release, v1.15.1, bundles nginx 1.27.1.

If you installed Ingress NGINX from the Kubernetes Helm repo, you are likely still running unsecure, EOL, and unpatched Ingress NGINX. 

You can confirm the nginx version inside the controller with:

kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- nginx -v

Ingress NGINX v1.15.1 reports nginx version: nginx/1.27.1.

NGINX Ingress Controller is F5's own, separate Kubernetes controller. F5 lists it as affected by this batch. It is not what this post is about.

What did nginx 1.31.7 and 1.30.6 fix?

Five CVEs, all announced in the nginx changelog and security advisories on October 14, 2026. nginx rates all five medium. F5, as the CVE Numbering Authority, scores them higher:

Sources: nginx.org CHANGES and security advisories, F5 advisories K000162416, K000162607, K000162608, K000162613, and K000162606, and the NES for Ingress NGINX 1.15.9 release notes.

Why none of them reach a stock Ingress NGINX deployment

Each of the five October CVEs depends on a directive, and Ingress NGINX either cannot emit that directive or does not emit it by default.

CVE-2026-15176 is not reachable. Ingress NGINX builds nginx with 00_drop-alias-root.patch, which deletes the alias and root directives from nginx entirely. A configuration that uses alias, even through a snippet, fails to load with unknown directive "alias".

CVE-2026-93479 does not apply to upstream Ingress NGINX. The bug was introduced by the July fix for CVE-2026-42533 and only exists in nginx 1.30.0 to 1.30.5 and 1.31.2 to 1.31.6. nginx 1.27.1 predates it.

CVE-2026-97205 needs two things. The first is already true: the Ingress NGINX template sets aio threads; in the http block unconditionally. The second is not: ssi on appears nowhere in the template, so SSI only happens if someone adds it in a snippet.

CVE-2026-97629 needs TLS session tickets. The ssl-session-tickets ConfigMap key defaults to "false", which renders ssl_session_tickets off;. Turning it on without also setting ssl-session-ticket-key is what exposes you, because the key file disables the automatic rotation where the bug lives.

CVE-2026-95101 needs HTTP/3. Ingress NGINX compiles nginx with --with-http_v3_module, but the template never creates a listening quic socket. Getting HTTP/3 means a server snippet plus exposing UDP 443 on the Service.

Snippets are the common thread, and they are off by default. allow-snippet-annotations defaults to "false", and annotations-risk-level defaults to High, which blocks the configuration-snippet and server-snippet annotations that are rated Critical. ConfigMap snippets (http-snippet, server-snippet, main-snippet) are set by whoever controls the controller's ConfigMap.

To check your own cluster, look for snippets and session tickets in the controller ConfigMap and your Ingress objects:

kubectl get configmap -n ingress-nginx ingress-nginx-controller -o yaml | grep -E 'snippet|ssl-session-ticket'

kubectl get ingress -A -o yaml | grep -E 'snippet'

Then check what nginx is actually running:

kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- nginx -T | grep -E 'ssi on|quic|ssl_session_tickets on'

No output from the last command means none of this month's three opt-in preconditions are met.

Can the October 2026 nginx CVEs be exploited remotely?

Yes, on an nginx that meets the preconditions. All five are triggered by an unauthenticated client over the network, which is why F5 scores them as high as it does.

CVE-2026-97205, CVE-2026-15176, and CVE-2026-93479 corrupt worker process memory. The reliable outcome is a worker crash. F5 says code execution is possible.

CVE-2026-95101 lets an HTTP/3 client get bytes past client_max_body_size or inject them into the request nginx proxies to your backend.

CVE-2026-97629 can let a forged TLS session resume, which matters most if you use the auth-tls-* annotations for client certificate authentication. F5 describes the forgery as non-deterministic and "beyond the attacker's control."

Why Ingress NGINX users should still care

I think the reachability analysis is a good reason not to panic this week. It does not close anything though.

First, earlier 2026 nginx CVEs do reach Ingress NGINX, and upstream v1.15.1 has no fix for them.

CVE-2026-42945, 'NGINX Rift', fixed May 13, 2026 (CVSS 4.0 9.2), is a heap overflow in the rewrite module triggered by a rewrite with unnamed captures like $1 or $2 and a replacement containing a ?, followed by another rewrite, if, or set. VulnCheck saw exploitation attempts starting May 16, three days after disclosure. Ingress NGINX generates rewrite directives from the rewrite-target annotation, which almost always uses unnamed captures. Whether a given Ingress is exploitable depends on its target. That it is on the request path for a lot of real clusters does not.

CVE-2026-42533, fixed July 15, 2026 (CVSS 4.0 9.2, rated major by nginx), is a heap overflow in regex map capture handling. Ingress NGINX renders regex map blocks from the block-user-agents and block-referers ConfigMap keys and matches them against the client-controlled User-Agent and Referer headers, before any authentication.

Second, scanners match versions, not configurations. Trivy, Grype, and every container scanner built on them see nginx 1.27.1 in the controller image and flag every CVE whose affected range includes it. That is four of this month's five: CVE-2026-15176, CVE-2026-97205, CVE-2026-97629, and CVE-2026-95101, two of them with a CVSS 3.1 score of 8.1.

Third, "not reachable" is an argument, not evidence. PCI DSS v4.0 requirement 6.3.3 expects critical and high security patches within one month of release. SOC 2 and FedRAMP assessors ask for a patch or a documented justification. The normal form of that justification is a signed VEX (Vulnerability Exploitability eXchange) statement from whoever ships the software, and Ingress NGINX upstream does not ship anything anymore. 

From the retirement announcement by Kubernetes SIG Network and the Security Response Committee: "Afterward, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered."

Every nginx CVE from here forward lands on Ingress NGINX the same way: on your scan report, with nobody upstream to fix it or explain why it does not apply.

How NES for Ingress NGINX handled October 2026

NES (Never-Ending Support) for Ingress NGINX 1.15.9 shipped October 19, 2026. It backports all five upstream fixes onto the pinned nginx 1.27.1, including the ones that are not reachable, so the scanner findings close instead of waiting on an exception.

CVE-2026-93479 is a good example of why this takes care. It does not affect upstream Ingress NGINX, but NES had already backported the July fix for CVE-2026-42533 in 1.15.7, and CVE-2026-93479 is a flaw in that fix. So NES needed this patch even though upstream does not.

Every CVE in the release notes carries its reachability analysis on Ingress NGINX, and the release ships with VEX statements for your auditor. NES also backported CVE-2026-42945 in 1.15.4 on May 18, 2026, five days after nginx fixed it, and CVE-2026-42533 in 1.15.7 on July 23, 2026.

The 1.15.9 image is a drop-in replacement for upstream v1.15.1:

registry.nes.herodevs.com/nes/ingress-nginx:v1.15.1-nes-1.15.9

It is also available as version 0.0.15 of the HeroDevs Helm chart.

What about NGINX itself?

If you run nginx directly, on VMs, in your own containers, or from distro packages, upgrade to 1.30.6 or 1.31.7, or to your distro's backported package. nginx.org only fixed the current stable and mainline branches. Older stable branches, like 1.28, did not get these fixes. NGINX Plus customers should check F5's advisories for fixed builds.

For teams pinned to an nginx release that no longer gets fixes, NES for NGINX is coming. More details to follow.

Frequently asked questions

Are the October 2026 nginx CVEs exploitable on Ingress NGINX?

Not on a stock deployment. CVE-2026-15176 is not reachable because Ingress NGINX removes the alias directive, CVE-2026-93479 does not affect nginx 1.27.1, and the other three need SSI, TLS session tickets, or HTTP/3, none of which Ingress NGINX enables by default.

Can I upgrade the nginx inside Ingress NGINX myself?

Not easily. The controller image bundles its own nginx build with Ingress NGINX patches and Lua modules, and upstream stopped publishing new images when the project retired in March 2026.

Is F5 NGINX Ingress Controller the same as Ingress NGINX?

No. NGINX Ingress Controller is F5's product and F5 has its own advisories for it. Ingress NGINX is kubernetes/ingress-nginx, an EOL component from the Kubernetes project.

Are any of the October CVEs exploited in the wild?

None were known to be as of October 15, 2026. CVE-2026-42945 from May 2026 was, starting May 16. However, it only took about three days for exploits of NGINX Rift to be detected after disclosure.

Should I migrate off Ingress NGINX?

Yes, eventually. Kubernetes recommends Gateway API as the replacement. NES for Ingress NGINX is for the clusters that cannot move before the next audit.

Patched nginx for Ingress NGINX

NES for Ingress NGINX keeps the nginx inside your ingress controller patched, with reachability analysis and VEX for every CVE. Talk to our team about coverage, and about NES for NGINX.

‍

‍