NGINX Ingress Controller 5.7: HTTP/2 to your upstreams, Opaque Secrets, and cert-manager challenges behind HTTPS redirects

NGINX Ingress Controller 5.7 speaks HTTP/2 to your upstream services, set per upstream or picked up from a Service’s appProtocol. An Opaque Secret now works anywhere a TLS, CA, htpasswd, or API key Secret does, so you can use a Secret created by other tooling as it is. HTTP-01 challenges from cert-manager complete on hosts that redirect to HTTPS or require authentication, a VirtualServerRoute without a host can be shared by any number of VirtualServers, least_time load balancing comes to NGINX Open Source, and a new ConfigMap key keeps the X-Forwarded headers that a proxy in front of you has already set.

How it runs got attention too. Topology-aware routing can keep traffic in a controller pod’s own zone or on its own node, the Helm chart can put more than one Service in front of a single controller, the upstream latency histogram takes your own buckets, and trace context propagation is now configurable. NGINX Ingress Controller 5.7 also adds operator certification in the Nutanix Kubernetes Platform Partner Catalog. Fixes make exact-match Ingress paths match again, keep the controller running when a namespace stops being watched, and keep VirtualServer status accurate. Changes to dynamic weight updates, F5 WAF for NGINX, and the F5 DoS for NGINX images need an F5 NGINX Enterprise solution, and they’re collected in one section at the end. Each community contribution is credited next to the change it made. Here’s what’s new.

Release highlights

HTTP/2 to your upstreams: Proxy to Services that speak cleartext HTTP/2, set per upstream or picked up from the Service itself.
Opaque Secrets: Use the Secrets your existing tooling creates for TLS, CA, basic auth, and API keys, without copying them into a typed Secret.
cert-manager challenges behind HTTPS redirects and authentication: Issue and renew certificates over HTTP-01 on hosts that redirect to HTTPS or require authentication.
Shared VirtualServerRoutes: Define the paths that several sites share once, and attach them to any number of VirtualServers.
Nutanix Kubernetes Platform operator certification: Run NGINX Ingress Controller on the Nutanix Kubernetes Platform with an operator certified in its Partner Catalog.
Bug fixes and smaller enhancements: Updates to Ingress path matching, watched namespaces, VirtualServer and VirtualServerRoute status, reloads, keepalive on mergeable Ingresses, request body size limits, CORS validation, HTTP/2 settings, the Helm chart, Helm 4 support, and Kubernetes 1.37.

HTTP/2 to your upstreams

