NGINX Gateway Fabric 2.6 marks our initial foray into implementing enterprise grade security capabilities into the Gateway API standard. This release brings F5 WAF for NGINX support to a Gateway API implementation, making NGINX Gateway Fabric one of the first Gateway API implementations to offer enterprise-grade WAF capabilities natively. Here’s what else is new:

F5 WAF for NGINX Support

What’s new?: NGINX Gateway Fabric now supports F5 WAF for NGINX. SecOps teams can build and compile WAF policies that can be applied to Gateways and HTTPRoutes, with NGINX Gateway Fabric fetching policies through NGINX One Console, NGINX Instance Manager, or an HTTP endpoint. This first phase introduces the ClickOps flow, allowing NGINX Gateway Fabric to retrieve and enforce WAF policies and signatures within Kubernetes. Policies can be compiled through the management plane, or compiled using the F5 WAF compiler and made available through an HTTP endpoint.

Why it matters?: SecOps teams can own and manage policies through the tools they already use, while application teams keep moving fast. This flexible retrieval model meets teams where they are, whether that’s a centralised SecOps team managing policies through NGINX One Console or a more distributed setup.

ListenerSet Support

What’s new?: NGINX Gateway Fabric now supports ListenerSet, a Gateway API type that allows additional listeners to be specified for a Gateway. This decouples listener configuration (ports, hostnames, TLS termination) from the central Gateway resource, enabling multiple teams to manage their own listeners without touching the shared Gateway.

Why it matters?: In multi-team environments, a single shared Gateway quickly becomes a bottleneck. ListenerSet gives application teams autonomy over their own TLS certificates and routes while keeping the core Gateway infrastructure centrally managed.

FrontendTLS Support for Client-Side mTLS

What’s new?: The release adds FrontendTLS support, enabling mutual TLS on the client side for inbound traffic at the Gateway layer.

Why it matters?: mTLS is a cornerstone of zero-trust networking. Having it available natively at the Gateway removes the need for workarounds and gives teams a clean, Kubernetes-native way to enforce strong identity and authentication requirements.

Expanded ProxySettings Policy Support

What’s new?: Additional NGINX directives have been added to the ProxySettings Policy CRD, including proxy_read_timeout, proxy_connect_timeout, and proxy_send_timeout — settings that previously required NGINX snippets.

Why it matters?: Snippets work, but they’re hard to audit, version, and govern at scale. Moving these settings into native Kubernetes manifests makes them visible, manageable, and consistent across your fleet.

What’s new?: You can now set NGINX variables in the RequestHeaderModifier, giving teams more flexibility when modifying request headers as part of Kubernetes-native traffic management. This is useful for adding trace or debug headers, passing variables like real client IP or request ID to backends, and handling complex routing patterns.

Why it matters?: Header manipulation is one of those things that sounds simple but quickly gets complicated in real environments. Native NGINX variable support here closes a gap that previously pushed teams toward custom snippets or external solutions.

Stability and Bug Fixes

This release also includes multiple stability improvements and bug fixes. Head over to the GitHub release page and our public release docs for the full picture. You can also follow this link to upgrade NGINX Gateway Fabric, and check out the new Kubernetes NGINX landing page to learn more about migrating from NGINX Ingress Controller to NGINX Gateway Fabric.

We’re proud of what the team put together here, and we can’t wait to share it with the community and our customers.