v1.9.1

Date: August 28, 2026

Breaking changes

• Reverted the 0s initial fetch timeout for SDS and RDS that was added in v1.9.0 (PR 9532), because a cluster waiting on a missing secret or endpoint with no timeout never left warming, which paused CDS updates for the whole proxy and kept its health checks from starting (issue 9687). Both now use Envoy’s default 15-second timeout again, as in v1.8.x.
• Upgrade note for v1.9.0 users only: reverting this changes the SDS configuration in every generated listener and cluster, which triggers an Envoy bug (https://github.com/envoyproxy/envoy/issues/47309) on proxies that are still running when the upgraded controller starts. About 15 seconds after the new controller pushes configuration, TLS listeners go active without certificates and every new TLS handshake fails. The same applies to clusters that use BackendTLSPolicy, Backend TLS, or the global rate limit service: they lose their CA and client certificates and requests to them fail. The pods still report Ready. Plain HTTP routing is unaffected, but existing connections on the affected listeners are drained and closed within shutdown.drainTimeout (60s by default). This lasts until the pod is replaced or the affected Secret is pushed again. Proxies started fresh on the new version are not affected.
• Users on v1.8.x should upgrade directly to v1.9.1 and skip v1.9.0; that path is not affected. Users on v1.9.0 should shorten the time old proxy pods keep running next to the new controller: before upgrading, set envoyDeployment.strategy (or envoyDaemonSet.strategy) in the attached EnvoyProxy to {type: RollingUpdate, rollingUpdate: {maxSurge: 100%, maxUnavailable: 0}} so every replacement pod starts at once and the old pods are removed as soon as the new ones are Ready. This needs cluster capacity for twice the proxy replicas, and the old pods still fail TLS for roughly the time the new pods take to become Ready; a one-at-a-time rollout multiplies that.
• Warning: replacing a proxy pod closes every connection it holds. The pod goes through the normal graceful drain (shutdown.drainTimeout, 60s by default), so requests that finish within the drain complete, but anything still open at the end, including WebSockets and gRPC streams, is cut. Weigh that against replacing all pods at once.
• A proxy in this state logs initial fetch timed out for ...tls.v3.Secret. To find pods that need replacing, alert on envoy_sds_init_fetch_timeout > 0; the counter stays set for the life of the process. To see whether TLS termination is still failing, alert on increase(envoy_listener_server_ssl_socket_factory_downstream_context_secrets_not_ready[5m]) > 0, which rises for every handshake rejected because the certificate is not loaded. Pushing a Secret again, for example by rotating it, restores whatever uses that Secret without a restart; replacing the pod fixes everything at once.
• The watchable_subscribe_duration_seconds histogram bucket boundaries changed from {0.001, 0.01, 0.1, 1, 5, 10} to {0.005, 0.025, 0.1, 0.25, 0.5, 1, 2, 4, 8, 15, 30, 60, 120} to improve latency resolution. The metric name and its _sum/_count series are unchanged, but _bucket series with le="0.001", le="0.01", le="5", and le="10" are no longer emitted; le="0.1" and le="1" remain available. Update any dashboard, alert, or recording rule that references the removed boundaries directly. Queries that aggregate dynamically by le, such as histogram_quantile(), do not require changes.
• HTTP is no longer supported as an OIDC issuer URL scheme.
• OCI Wasm image pulls now require the registry to serve HTTPS. The implicit fallback to plain HTTP has been removed, so a Wasm extension backed by a plain HTTP registry will fail to load unless that registry is explicitly configured as insecure.

Security updates

• Enabled AES-256-GCM encryption for OAuth2/OIDC session cookies and disabled the legacy AES-256-CBC decryption path in the Envoy proxy bootstrap, addressing the padding oracle in CVE-2026-47775. Existing OIDC sessions were encrypted with AES-256-CBC and are no longer accepted, so users with an active session are redirected to re-authenticate once after upgrading. This is set in the default bootstrap, so an EnvoyProxy using spec.bootstrap with type Replace (the default when no type is given) does not receive it; OIDC users with a replacement bootstrap must add envoy.reloadable_features.oauth2_use_gcm_encryption: true and envoy.reloadable_features.oauth2_legacy_cbc_decrypt_compat: false to a layered_runtime static layer themselves.
• Added validation for the OIDC issuer URL configured in SecurityPolicy.
• Fixed a nil pointer dereference in SecurityPolicy translation for TCPRoutes: a listener with no corresponding xDS IR entry (for example, a Gateway listener marked Conflicted for sharing a port with another listener) could panic the control plane during translation, silently dropping that reconcile’s IR and status publication.
• Fixed a confused-deputy/PSA-escape issue (GHSA-w42f-28h3-998w) where a tenant-supplied KubernetesContainerSpec.SecurityContext on an EnvoyProxy replaced Envoy Gateway’s hardened default SecurityContext outright instead of merging on top of it, allowing a tenant whose EnvoyProxy is materialized in the shared controller namespace to drop restrictions (e.g. run privileged or as root) that the controller namespace’s Pod Security Admission would otherwise enforce.
• Fixed a control-plane availability issue in EnvoyExtensionPolicy Wasm OCI permission handling.
• Fixed OCI Wasm image pulls silently downgrading to plain HTTP when the registry rejected the HTTPS request, which allowed an on-path attacker to serve arbitrary Wasm code to the Envoy proxies. Plain HTTP is now used only for registries that are explicitly configured as insecure.

New features

Bug fixes

• Fixed OIDC flow-state cookies accumulating in the browser and overflowing the request header size limit. Envoy mints a nonce (CSRF) and a PKCE code verifier cookie for every authorization flow it starts, but only deletes the pair belonging to the flow that completes the callback, so flows that are abandoned - parallel requests from a logged out browser, a user navigating away from the provider’s login page - leave their cookies behind until they expire. Envoy Gateway now scopes both cookies to the OIDC redirect path, the only path where Envoy needs their value, so any orphans are no longer sent on every request. Note this bounds the damage rather than eliminating it: orphans are still sent to the callback endpoint itself until they expire, and logout can no longer purge them early because the browser no longer sends them to the signout path, so also consider lowering csrfTokenTTL. The PKCE code verifier cookie is also now named CodeVerifier-<suffix>, carrying the same per-policy suffix as the other OAuth2 cookies instead of Envoy’s shared default, so SecurityPolicies on the same cookie domain no longer delete each other’s in-flight flow cookies on logout. On upgrade, a browser already holding flow cookies keeps them at the old path=/, since the new deletion headers are scoped to the redirect path. They expire on the lifetime they were originally issued with - 10 minutes by default, and unaffected by any csrfTokenTTL you configure during the upgrade. The old code verifier cookie name is also no longer read, so a login that was in progress across the rollout may need to be retried once.
• Fixed HTTPRoute (and other xRoute) acceptance not being re-evaluated when a namespace’s labels changed to newly match, or stop matching, a Gateway listener’s allowedRoutes.namespaces.from: Selector, requiring a controller restart to pick up the change. Envoy Gateway now watches Namespace label updates and re-reconciles affected Gateways automatically.
• Fixed HTTPRoutes attached to a listener that won a hostname conflict being rejected with NoMatchingListenerHostname and omitted from xDS by excluding conflict-losing listeners from route hostname filtering.
• Fixed the controller crash-looping when an extension manager’s backendResources references a CRD that is not installed in the cluster. The CRD existence is now checked once at controller startup and cached in a field on the reconciler, following the same pattern already used for ServiceImport, Backend, and other optional CRDs. When the CRD is absent, both the watch and the reconcile list path are skipped; all other errors from the list call are returned so the reconcile is retried instead of publishing an incomplete resource snapshot.
• The global rate limit cluster is now built from the in-cluster envoy-ratelimit Service/EndpointSlices using EDS instead of resolving a static DNS hostname, so requests keep hitting rate limit service replicas correctly as they scale up or down. When the Service or its endpoints can’t be discovered, Envoy Gateway falls back to the previous STRICT_DNS behavior.
• Fixed the File and ALS access log sinks silently falling back to the default JSON fields when telemetry.accessLog.settings[].format sets text without type, which the API accepts.
• Fixed a BackendTrafficPolicy setting a ConsistentHash load balancer having no effect when it targets a UDPRoute. The cluster was configured with Maglev, but no hash policy was set on the UDP proxy listener filter, so Envoy had no hash key to compute and fell back to picking an upstream host at random for every UDP session. The source IP hash policy is now configured on the UDP proxy. Only the SourceIP consistent hash type applies to UDP, since headers, cookies and query parameters do not exist in a UDP datagram.
• Fixed controller panic when translating backend credential injection with an invalid header.
• Fixed the Wasm image permission cache key omitting the CA certificate, which allowed a permission check result to be reused across different TLS trust configurations.

Performance improvements

• Improved reconcile performance by listing the extension manager’s resources and backendResources once per GatewayClass instead of once per Gateway.

Deprecations

Other changes

• Added per-phase tracing spans to the Gateway API and xDS translators, each recording the size of the input it processed, so that a slow translation can be attributed to a specific phase — listener processing, HTTP and gRPC route processing, the main policy types, EnvoyPatchPolicy JSON patches, extension server hooks, and xDS resource validation — instead of showing up as one opaque multi-second span.