What’s new: NGINX Ingress Controller can now proxy to upstream services over HTTP/2. VirtualServer and VirtualServerRoute upstreams take a proxy-http-version field, and Ingress resources, including mergeable minions, take an nginx.org/proxy-http-version annotation. Both accept 1.0, 1.1, or 2. 1.0 also sends Connection: close to the upstream. Leave them unset and NGINX Ingress Controller uses HTTP/2 for any Service port that declares appProtocol: kubernetes.io/h2c, while an explicit setting always takes precedence. Over HTTP/2 the Connection and Upgrade headers are dropped, since the protocol forbids them, and you get a warning if you set a version on a gRPC upstream or pair HTTP/2 with WebSockets (nginx/kubernetes-ingress#10905).

Why it matters: Services built to speak cleartext HTTP/2 (h2c) can now be proxied in that protocol, rather than over the HTTP/1.1 that NGINX Ingress Controller always used before. And because the version can come from the Service, a team that marks its port kubernetes.io/h2c gets HTTP/2 without anyone touching the Ingress or VirtualServer in front of it.

Opaque Secrets for TLS, CA, basic auth, and API keys

What’s new: NGINX Ingress Controller now accepts a plain type: Opaque Secret anywhere it reads one, as long as the Secret carries the keys the feature needs: tls.crt and tls.key for a TLS certificate, ca.crt for a CA, htpasswd for basic auth. That covers the default and wildcard server certificates too, and API key Secrets work the same way. Validation now checks the data rather than the Secret’s type, so kubernetes.io/tls and the nginx.org/ types keep working as before (nginx/kubernetes-ingress#10816).

Accepting Opaque means every Secret in a watched namespace now reaches the controller, so it ignores the ones it has no use for. Secrets that no resource references are skipped, updates are compared on their data rather than their metadata, and a Secret is written to disk only once a valid resource uses it.

Why it matters: Secrets created with kubectl create secret generic, and by common secret-management tooling, are Opaque. Until now, NGINX Ingress Controller accepted only kubernetes.io/tls and its own nginx.org/ types, so using one of those Secrets meant copying its data into a second Secret of the right type and keeping the two in step. Now you point the resource at the Secret you already have.

cert-manager challenges behind HTTPS redirects and authentication

What’s new: To pass an HTTP-01 challenge, cert-manager’s solver has to answer a plain-HTTP request under /.well-known/acme-challenge/ with a 200. NGINX Ingress Controller now recognizes an active challenge, a path under that prefix served by one of cert-manager’s cm-acme-http-solver- Services, and exempts it from the host’s HTTPS redirect and its authentication. There’s nothing new to configure:

On a VirtualServer: Challenge routes skip tls.redirect and authentication policies, while access control and rate limiting policies set on the VirtualServer still apply. Each challenge is served as an exact-match location, so a catch-all regex route can’t capture the token. If a route already defines that exact location, it’s left alone and the VirtualServer reports a warning. This needs -enable-cert-manager, and the solver’s Ingress must be in the same namespace as the VirtualServer (nginx/kubernetes-ingress#11015).
On an Ingress: Challenge paths that cert-manager adds with acme.cert-manager.io/http01-edit-in-place: "true" skip nginx.org/ssl-redirect, nginx.org/redirect-to-https, and authentication, while access control and nginx.org/limit-req-* rate limiting still apply (nginx/kubernetes-ingress#11015).

While a challenge is active, the redirect exemption covers every path under /.well-known/acme-challenge/ on that host, but only the challenge location itself skips authentication.

Why it matters: You can keep an HTTPS redirect and authentication on a host and still have cert-manager issue and renew its certificate over HTTP-01. Those used to pull against each other, and the way out was a temporary certificate, turning the redirect off, or a snippet.

One VirtualServerRoute, shared by many VirtualServers

What’s new: spec.host is now optional on a VirtualServerRoute. A VirtualServerRoute without a host can be attached to any VirtualServer, whatever its host, by name with route or by label with routeSelector, and to several VirtualServers at once. A VirtualServerRoute that sets host still has to match its VirtualServer, as before (nginx/kubernetes-ingress#10925).

Why it matters: Paths that several sites share, like a cart, a checkout, or an API, can now be defined once. Twenty regional hosts serving the same five paths used to need a hundred VirtualServerRoutes that differed only in host. Now they need five, and changing how one of those paths routes is one edit instead of twenty.

Operator certification in the Nutanix Kubernetes Platform Partner Catalog

What’s new: NGINX Ingress Controller 5.7 adds operator certification in the Nutanix Kubernetes Platform Partner Catalog.

Why it matters: This is an important milestone that expands platform support for Kubernetes teams on Nutanix and strengthens our integration with its partner ecosystem. We’re also looking forward to adding NGINX Gateway Fabric to Nutanix Kubernetes Platform later this year, right in time for KubeCon NA.

Least time load balancing in NGINX Open Source

What’s new: The least_time load balancing method, which sends each request to the upstream server with the lowest average response time and the fewest active connections, moves to open source. Set least_time header or least_time last_byte, optionally with inflight, through the nginx.org/lb-method annotation, the lb-method ConfigMap key, or lb-method on a VirtualServer upstream. TransportServer upstreams take it through loadBalancingMethod, measuring connect, first_byte, or last_byte (nginx/kubernetes-ingress#10746).

Why it matters: When your backends respond at different speeds, least time sends each request to the one answering fastest instead of taking turns, so a slow pod gets less traffic rather than an equal share.

Keep the X-Forwarded headers a proxy in front has already set

What’s new: A new use-forwarded-headers ConfigMap key tells NGINX Ingress Controller to pass on the X-Forwarded-Host, X-Forwarded-Port, and X-Forwarded-Proto headers it receives, rather than replacing them with its own connection details, and to send the forwarded host upstream as Host. It applies to Ingress, VirtualServer, and VirtualServerRoute resources. When a header carries several values, the first one wins, and when it’s missing, NGINX Ingress Controller falls back to its own values. The key is off by default and can’t be combined with disable-forwarded-headers, and a header you set explicitly on a VirtualServer still takes precedence. Because the headers are taken as they arrive, turn this on only when every request reaches NGINX Ingress Controller through the proxy that sets them (Ingress nginx/kubernetes-ingress#10947, VirtualServer and VirtualServerRoute nginx/kubernetes-ingress#10949).

Why it matters: Behind a content delivery network (CDN) or a cloud load balancer, NGINX Ingress Controller isn’t the first proxy a request meets, so the host, port, and scheme it sees are the ones that proxy connected with, not the ones your users asked for. Passing the originals through lets your application build correct redirects and links and check the domain it was really called on. NGINX Ingress Controller 5.6 let you turn these headers off; 5.7 lets you keep the ones the proxy in front already set.

Topology-aware routing to the nearest endpoints

What’s new: A new -enable-topology-aware-routing flag, controller.enableTopologyAwareRouting in the Helm chart, makes NGINX Ingress Controller honor a Service’s spec.trafficDistribution. With it on, each controller pod reads the topology hints Kubernetes writes onto EndpointSlices and sends traffic only to the endpoints on its own node (PreferSameNode) or in its own zone (PreferSameZone or PreferClose), by the same rules kube-proxy uses. Where the hints don’t allow that, it falls back to every ready endpoint, as it does today. The flag is off by default and covers VirtualServer, VirtualServerRoute, Ingress, and TransportServer upstreams. Started by community contributor mrak (nginx/kubernetes-ingress#9909) and finished by the team (nginx/kubernetes-ingress#11016).

Why it matters: Traffic that stays in the zone it arrived in avoids cross-zone data transfer charges and the latency that comes with them. Until now the only way to get zonal routing was use-cluster-ip, which hands load balancing to kube-proxy and gives up NGINX Ingress Controller’s own upstream features. Each controller pod routes within its own zone, so spread your replicas across zones roughly in proportion to your client traffic.

More than one Service in front of a single controller

What’s new: The Helm chart takes a new controller.service.additionalServices map. Each entry, keyed by the Service’s name, adds another Service that selects the same controller pods, with its own type, ports, annotations, labels, load balancer settings, traffic policy, IP families, external IPs, and session affinity. They render independently of controller.service.create, so you can define every Service explicitly. The chart rejects an ExternalName type, missing ports, invalid names, and a name that collides with the main Service, and status reporting still follows the one Service named in controller.reportIngressStatus.externalService. Developed by community contributor GabboPenna (nginx/kubernetes-ingress#10478).

Why it matters: One controller can now serve HTTP and HTTPS on one load balancer address and a TransportServer’s TCP listener on another, each with its own annotations and source ranges. That used to take a second controller, or a Service manifest kept outside the chart with the controller’s selector labels copied in by hand.

Trace context and latency buckets you can tune

What’s new: Two settings for running NGINX Ingress Controller with OpenTelemetry and Prometheus:

otel-trace-context sets how trace context is handled: The ConfigMap key sets NGINX’s otel_trace_context directive to extract, inject, propagate, or ignore, so NGINX Ingress Controller can continue the trace on an incoming request, pass its own context on to your backends, do both, or leave the headers alone. It needs otel-exporter-endpoint. Started by community contributor adberger (nginx/kubernetes-ingress#10556) and finished by the team (nginx/kubernetes-ingress#10843).
-latency-metrics-buckets sets the latency histogram’s buckets: A comma-separated list of bounds in milliseconds, also available as the controller.latencyMetricsBuckets Helm value, replaces the fixed 26 buckets of upstream_server_response_latency_ms. It needs -enable-latency-metrics, and the values must be positive and strictly ascending. The Helm chart rejects a malformed value at install, and the controller logs a warning and falls back to the default buckets for any other invalid list. Developed by community contributor bm1216 (nginx/kubernetes-ingress#10282).

Why it matters: Trace context decides whether the span NGINX Ingress Controller records joins the rest of a request’s trace or sits in a separate one. Every histogram bucket is its own time series, multiplied across each upstream, server, and status code, so fewer buckets directly cuts the series you store and pay for.

Turn HTTP/2 on or off per host

What’s new: The http2 ConfigMap key now applies once, at the http level, so it covers every server, with or without TLS. A new nginx.org/http2 Ingress annotation and a spec.http2 VirtualServer field override it per host; on a mergeable Ingress, set it on the master. On the default listeners, cleartext HTTP/2 (h2c) still follows the ConfigMap key, because NGINX takes that setting from the port’s default server. gRPC on a VirtualServer no longer requires TLS either (nginx/kubernetes-ingress#10989).

Why it matters: HTTP/2 used to be one switch for the whole controller, and it only reached TLS servers. It’s now a per-host decision, and it reaches plaintext hosts as well.

Smaller enhancements

commonLabels in the Helm chart: A chart-wide value adds your labels, such as ownership, cost center, or environment, to every resource the chart manages and to the controller pods, where cost and monitoring tools read them. Selectors are left alone, and a resource’s own extraLabels, such as controller.pod.extraLabels, wins over commonLabels on the same key. Setting a label the chart manages itself fails the render, and setting commonLabels triggers one rolling restart. Started by community contributor nxf5025 (nginx/kubernetes-ingress#8737) and finished by the team (nginx/kubernetes-ingress#10994).
Helm 4 support: The Helm chart works with Helm 4 without changes. It renders the same objects under Helm 4 as under Helm 3, so switching doesn’t restart the controller pods, and the project’s CI now runs Helm 4 (rendering nginx/kubernetes-ingress#10990, CI nginx/kubernetes-ingress#10378).
Tested on Kubernetes 1.37: NGINX Ingress Controller 5.7 is tested on Kubernetes 1.30 through 1.37. NGINX Ingress Controller 5.6 was tested through 1.36 (NGINX Ingress Controller changelog).

Stability and bug fixes

Exact-match paths on Ingress resources match again: Since NGINX Ingress Controller 5.6.0, an Ingress path with pathType: Exact was rendered as one quoted string, location "= /path", which NGINX reads as a prefix match on the literal text = /path. The location never matched a request, and the configuration still passed validation, so nothing reported the failure. That included cert-manager’s HTTP-01 solver, which serves exact-match paths. Exact paths that also carry the nginx.org/path-regex annotation, which produced a location that couldn’t match either, are handled too (nginx/kubernetes-ingress#10793).
The controller keeps running when a namespace stops being watched: When a namespace dropped out of the watched set, for example because its label no longer matched -watch-namespace-label, its informer was deleted while work for it was still queued, and picking up that work crashed the controller with a nil pointer panic. That work is now dropped cleanly. Developed by community contributor abirdZendesk (nginx/kubernetes-ingress#10791).
VirtualServer status survives other controllers’ events: After a leader election, NGINX Ingress Controller rebuilds VirtualServer, VirtualServerRoute, and TransportServer status from Kubernetes events, and it used to read events from every controller. A newer event from a policy engine such as Kyverno could set status.state to an empty string and fill reason and message with another controller’s text. Only NGINX Ingress Controller’s own events count now, and the newest of them is picked correctly. Developed by community contributor fcrespofastly (nginx/kubernetes-ingress#10230).
routeSelector no longer reloads NGINX for unchanged VirtualServers: VirtualServerRoutes matched by a selector came back in random order on every pass, so an untouched VirtualServer could look changed and trigger a reload. With 12 selector-matched VirtualServerRoutes, 30 unrelated VirtualServer updates caused 25 to 30 needless reloads. The order is now deterministic (nginx/kubernetes-ingress#10824).
A ConfigMap change during batch processing no longer outlasts the batch: When the ConfigMap changed while the controller was processing a batch of changes, it marked every configuration for regeneration and never cleared that mark once the batch finished, so later work could keep regenerating all of them and waste resources. The mark now resets when the batch ends (nginx/kubernetes-ingress#10813).
nginx.org/keepalive takes effect on minion Ingresses: In a mergeable Ingress, the annotation only worked on the master, even though each minion defines its own upstreams. Keepalive is now set per upstream, so a minion’s value applies to its own paths (nginx/kubernetes-ingress#9836).
VirtualServer warnings are reported when the configuration doesn’t change: A warning, such as two VirtualServerRoutes claiming the same path, was computed and then discarded whenever the rendered configuration was unchanged, so whether a VirtualServer reported it depended on the order you applied the resources in. Warnings now reach the status and events through a status-only update, with no reload. Developed by community contributor cestercian (nginx/kubernetes-ingress#10912).
A routeSelector that matches nothing raises a warning: A VirtualServer whose selector stopped matching any VirtualServerRoute, after a delete, an ingressClassName change, or a label removal, stayed Valid with no event while serving none of those routes. It now reports a warning, as a VirtualServer attached by name already did. Also developed by community contributor cestercian (nginx/kubernetes-ingress#10913).
client-max-body-size holds on VirtualServer routes with matches, splits, and API key policies: On a route with matches or splits, NGINX checked the request size at an internal redirecting location that had no limit set, so the 1 MB default rejected larger bodies whatever limit you had configured on the upstream or in the ConfigMap. Routes behind an API key policy hit the same check in the auth subrequest, which failed with a 500. Those internal locations now leave the check to the location that serves the request (nginx/kubernetes-ingress#11042).
Watched-namespace changes no longer race status updates: The registry of per-namespace informers is now safe to share across goroutines, so a status update can no longer come from an informer that has already stopped. The ExternalDNS and cert-manager integrations now skip a namespace that’s no longer watched, too (nginx/kubernetes-ingress#10956).
Three Helm settings work with custom resources turned off: With controller.enableCustomResources: false, the chart silently dropped controller.allowEmptyIngressHost, controller.defaultHTTPListenerPort, and controller.defaultHTTPSListenerPort from the controller’s arguments. None of them depends on custom resources, and all three are now passed regardless. Also developed by community contributor cestercian (allowEmptyIngressHost nginx/kubernetes-ingress#10832, listener ports nginx/kubernetes-ingress#10874).
The controller Service omits empty node ports: With controller.service.type set to LoadBalancer or NodePort and no node port configured, the chart rendered an empty nodePort: that Kubernetes then filled in, so GitOps tools such as Argo CD reported a permanent diff. nodePort is now rendered only when you set one. Started by community contributor josemaia (nginx/kubernetes-ingress#10340) and finished by the team (nginx/kubernetes-ingress#10998).
CORS policies reject out-of-range origin ports: The allowOrigin field of a cross-origin resource sharing (CORS) policy accepted ports outside 1 to 65535, such as https://example.com:99999, in exact and wildcard origins alike. Both are now range-checked. Started by community contributor immanuwell (nginx/kubernetes-ingress#9861) and finished by the team (nginx/kubernetes-ingress#10897).
[Enterprise only] Go clients can leave trustedCertSecret out of JWT and OIDC policies: The field is now omitempty on JWTAuth and OIDC, so a Policy built with the Go API types no longer sends an empty string that the API server rejects against the field’s pattern. JSON Web Token (JWT) and OpenID Connect (OIDC) policies need F5 NGINX Plus. Developed by community contributor SAY-5 (nginx/kubernetes-ingress#9751).

Upgrade notes

Solver Ingresses attach to a VirtualServer only as challenge routes: A cert-manager solver Ingress now attaches to a VirtualServer only when it’s in the VirtualServer’s namespace, serves a path under /.well-known/acme-challenge/, and points at a cm-acme-http-solver- Service. One that attached before from another namespace, or with a different path or backend, is now treated as an ordinary Ingress and loses the host to the VirtualServer (nginx/kubernetes-ingress#11015).
The http2 ConfigMap key reaches plaintext hosts: With http2: "true", an HTTP/2 request to a plaintext host used to be refused with 421 Misdirected Request, because the key only reached TLS servers. It’s now served. HTTP/1.1 clients are unaffected (nginx/kubernetes-ingress#10989).
status.referencedBy on a VirtualServerRoute can name several VirtualServers: It’s now a comma-separated list of every VirtualServer that references the route, including any that lost a host collision. If you parse it, expect more than one name (nginx/kubernetes-ingress#10925).

Community recognition

NGINX Ingress Controller is built in the open, and every release carries work from people outside the team. Whether you sent a pull request, tested a fix, or helped shape a feature, thank you!

Community contributions

Eleven community members had work land in NGINX Ingress Controller 5.7: eight bug fixes and five features. Every one of them is credited above, next to the change they made. Thanks to abirdZendesk, adberger, bm1216, cestercian, fcrespofastly, GabboPenna, immanuwell, josemaia, mrak, nxf5025, and SAY-5. Your contributions in this release have helped shape NGINX Ingress Controller 5.7!

Community inspired development work

Support for cert-manager challenges behind HTTPS redirects and authentication was inspired by an earlier effort, credited in the team’s PR: indyjonesnl‘s earlier implementation. Thanks for getting this started!

The use-forwarded-headers ConfigMap key was inspired by Mohammed-suhail-devops‘s earlier implementation. We’re grateful for the contribution.

We want to give a shout-out to two contributors whose pull requests weren’t merged, because an alternative solution shipped instead. Chupaka‘s pull request tackled how the Helm chart renders nodePort on the controller Service, which the node port fix in Stability and bug fixes solves a different way. elliott-logrocket‘s pull request tackled exact-match Ingress paths that carry the nginx.org/path-regex annotation, which the exact-match path fix in Stability and bug fixes now covers. Thank you both for the time you put in.

Get your name in NGINX Ingress Controller 5.8

Fix a bug, pick up an open issue, or bring a feature you’ve built. The contributing guide covers the rest.

Your pull request also stays open while it waits for review. The repository’s stale bot used to mark every pull request stale after 90 days without activity and close it 10 days later. Pull requests labeled community are now exempt, except one waiting on its author after a maintainer has replied, which is marked stale after 30 days and closed 14 days later (nginx/kubernetes-ingress#10951).

Also in this release: Features that need an F5 NGINX Enterprise solution

These changes need NGINX Plus, F5 WAF for NGINX, or F5 DoS for NGINX. For more information, check the F5 DevCentral release article.

Dynamic weight changes reach the right split: With -weight-changes-dynamic-reload, NGINX Ingress Controller writes a split’s new weights to NGINX Plus key-value zones instead of reloading NGINX. When more than one route-level split changed at once, a later update could land in another split’s zone or be dropped with only a warning, and VirtualServerRoutes with the same name in different namespaces could take each other’s updates, misrouting traffic until the next full reload. Weight changes are now processed on the controller’s sync queue rather than in its event handler, and a change that isn’t only to weights, such as a label change on a VirtualServerRoute, gets a full configuration update (route-level splits nginx/kubernetes-ingress#10825, same-named VirtualServerRoutes nginx/kubernetes-ingress#10830, sync queue nginx/kubernetes-ingress#10822).
F5 WAF for NGINX stays out of authentication subrequests: F5 WAF for NGINX doesn’t support modules that make internal subrequests in a scope where it’s enabled, and authentication in NGINX Ingress Controller relies on them. When the F5 WAF for NGINX module is loaded, NGINX Ingress Controller now turns it off (app_protect_enable off) in those internal locations: the ExternalAuth target on Ingress, VirtualServer, and VirtualServerRoute resources, JSON Web Key Set (JWKS) fetches for JWT policies, API key validation, and the internal locations of both OIDC implementations (nginx/kubernetes-ingress#10588).
The F5 DoS for NGINX images ship NGINX Agent 3: The images with F5 DoS for NGINX alone, nginx-ic-dos/nginx-plus-ingress and its -ubi tag, now ship NGINX Agent 3, the version F5 NGINX One Console requires, instead of NGINX Agent 2. Images with F5 WAF for NGINX are unchanged (nginx/kubernetes-ingress#11054).
Opaque Secrets for NGINX Plus and F5 WAF for NGINX: The Opaque Secret support covered above also applies to a JWKS for JWT policies (jwk), an OIDC client secret (client-secret), the NGINX Plus license (license.jwt), and F5 WAF for NGINX bundles (nginx/kubernetes-ingress#10816).
Resource requests and limits for the IP Intelligence container: The Helm chart now accepts them for the F5 WAF for NGINX IP Intelligence container, as it already did for the enforcer and configuration manager containers, so a HorizontalPodAutoscaler can scale the controller pods (nginx/kubernetes-ingress#10848).
Go clients can leave trustedCertSecret out of JWT and OIDC policies: The fix from community contributor SAY-5 is in Stability and bug fixes above (nginx/kubernetes-ingress#9751).

Getting started with NGINX Ingress Controller 5.7

NGINX Ingress Controller 5.7 is available now as container images on Docker Hub, GitHub Container Registry, Amazon ECR Public Gallery, and Quay.io, and as version 2.8.0 of the Helm chart.

Release notes and changes: Read the full changelog.
Install and upgrade: Follow the NGINX Ingress Controller installation guide.
Documentation: Visit the NGINX Ingress Controller documentation.
Moving from Ingress-NGINX? Follow the NGINX Ingress Migration Tool guide.
Interested in NGINX’s open source Kubernetes ecosystem? Start at kubernetes.nginx.org.

Stay tuned to the NGINX Blog for more release updates and technical deep dives.

Keeping NGINX Ingress Controller up to date

NGINX Ingress Controller releases include important fixes and ongoing improvements. We encourage users to stay current with the latest version. NGINX Ingress Controller 5.7 fixes two authentication bypass vulnerabilities in external authentication, CVE-2026-94197 and CVE-2026-104939. Each CVE links to its official F5 advisory. NGINX Ingress Controller 5.7 also ships NGINX Open Source 1.31.7, up from 1.31.4 in NGINX Ingress Controller 5.6.0. Between those versions, NGINX Open Source fixed six CVEs: CVE-2026-90439 in 1.31.6, and five more in 1.31.7, listed in F5’s security notification.

To stay informed, subscribe to F5 notifications and select the relevant advisory updates.