Envoy Gateway has released v1.9.1, a maintenance release that focuses heavily on security, upgrade reliability, and operational correctness following the broader v1.9 release. Released on August 28, the update reverses one of v1.9.0‘s changes to secret and endpoint fetching, adds fixes for several security issues, and introduces more granular observability into Gateway API and xDS translation.
The most significant change concerns the initial fetch timeout used for Secret Discovery Service (SDS) and Route Discovery Service (RDS). Envoy Gateway 1.9.0 changed this timeout to zero, but the project found that a cluster waiting indefinitely for a missing Secret or endpoint could remain in a warming state, preventing CDS updates from progressing and delaying health checks. Version 1.9.1 restores Envoy’s default 15-second timeout, returning this behaviour to the v1.8.x model.
The change is more complicated for organisations already running v1.9.0. Envoy Gateway warns that changing the SDS configuration during the controller upgrade can trigger an Envoy issue affecting proxies that remain running while the new controller is deployed. In the affected scenario, TLS listeners can become active without their certificates, causing new TLS handshakes to fail. Backend TLS configurations and the global rate-limit service can experience similar certificate or CA problems.
For users on v1.8.x, the project recommends upgrading directly to v1.9.1 and skipping v1.9.0. Existing v1.9.0 deployments require more care: Envoy Gateway recommends a rolling-update configuration that replaces proxy pods quickly, although this requires sufficient cluster capacity and can terminate existing connections as pods are replaced. The release notes specifically warn that long-lived WebSocket and gRPC connections can be interrupted during replacement.
A GitHub issue from a user running Envoy Gateway in production described an outage in which long-running Envoy proxies lost their downstream TLS certificates and stopped serving HTTPS traffic, with recovery requiring manual proxy restarts. The issue linked the behaviour to the handling of new SDS subscriptions and the change to the initial fetch timeout introduced in v1.9.0.
Security is another major theme in the release. Envoy Gateway now enables AES-256-GCM for OAuth2/OIDC session-cookie encryption and removes support for the legacy AES-256-CBC decryption path, addressing the padding-oracle vulnerability identified as CVE-2026-47775. Existing sessions using the older encryption mechanism will require users to authenticate again after upgrading. Deployments using a replacement Envoy bootstrap need to explicitly configure the corresponding runtime settings.
The release also strengthens several other security boundaries. OIDC issuer URLs now receive additional validation, OCI Wasm image pulls no longer silently fall back from HTTPS to HTTP, and a security-context issue involving tenant-supplied EnvoyProxy configuration has been fixed. The latter prevented a tenant-provided Kubernetes security context from completely replacing Envoy Gateway’s hardened defaults, which could otherwise allow restrictions such as privileged execution or running as root to be removed.
The Wasm changes are particularly relevant to supply-chain security. Previously, an OCI registry that rejected an HTTPS request could cause Envoy Gateway to fall back to plain HTTP, potentially allowing an on-path attacker to provide arbitrary Wasm code. Version 1.9.1 removes that implicit fallback; HTTP is now permitted only where a registry has explicitly been configured as insecure.
Several fixes address less visible but important controller and traffic-management behaviour. OIDC flow cookies are now scoped to the redirect path, reducing unnecessary propagation of abandoned authentication cookies. Namespace label changes are now automatically watched so that route acceptance can be re-evaluated without restarting the controller. The release also fixes hostname-conflict handling, controller crashes involving missing optional CRDs, and incorrect behaviour when consistent hashing is configured for UDP routes.
The release also improves the global rate-limit integration by using Kubernetes Service and EndpointSlice information through EDS rather than relying solely on static DNS resolution. This allows requests to continue reaching the appropriate rate-limit service replicas as they scale, while retaining the previous DNS-based behaviour as a fallback when the service or endpoints cannot be discovered.
One of the quieter changes may prove useful for platform engineering teams. Envoy Gateway now adds per-phase tracing spans to Gateway API and xDS translation. Rather than seeing a slow translation as a single opaque operation, operators can identify where processing time is being spent across listener processing, HTTP and gRPC routes, policy processing, EnvoyPatchPolicy handling, extension hooks, and xDS validation.
Envoy Gateway 1.9.1 is therefore more than a collection of routine fixes. The release illustrates some of the operational complexity that comes with running a Kubernetes-native gateway at scale: configuration changes can affect live proxy state, security boundaries extend into Wasm and tenant-controlled resources, and control-plane performance increasingly needs its own telemetry.
For teams evaluating or already running Envoy Gateway, the upgrade path matters. v1.8.x users can move directly to v1.9.1, while v1.9.0 users should pay particular attention to the documented proxy replacement strategy and TLS impact before upgrading. The release itself is available as v1.9.1, with the project’s documentation providing the detailed upgrade and configuration guidance.