リリース

v2.12.9 is a dense bug-fix release targeting JetStream stability — covering Raft correctness, consumer state corruption, and filestore encryption bugs that could silently corrupt data.

• securityUpdate: golang.org/x/crypto bumped to v0.51.0

  The x/crypto dependency was updated alongside Go 1.25.10. If your org tracks CVEs against transitive dependencies, verify your SBOM tooling picks this up. Upgrade to v2.12.9 to pull in the patched crypto library — there's no workaround at the application level.

• breakingEncrypted JetStream users must upgrade — filestore corruption risk

  A bug in filestore encryption mode conversion could cause block-level corruption when switching encryption settings (PR #8105, #8166). If you've ever changed encryption mode on an existing stream, inspect those streams after upgrading. If corruption already occurred, you'll need to restore from a pre-conversion snapshot.

• enhancementUse the new /varz client traffic metrics for capacity planning

  The four new metrics (in/out_client_msgs and in/out_client_bytes) let you separate actual client-facing load from internal cluster/leafnode traffic. Wire these into your Prometheus scrape now — they're directly useful for right-sizing clusters and spotting noisy clients without needing to parse per-connection data.

Emissary-Ingress v4.1.0 ships Envoy 1.37.2 and fixes a stale cache bug that caused Istio mTLS cert rotation to silently fail.

• securityReview Envoy 1.37.x release notes before upgrading

  This upgrade spans Envoy 1.37.0 through 1.37.2, which includes security patches and potentially deprecated xDS fields. Pull up the Envoy 1.37.0, 1.37.1, and 1.37.2 changelogs and scan for any deprecated API fields or behavior changes that match your current Mapping/Ambassador configs before rolling out to production.

• breakingStale config cache fix may change startup behavior

  The IR.check_deltas fix now triggers a full reconfigure when an empty-delta snapshot arrives with a cached state. In practice this means Emissary will re-push config to Envoy in scenarios where it previously did nothing. If you have automation or health checks that depend on the old (broken) quiet behavior during cert rotation windows, validate them in staging first.

• enhancementUpgrade if you run Emissary alongside Istio

  If your cluster uses Istio and Emissary together, this fix directly addresses mTLS cert rotation failures (issue #4744). Stale certificates staying in the cache caused silent connectivity breakage during rotation events. Upgrading to v4.1.0 should eliminate those intermittent failures without any config changes on your part.

Istio 1.30 ships experimental AI-focused agentgateway, ambient mode CIDR support, a new TrafficExtension API, and tightened debug endpoint auth that breaks existing setups.

• breakingDebug endpoint auth is on by default — audit your tooling now

  Port 15010 XDS debug endpoints now enforce authentication with ENABLE_DEBUG_ENDPOINT_AUTH=true as the default. Any internal tooling, dashboards, or scripts hitting syncz or config_dump without credentials will start failing after upgrade. Before upgrading, inventory everything that talks to port 15010 and either add auth or explicitly allowlist namespaces via DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES.

• breakingStart migrating off WasmPlugin to TrafficExtension API

  TrafficExtension is now the primary extensibility API, replacing WasmPlugin. WasmPlugin isn't being removed immediately, but new features will land in TrafficExtension first. If you run Wasm extensions in production, plan a migration window and test TrafficExtension parity before 1.31 hardens the deprecation.

• enhancementUse CIDR ServiceEntry in ambient mode to simplify external IP routing

  Previously, ambient mode required enumerating individual IP endpoints in ServiceEntry. CIDR support means you can now cover entire subnets — useful for external databases, on-prem services, or shared infrastructure with dynamic IPs. If you've been maintaining large lists of individual endpoints, consolidate them now and reduce operational overhead.

Istio 1.29.3 patches two security vulnerabilities — an AuthorizationPolicy bypass and a cross-namespace XDS config leak — alongside a multicluster deadlock fix and AWS EKS ambient mesh probe fix.

• securityAudit AuthorizationPolicy rules using suffix-match principals or namespace selectors — patch immediately

  Regex metacharacters (., [, etc.) in source.principals and source.namespaces were embedded into Envoy SafeRegex unescaped. This means a policy allowing 'spiffe://cluster.local/ns/foo/sa/bar.admin' could inadvertently also match 'spiffe://cluster.local/ns/foo/sa/barXadmin'. Any service with suffix-based wildcard principal matching is potentially affected. Upgrade to 1.29.3 and review policies where principals or namespace values contain dots, brackets, or other regex metacharacters.

• securityRotate access controls on XDS debug endpoints — any authenticated workload could read cross-namespace configs

  The /debug/syncz and /debug/config_dump endpoints served by StatusGen had no namespace boundary enforcement. An authenticated workload in namespace A could enumerate and read Envoy configs of workloads in namespace B. If you run multi-tenant clusters or expose istiod debug endpoints, assume cross-namespace config data may have been accessible. Upgrade immediately and audit who has accessed these endpoints via your API server audit logs.

• breakingMulti-cluster operators: the secret controller deadlock fix may change behavior during cluster updates

  The deadlock in the multicluster secret controller was triggered during remote cluster updates. If your control plane has been experiencing hangs or stalls in multi-cluster scenarios, this fix resolves the root cause — but test your cluster join/leave workflows after upgrading to confirm expected behavior is restored.

Istio 1.28.7 was released, but the published notes are too brief to summarize. See the original release notes for details.

Native sidecars promoted to GA and enabled by default, plus a security fix restricting Server resources from affecting workloads outside their namespace. Heavy dependency refresh across Rust and Go stacks.

• securityServer namespace isolation fix — review cross-namespace Server resources immediately

  A fix was applied so that Server resources can no longer affect workloads in namespaces other than their own. If you have intentionally or accidentally created Server policies that were influencing workloads cross-namespace, those policies will silently stop applying after this upgrade. Audit your Server resources across all namespaces and verify that authorization policies still behave as expected post-upgrade. The risk of misconfigured over-broad policies is reduced, but any reliance on the previous behavior will break.

• breakingNative sidecars are now on by default — audit your cluster before upgrading

  Native sidecar support (using Kubernetes init containers with restartPolicy: Always) is now GA and enabled by default. If your cluster runs Kubernetes < 1.29, native sidecars are unsupported and this will break injection. Even on supported versions, verify that any tooling, admission webhooks, or pod lifecycle assumptions in your workloads are compatible. Test in a staging environment before rolling out to production. If you need the old behavior, explicitly disable the feature flag during install/upgrade.

• enhancementConfigure honorTimestamps on the linkerd-proxy PodMonitor

  If you're using the Prometheus Operator and have timestamp alignment issues in your Linkerd proxy metrics (e.g., stale or out-of-order samples), you can now set honorTimestamps in the Helm chart for the linkerd-proxy PodMonitor. This is a quality-of-life win for teams with strict metric ingestion pipelines. Set it explicitly during your next Helm upgrade rather than leaving it at the default.

Cilium v1.19.4 is a stability-focused patch release with 20+ bug fixes covering crash prevention, IPsec reliability, and Cluster Mesh correctness — upgrade if you run any of those features.

• securityUpdate moby/spdystream dependency (security fix included)

  This release bumps github.com/moby/spdystream to v0.5.1 as a security fix. The dependency is used in Kubernetes API communication paths. No CVE number is listed in the release notes, but treat this as a prompt to upgrade — staying on v1.19.3 leaves the exposure open.

• breakingHand-managed EndpointSlices need service-proxy-name label added

  If you set --k8s-service-proxy-name and manage EndpointSlices manually, those slices will now be filtered OUT at the watch level unless they carry the matching service.kubernetes.io/service-proxy-name label. After upgrading, any untagged hand-managed slice becomes invisible to Cilium, causing traffic drops. Audit your EndpointSlices before upgrading and stamp the label on any that are missing it.

• enhancementPrioritize upgrade if you run IPsec, WireGuard, or Cluster Mesh

  Three distinct data-plane reliability fixes land here: IPsec packet drops during rolling key rotation, WireGuard silent packet loss under constrained MTU with IPv6, and Cluster Mesh missing backends for multi-port services. Any of these can cause hard-to-diagnose intermittent connectivity issues. If your environment uses any of these features, this patch should move to the front of your upgrade queue.

v1.17.16 patches a cross-namespace traffic hijacking vulnerability in CiliumLocalRedirectPolicy, fixes an IPsec panic on malformed input, and resolves a static pod identity resolution bug.

• securityAudit LRP addressMatcher configs before upgrading

  The LRP addressMatcher change fixes a real attack vector: a policy in one namespace could previously override a Service frontend and redirect traffic cross-namespace. After upgrading, any LRP that was relying on this override behavior will stop working silently — traffic won't redirect as expected. Before upgrading, audit your CiliumLocalRedirectPolicy objects for addressMatcher entries that overlap with existing Service frontends. If you legitimately need the old behavior, set --enable-lrp-address-matcher-override=true, but treat that as a temporary measure and redesign the policy.

• securityUpgrade if running IPsec — agent crash risk on malformed input

  The parseSPI panic means a malformed IPsec packet could crash the Cilium agent, taking down networking on that node. This is a low-complexity denial-of-service risk for any cluster using Cilium's IPsec transparent encryption. Upgrade to v1.17.16 promptly if IPsec is enabled in your environment.

• breakingLRP addressMatcher behavior change is not fully backward-compatible

  This is a behavior change, not just a bug fix. If you have CiliumLocalRedirectPolicies using addressMatcher that overlap with Service ClusterIPs or external IPs, those policies will now be rejected or ignored where they previously worked. Test your LRP configurations in a non-production environment before rolling this upgrade out. The opt-in flag --enable-lrp-address-matcher-override=true exists, but using it means you are accepting the previously-vulnerable behavior.

Cilium v1.18.10 is a stability-focused patch release fixing agent crashes, IPsec panics, Cluster Mesh backend gaps, and a data race in IPAM — all backported from upstream.

• securitymoby/spdystream and x/net security updates are included

  This release pulls in a security fix for github.com/moby/spdystream and bumps x/net to v0.53. Both are network-layer dependencies. If your policy or threat model tracks transitive dependency CVEs, this patch justifies the upgrade on its own.

• breakingUpgrade encrypted clusters to fix IPsec panic risk

  A panic in parseSPI on malformed IPsec input could crash the agent on nodes running encrypted traffic. If you use IPsec encryption, treat this as a priority upgrade — a malformed packet or misconfigured peer can take down the agent process entirely.

• enhancementCluster Mesh users with shared target ports should upgrade

  The missing global service backends bug silently dropped backends from services where multiple ports mapped to the same target port. Traffic would route correctly within a single cluster but fail cross-cluster. Upgrade and verify affected services post-rollout using hubble observe or service endpoint inspection.

A routine edge release dominated by dependency bumps, with two meaningful bug fixes: multicluster service cleanup now respects namespaces, and a CLI gateway API version correction.

• securityRust TLS stack updated — aws-lc-rs, rustls-webpki, rustls-pki-types all bumped

  Several TLS-adjacent crates were updated in one shot: aws-lc-rs 1.16.3, rustls-webpki 0.103.13, and rustls-pki-types 1.14.1. No CVEs are called out explicitly, but these are the cryptographic underpinnings of Linkerd's mTLS. If you're in a security-sensitive environment, this is a good reason to pull this edge over older ones.

• breakingKubernetes 1.31 is now the minimum supported version

  The MSKV bump to 1.31 means clusters running 1.30 or older are no longer in the supported envelope. Check your cluster versions before adopting this edge release — if you're still on 1.30, upgrade Kubernetes first or hold on this Linkerd edge.

• enhancementFix multicluster namespace-scoped service cleanup before upgrading

  If you run Linkerd multicluster and have services spread across multiple namespaces, the previous cleanup logic could operate beyond its intended namespace scope. This fix is a correctness improvement — after upgrading, verify your mirrored services are in the expected state, especially if you've seen unexpected service deletions or stale mirrors in non-default namespaces.

NATS v2.14.0 (skipping 2.13.x) brings JetStream scheduling, fast-ingest batch publishing, consumer reset API, and critical Raft data-loss fixes. Review the upgrade guide before deploying.

• breakingRead the 2.14 Upgrade Guide — 2.13.x was skipped

  This release jumps from 2.12.x to 2.14.x. The upgrade guide covers backwards compatibility breaks you must address. If you use ACLs on JetStream ACK or flow control subjects, the new domain-aware format ($JS.ACK.domain.acchash.stream.consumer.>) is disabled by default now but becomes the default in v2.15 — start updating your ACL rules now so the v2.15 upgrade isn't a fire drill.

• breakingRaft startup now fails on corrupt/missing snapshots — test your recovery procedures

  Previously, a node with a corrupt or misaligned snapshot might start silently with bad state. Now it refuses to start. This is the right behavior, but if you have any clusters with questionable disk health or have experienced unclean shutdowns, validate your snapshot integrity before rolling this upgrade out. Ensure your ops runbook covers the recovery path for this scenario.

• enhancementConsumer Reset API removes a painful operational pattern

  Rewinding a consumer previously meant deleting and recreating it — disruptive and error-prone. The new $JS.API.CONSUMER.RESET API lets you move a consumer back to an earlier sequence in place. If you maintain any tooling or runbooks that handle consumer rewind or replay scenarios, update them to use this API. It's also useful for incident recovery workflows.

Strimzi 1.0.0 drops all pre-v1 CRD APIs — this is a hard requirement before upgrading. Also adds Kafka 4.1.2 support, TLS on the HTTP Bridge, and environment-variable-based rack awareness.

• breakingConvert all CRDs to v1 API before upgrading — no exceptions

  Strimzi 1.0.0 flat-out removes v1beta2, v1beta1, and v1alpha1. If any of your custom resources still use those API versions, the operator will not reconcile them after upgrade. Run the CRD conversion procedure documented by Strimzi before touching anything else. This applies to KafkaTopic and KafkaUser resources too, which had their own v1alpha1/v1beta1 versions. Skipping this step will break your cluster management silently.

• enhancementSwitch rack awareness to environment-variable type to drop ClusterRoleBindings

  The new type: environment-variable rack awareness reads topology from env vars rather than querying the Kubernetes API, which means it no longer needs ClusterRoleBindings. If you're running in environments with tight RBAC policies or multi-tenant clusters, this is worth migrating to. Review your Kafka CR's rack configuration and update the type field — no other infrastructure changes needed.

• enhancementUseConnectBuildWithBuildah is now on by default — verify your Connect build pipelines

  This feature gate moving to beta means Buildah is now the default build tool for Kafka Connect connector builds. If you've been relying on Kaniko-specific behavior or have custom build configurations, test your Connect builds in a non-production environment after upgrading. The Buildah image is pinned in the release, so the toolchain is stable, but behavioral differences in layer caching or registry auth handling could surface.

NATS v2.12.8 is a substantial bug-fix release targeting JetStream stability — particularly clustered stream/consumer reliability, Raft edge cases, and a bearer JWT disclosure vulnerability in the monitoring API.

• securityPatch immediately: /connz was leaking bearer JWTs

  Any deployment using JWT-based auth with the monitoring endpoint exposed (even internally) was potentially leaking bearer tokens in /connz responses. Rotate any JWTs that may have been exposed, audit monitoring endpoint access logs, and upgrade to v2.12.8 now. If you can't upgrade immediately, restrict /connz access via firewall or NATS monitoring auth.

• securityCLI argument secrets now redacted in monitoring

  Route and cluster URLs passed as CLI arguments (which often contain credentials) were previously visible in monitoring output. Upgrade to v2.12.8 and review any monitoring dashboards or log aggregation pipelines that may have captured this data historically.

• enhancementJetStream cluster operators: test your scaling and recovery paths

  This release fixes several nasty edge cases — stream leader catch-up from snapshots, Raft commit index resets on term mismatches, in-flight assignment visibility for stream/consumer info, and the 'last sequence mismatch' error from failed proposals. If you've been seeing any of these intermittent errors in clustered JetStream, v2.12.8 is a high-priority upgrade. After upgrading, monitor for reduced error rates in stream info and consumer info endpoints during scaling operations.

NATS v2.11.17 is a security and stability patch addressing JWT bearer token exposure in monitoring endpoints, credential redaction gaps, and several crash/correctness bugs.

• securityPatch immediately: /connz was leaking bearer JWTs

  Any operator exposing the NATS monitoring port (default 8222) to internal or external networks should treat this as urgent. Bearer tokens visible in /connz could be harvested and replayed. Rotate any JWTs that may have been exposed, audit who had access to your monitoring endpoints, and upgrade to 2.11.17 now. If you cannot upgrade immediately, firewall the monitoring port.

• securityCLI-embedded secrets were visible in monitoring output

  If your NATS deployment passes route or cluster URLs with embedded credentials as command-line arguments, those secrets were previously visible in monitoring output. Audit your monitoring data for any historical exposure, rotate affected credentials, and upgrade. Long-term, prefer config files or environment-based secret injection over CLI arguments.

• breakingRepeated CONNECT behavior change may affect edge-case clients

  The fix for repeated CONNECT messages clearing subscriptions changes previously tolerated (but incorrect) behavior. Custom clients or unusual connection patterns that send multiple CONNECT messages on the same connection could see subscriptions unexpectedly dropped. Audit any non-standard client code before upgrading in production.

Maintenance-heavy edge release with OpenSSL/rustls security bumps, a policy admission fix for Gateway routes, and a more robust annotation-to-metric-label conversion in the injector.

• securityPick up OpenSSL and rustls-webpki patches now

  Two OpenSSL crate bumps landed in this release, plus a rustls-webpki update. These sit in the proxy's TLS stack. If you're running any Linkerd edge build in a security-sensitive environment, upgrade to edge-26.4.4 to get the patched cryptographic dependencies rather than waiting for the next stable.

• breakingVerify Gateway route policies after the admission webhook fix

  The admission webhook previously ran full validation on Gateway routes even when they contained fields Linkerd doesn't support, causing legitimate routes to be rejected. That's fixed now — but if you worked around this by restructuring routes, review whether those workarounds are still needed or are now masking misconfigurations.

• enhancementTest chart override behavior if you use custom install values

  The fix to apply overrides to chart values on install closes a gap where certain Helm value overrides weren't being applied. If you have installation automation that relies on specific override patterns, run a dry-run install against this version to confirm the resulting values match expectations before rolling to production.

Envoy v1.38 is a massive release with several breaking changes requiring immediate action — RSA key usage enforcement, BoringSSL build flag changes, and tcp_proxy config validation are the top priorities before upgrading.

• securityPatch CVE-2026-27135 by upgrading to v1.38

  This release includes the nghttp2 patch for CVE-2026-27135, which affects HTTP/2 header field handling. If you're running Envoy as an HTTP/2 gateway or proxy, this is a direct exposure. Prioritize upgrading clusters that terminate or proxy HTTP/2 traffic. RBAC header matcher also received a fix preventing concatenation-based bypass attacks — another reason to treat this upgrade as security-relevant.

• breakingAudit TLS configs before upgrading — RSA key usage now enforced

  enforce_rsa_key_usage defaults to true starting this release and will be removed entirely next release, making it permanent. Any upstream TLS connection where the certificate's key usage doesn't match the negotiated cipher will be rejected. Before upgrading, audit your upstream certificate configurations. Test in staging first — silent failures in prod will be connection resets, not helpful error messages.

• breakingUpdate BoringSSL FIPS build pipelines before building v1.38

  The --define=boringssl=fips Bazel flag is gone. CI/CD pipelines or Dockerfiles that build Envoy with FIPS mode will fail silently or error out. Replace with --config=boringssl-fips. If you're consuming official binaries rather than building from source, this doesn't affect you directly, but verify your supply-chain tooling if you maintain custom builds.

• enhancementOpenTelemetry metrics over HTTP — drop the collector sidecar

  The OTel stat sink can now push metrics directly via OTLP/HTTP without requiring a collector sidecar. If you're running otel-collector as a DaemonSet purely for Envoy metrics forwarding, you can simplify that architecture. Evaluate whether direct OTLP/HTTP export to your backend (Grafana Cloud, Honeycomb, etc.) reduces operational overhead in your environment.

v1.33.4 is a security-critical patch fixing a Lua code injection CVE in Contour's Cookie Rewriting feature — upgrade immediately, and note the hard Envoy 1.35.0 minimum requirement.

• securityPatch CVE-2026-41246 immediately — arbitrary code execution risk in shared Envoy

  Any tenant with RBAC permissions to create or modify HTTPProxy resources could inject arbitrary Lua code through a crafted pathRewrite value. In multi-tenant clusters where Envoy is shared infrastructure, this means a compromised or malicious tenant could steal xDS client credentials or deny service to other tenants. Upgrade Contour to v1.33.4 and ensure Envoy is at 1.35.0 or later before deploying. Audit your RBAC policies to limit HTTPProxy write access to trusted principals as a defense-in-depth measure.

• breakingEnvoy 1.35.0 minimum — verify your Envoy version before upgrading Contour

  This release will not function correctly with Envoy versions older than 1.35.0 due to the new filterContext-based Lua approach. If you manage your own Envoy image or pin versions, upgrade Envoy first. The bundled Envoy in the official manifests is already at v1.35.10, so if you use the standard deployment you're covered — but custom or air-gapped environments need explicit attention here.

• enhancementReview HTTPProxy RBAC regardless of upgrade timing

  Even after patching, the underlying attack surface is broad write access to HTTPProxy resources. Take this as a signal to tighten RBAC: restrict HTTPProxy creation/modification to platform operators rather than application developers where possible. In high-trust multi-tenant environments this kind of privilege separation is the right long-term control.

v1.32.5 is a security patch fixing a Lua code injection vulnerability (CVE-2026-41246) in Contour's Cookie Rewriting feature, plus an Envoy bump to v1.34.14. Upgrade immediately in multi-tenant environments.

• securityPatch CVE-2026-41246 immediately in multi-tenant clusters

  Any cluster where untrusted users or teams have RBAC permissions to create or modify HTTPProxy resources is directly exposed. An attacker crafts a pathRewrite.value that breaks out of the Lua string context, gaining code execution in Envoy — which runs as shared infrastructure. That means credential theft (xDS client certs) or denial of service for every tenant on the same Envoy instance. Upgrade to v1.32.5 now. While you prepare the upgrade, audit who has create/update rights on HTTPProxy and tighten RBAC to the minimum necessary.

• breakingReview existing cookieRewritePolicies after upgrade

  The fix adds escaping to pathRewrite.value inputs. Legitimate values with special characters (backslashes, quotes, etc.) will now be escaped before Lua interpolation, which changes runtime behavior. Test any HTTPProxy resources using cookieRewritePolicies[].pathRewrite.value in a staging environment post-upgrade to confirm cookie rewriting still behaves as expected.

• enhancementEnvoy v1.34.14 is bundled — no separate action needed

  The Envoy bump is included in the Contour image. If you run a managed Envoy deployment alongside Contour, verify your Envoy image is also updated to v1.34.14 to stay consistent with Contour's tested configuration.

Contour v1.31.6 patches a Lua code injection vulnerability (CVE-2026-41246) in Cookie Rewriting that could allow arbitrary code execution in shared Envoy infrastructure.

• securityPatch immediately if you allow untrusted users to create/modify HTTPProxy resources

  CVE-2026-41246 is a privilege escalation path in multi-tenant clusters. Any user with RBAC write access to HTTPProxy objects can inject arbitrary Lua into Envoy — and since Envoy is shared infrastructure, the blast radius extends to other tenants and exposes xDS credentials. Upgrade to v1.31.6 now. If you cannot upgrade immediately, audit existing HTTPProxy objects for suspicious pathRewrite values and tighten RBAC so only trusted principals can write HTTPProxy resources.

• enhancementReview RBAC around HTTPProxy write permissions regardless of upgrade status

  This CVE class — user-controlled values interpolated into code — is a design risk whenever untrusted users can write Kubernetes custom resources that drive proxy configuration. Use this as a prompt to apply least-privilege RBAC on HTTPProxy, HTTPRoute, and similar resources across your clusters. Namespace-scoped RBAC and admission webhooks that validate pathRewrite values are good mitigations to layer on top of the patch.

Cilium v1.19.3 is a dense bugfix release targeting memory leaks, panics, and networking correctness issues — particularly in DSR mode, WireGuard dual-stack, and IPAM edge cases.

• securityUpdate go-jose dependency (CVE exposure)

  go-jose/go-jose was bumped to v4.1.4 as a security update. While Cilium's direct exposure depends on usage paths, this library is involved in JWT/token handling. If you're running automated audits or supply chain checks, note this dependency version change in your SBOM.

• breakingIPAM corruption risk on dual-stack clusters — upgrade urgently

  A bug in dual-stack cluster-pool IPAM could cause IPv4 PodCIDRs to be freed and reassigned after an operator restart if duplicate IPv6 PodCIDRs existed. This is a data-plane correctness issue that causes silent IP conflicts between nodes. If you run dual-stack with cluster-pool IPAM, upgrade to v1.19.3 before your next operator restart. After upgrading, inspect node CIDRs for any anomalies.

• enhancementMemory leak fixes matter more than they look — plan your upgrade

  Two distinct memory leaks are patched here. One is triggered by incremental policy updates (common in dynamic environments), the other by policy create/delete cycles. In clusters with frequent NetworkPolicy churn — CI namespaces, multi-tenant platforms, or GitOps-driven policy — these leaks can accumulate over hours or days. If your Cilium agents show gradual memory growth, this release likely explains it. Rolling restart after upgrade is sufficient; no config changes needed.

Cilium v1.18.9 is a patch release focused on memory leak fixes, panic prevention, and load balancer correctness — several bugs here could cause real production incidents.

• securitygo-jose dependency patched — update if using Cilium's auth features

  go-jose/go-jose/v4 was updated to v4.1.4 as a security fix. If your Cilium deployment uses mutual auth or any JWT/JOSE-based features, this patch addresses a known vulnerability in that library. Treat this upgrade as a priority if those code paths are active.

• breakingIPAM reassignment risk: upgrade dual-stack clusters promptly

  If you run dual-stack with cluster-pool IPAM, a bug could reassign a node's IPv4 PodCIDR to another node after an operator restart — with an existing duplicate IPv6 PodCIDR in play. This causes IP conflicts and broken pod networking. Upgrade to 1.18.9 before your next operator restart or planned maintenance window.

• enhancementMemory leaks under policy churn are fixed — relevant for dynamic environments

  Two separate memory leak paths were closed: one from incremental policy updates, one from policies being frequently created and deleted. Clusters with high policy churn (CI environments, multi-tenant setups, frequent namespace deployments) were slowly leaking memory. After upgrading, monitor Cilium agent memory baselines — you should see stabilization over hours to days.

v1.17.15 is a bug-fix patch tackling memory leaks, endpoint regeneration hangs, IPAM data corruption, and policy update deadlocks — all of which can cause silent production degradation.

• breakingIPAM corruption risk: upgrade before operator restarts in dual-stack clusters

  If you run dual-stack with cluster-pool IPAM and have any duplicate IPv6 PodCIDR conditions, an operator restart can cause IPv4 PodCIDR reassignment across nodes — effectively giving two nodes the same subnet. This is silent data-plane corruption. Upgrade to v1.17.15 before performing any operator restarts or node scaling operations in affected clusters.

• enhancementAddress memory leak accumulation in policy-heavy environments

  Two separate memory leaks were patched: one from incremental policy updates (slow, hard to detect) and another from policy churn (create/delete cycles). If you use GitOps-driven policy workflows or frequently rotate NetworkPolicies, your agents may be leaking memory right now. After upgrading, watch agent memory trends over 24-48 hours — you should see stabilization compared to a pre-upgrade baseline.

• enhancementEndpoints stuck in waiting-to-regenerate? This release fixes it

  A race condition caused endpoints to get permanently stuck in the 'waiting-to-regenerate' state, meaning policy changes stopped being applied to affected pods without obvious errors. If you've seen endpoints failing to pick up policy updates without a pod restart, upgrade and validate that endpoint regeneration completes cleanly after policy changes using 'cilium endpoint list'.

edge-26.4.3 adds per-pod proxy env var injection via annotation, bumps proxy to v2.349.0, and validates Kubernetes 1.35 compatibility across policy tests.

• securityrustls-webpki patch — verify if you vendor Rust dependencies

  rustls-webpki was bumped to 0.103.11. This library is part of Linkerd's mTLS stack. No CVE is listed, but if your organization audits or vendors Rust dependencies, update your lockfiles and re-run your SBOM scans to stay current.

• enhancementUse proxy-additional-env to inject custom env vars without custom images

  The new `proxy-additional-env` annotation lets you set environment variables on injected proxies at the pod or namespace scope. This is useful for tuning proxy behavior (e.g., log levels, feature flags) in specific workloads without modifying global Helm values or building custom proxy images. Start using it on non-critical workloads first to validate behavior before rolling out broadly.

• enhancementPlan for Kubernetes 1.35 if you're on the upgrade path

  Linkerd's test suite now covers k8s 1.35, including policy tests. If your team is evaluating or scheduling a cluster upgrade to 1.35, this edge release gives you reasonable confidence that core Linkerd functionality and policy enforcement will hold. Run your own smoke tests against a 1.35 staging cluster before committing to a production upgrade.

v2.12.7 is a targeted bug-fix release addressing ACL bypass vulnerabilities, multiple leafnode panics, a JetStream consumer stuck state, and an MQTT JWT regression from 2.12.6.

• securityPatch ACL bypass bugs immediately if you use deny rules or queue groups

  Two ACL enforcement bugs are fixed here. Overlapping wildcard patterns in deny ACLs were not enforced correctly, and queue subscriptions could bypass non-queue deny rules entirely. If your security model relies on deny-based ACLs — especially with wildcards or mixed queue/non-queue subscribers — treat this as a must-upgrade. Audit your ACL configurations after upgrading to confirm expected deny behavior is active.

• breakingMQTT users on 2.12.6 must upgrade — auth callout JWT was broken

  If you deployed 2.12.6 with MQTT clients using auth callout, JWTs were not being forwarded to the callout service, meaning your auth logic was silently bypassed or failing. This regression is fixed in 2.12.7. Upgrade immediately and verify MQTT client authentication is functioning end-to-end.

• enhancementmax_mem_store and max_file_store can now be increased via config reload

  You can now raise JetStream storage limits without restarting the server — just update the config and reload. Decreasing is still not supported via reload. Useful for capacity adjustments during peak periods without downtime. Plan your storage sizing with headroom so you can expand reactively if needed.

v2.11.16 is a security-focused patch fixing multiple ACL bypass vulnerabilities in queue subscriptions, leafnode inbound messages, and wildcard deny patterns — update immediately if you rely on NATS authorization.

• securityACL bypass via queue subscriptions — patch now

  Queue subscribers could silently bypass deny rules intended for non-queue subscriptions. If your authorization model uses deny patterns to restrict subjects, those controls were not reliably applied. Audit your ACL configurations and update to v2.11.16 before anything else. This affects any multi-tenant or permission-isolated NATS deployment.

• securityLeafnode ACL enforcement was incomplete — verify your leaf configs

  Inbound messages on leafnode connections were not always checked against ACL permissions. If you run leafnode-connected clusters with per-account or per-user authorization, treat this as a potential unauthorized data access vector. After upgrading, review leafnode user credentials and their associated permission sets.

• breakingno_auth_user scope change may affect existing setups

  The no_auth_user option is now restricted to client connections only. If you had any tooling or configuration relying on no_auth_user applying to leafnode or other non-client connection types, those connections will now require explicit credentials. Test in staging before rolling this update to production leafnode infrastructure.

Istio 1.29.2 was released, but the published notes are too brief to summarize. See the original release notes for details.

Istio 1.28.6 was released, but the published notes are too brief to summarize. See the original release notes for details.

Envoy v1.37.2 is a patch release fixing three runtime bugs: a crash on listener removal, incomplete body forwarding in dynamic module filters, and a request hang on buffer overflow during internal redirects.

• breakingUpgrade immediately if using process-level access log rate limiting

  If your Envoy config uses a process-level access log rate limiter and you perform any listener hot-reload or removal, you are hitting a crash path. This is not a low-probability edge case — listener removal happens during routine config updates via xDS. Upgrade to v1.37.2 before your next config push.

• breakingCheck dynamic module filter pipelines for body truncation

  If you run dynamic module filters alongside other filters that buffer request or response bodies (e.g., ext_proc, gRPC transcoding, JWT body inspection), you may have been forwarding truncated payloads upstream or to clients without any error. Audit logs for unexpected body size mismatches and validate behavior in staging after upgrading.

• breakingInternal redirect with large request bodies could hang — patch this now

  Any route config using internal redirects combined with upstream services that can trigger redirects on large POST/PUT bodies is a hang risk. The request stalls rather than returning an error, which means your upstream timeout is the only safety net. This is a silent reliability failure. Upgrade and consider temporarily tightening request buffer limits on affected routes as a short-term guard.

Envoy v1.36.6 is a patch release fixing two bugs: incomplete body delivery in dynamic module filters and a request hang when internal redirect triggers buffer overflow.

• breakingUpgrade if you use dynamic module filters with buffering neighbors

  If your filter chain mixes dynamic module filters with any filter that buffers the body (e.g., ext_proc, grpc-web, or custom buffering filters), you were silently receiving incomplete bodies. This is a data-correctness bug, not just a performance issue. Upgrade to v1.36.6 immediately and validate that your dynamic modules are processing full payloads post-upgrade.

• breakingInternal redirect + buffer overflow caused indefinite request hang

  Any deployment using internal redirects where the request body can exceed the configured buffer limit was exposed to hung requests — requests that never complete and hold connections open. This is particularly dangerous under load. Upgrade now; in the interim, consider raising buffer limits or disabling internal redirects if you're seeing stuck requests.

Envoy v1.35.10 was released, but the published notes are too brief to summarize. See the original release notes for details.

Envoy v1.34.14 was released, but the published notes are too brief to summarize. See the original release notes for details.

Pure dependency maintenance release — proxy bumped to v2.348.0, multiple Go/Rust/JS deps updated. No feature changes or bug fixes to speak of.

• securitylodash updated in web dashboard — low urgency, but worth knowing

  lodash went from 4.17.23 to 4.18.1. The Linkerd dashboard is typically internal-facing, so exposure is limited. Still, if your team audits frontend dependency CVEs, confirm this resolves any open advisories in your SBOM tooling.

• enhancementProxy v2.348.0 — check the proxy changelog if you're chasing specific behavior

  The proxy is the only component here with potentially meaningful runtime changes. The release notes don't surface proxy-level details directly, so if you're tracking a specific fix or behavior change, pull up the linkerd2-proxy v2.348.0 release notes separately before promoting this edge build to production.

• enhancementSkip this edge unless you need the proxy bump

  This is a housekeeping release. If you're already tracking edge builds for the proxy, upgrading is straightforward. For anyone evaluating edge-26.4.x for broader testing, there's no functional regression risk here, but also nothing compelling enough to rush an upgrade from edge-26.4.1.

Istio 1.27.9 was released, but the published notes are too brief to summarize. See the original release notes for details.

Mostly a dependency maintenance release with two proxy bumps (v2.346.0, v2.347.0), a multicluster RBAC fix, and a Prometheus config correction for viz admin port names.

• securityCrypto dependency updates — low urgency but keep your upgrade cadence

  openssl, rustls-webpki, aws-lc-rs, and aws-lc-sys all received patch bumps this cycle. None carry disclosed CVEs, but these are core cryptographic libraries in the proxy. Stay on a regular edge upgrade cadence rather than skipping multiple releases, so these patches don't accumulate.

• breakingCheck Prometheus metrics after upgrading if you use Linkerd Viz

  The Prometheus config was corrected to match new admin port names. If you're running Linkerd Viz and upgraded from an earlier edge build, verify your dashboards still show expected metrics after the upgrade. Gaps in scraping could have silently existed before this fix — cross-check your Prometheus targets to confirm scrape health.

• enhancementMulticluster users: review Server/AuthorizationPolicy coverage

  Missing Server and AuthorizationPolicy resources were added for the multicluster extension. If you use Linkerd multicluster, upgrade and audit your cross-cluster authorization posture. The previous gap meant some traffic paths lacked proper policy objects, which could have caused unexpected allow/deny behavior depending on your default policy.

Emissary v4.0.1 is the true first release of Emissary 4, built on distroless images and stock Envoy 1.36.2, with five breaking changes that require immediate attention before upgrading.

• securityApply this release for CVE fixes in dependencies and Python

  Multiple dependency updates and a Python interpreter upgrade were included specifically to resolve CVEs. The release notes don't enumerate the CVEs, so check the CHANGELOG for specifics. If you're running any prior Emissary version, upgrading to 4.0.1 is the right move for the security fixes alone — just plan for the breaking changes in the same window.

• breakingAudit all five breaking changes before upgrading

  This is a major version jump with five distinct breaking changes. Before upgrading: (1) Update your Helm repo URL to GHCR and pin chart version to 4.0.1. (2) If you use v1 or v2 CRDs, explicitly set enableLegacyVersions: true in your values file. (3) Remove any --metrics-endpoint flags from your diagd configuration. (4) Migrate banner endpoint config to the AMBASSADOR_DIAGD_BANNER_ENDPOINT env var. (5) Verify you have no dependency on Edge Stack's custom error responses or header-case features — pure Emissary users should be unaffected, but double-check.

• enhancementUse the new multiarch images for ARM64 clusters

  Emissary 4 ships multiarch Docker images covering both amd64 and arm64. If you run mixed-arch or ARM-only clusters (common with Graviton or Ampere nodes), you can now deploy Emissary without custom builds or workarounds. The image pull just works — no node affinity hacks needed.

gRPC v1.80.0 delivers TLS private key offloading, EventEngine enabled by default in Python, and a raft of Python async/AIO bug fixes that affect production stability.

• securityPrivate key material no longer needs to live in process memory

  The private key offload feature means TLS signing can be delegated externally. For teams running in regulated environments, upgrade to v1.80.0 and migrate to the offload-backed credential provider to eliminate the attack surface of in-process key storage. This applies to both the Python signer implementation and the core C++ offload path.

• breakingEventEngine is now the default I/O backend in Python — test before upgrading

  EventEngine replacing the legacy polling engine by default changes how gRPC Python handles I/O, threading, and fork behavior. A fork-support env var default was reverted (PR #41769) in this same release, signaling the area is still stabilizing. Run your existing Python gRPC workloads in a staging environment before promoting to production, and pay attention to any fork-based server patterns (e.g., gunicorn pre-fork).

• enhancementAdopt Private Key Offload for secrets-safe TLS

  The new TLS Private Key Offload implementation and InMemoryCertificateProvider let you keep private keys in an HSM or KMS and rotate certs at runtime. If you run gRPC servers with compliance or secrets-management requirements, this is the right upgrade path. Wire up the new signer interface and drop file-based credential loading where you can.

v2.12.6 is a critical security release fixing 11 CVEs across MQTT, JetStream, WebSockets, leafnodes, and mTLS. Also fixes a JetStream regression from 2.12.5 that could lose consumer assignments.

• securityUpgrade immediately — 11 CVEs patched across core subsystems

  This release patches CVEs in MQTT (3), JetStream (2), leafnodes (2), WebSockets (1), mutual TLS (1), command-line credentials (1), and publish permissions (1). If you run any of these features in production, there is no safe reason to stay on an older build. Review your deployment against the affected subsystems and prioritize accordingly — MQTT and leafnode users face the highest exposure count.

• breaking1MB JWT size limit is now enforced

  JWTs larger than 1MB will be rejected. This is unlikely to affect most deployments, but if you use deeply nested or unusually large account/user JWTs (e.g., with large permission sets), validate your JWT sizes before upgrading. Check your operator's JWTs and any dynamically issued credentials.

• breakingJetStream consumer assignments could be silently lost on 2.12.5 — fix requires upgrade

  A regression in 2.12.5 caused stream updates on clustered JetStream with async snapshots to drop consumer assignments. If you're running 2.12.5 with clustered JetStream, audit your consumer counts before and after upgrading to confirm no silent data loss occurred. This is the most operationally dangerous bug in this release cycle.

v2.11.15 is a critical security release patching 11 CVEs across MQTT, leafnodes, WebSockets, JetStream, and mTLS. Upgrade immediately if you run any of these features.

• securityUpgrade now — 11 CVEs, multiple remote attack surfaces

  This release patches CVEs across nearly every major NATS feature area. MQTT users face the most exposure: password leakage in monitoring endpoints, session hijacking via mismatched client IDs, and malformed packet panics. WebSocket deployments had an unbounded memory allocation path exploitable for DoS. Leafnode and mTLS users also have targeted fixes. There is no safe reason to delay this upgrade. Pin your deployments to v2.11.15 and roll it out across all clusters — dev, staging, and production.

• breakingMQTT client ID restrictions may break existing clients

  NATS special characters (`.`, `>`, `*`, spaces, tabs) are now rejected in MQTT client IDs. If any of your MQTT clients use these characters — common in some IoT device naming schemes — they will fail to connect after upgrade. Audit your MQTT client ID naming conventions before rolling out this version in production. Also verify that your MQTT clients do not rely on the previously broader implicit permission scope, which is now restricted to `$MQTT.sub.*` and `$MQTT.deliver.pubrel.*` prefixes.

• enhancementTrace logging and monitoring endpoints now redact secrets

  Command-line secrets were previously visible in expvar monitoring output and trace logs. This is fixed. If you've been scraping the monitoring port or collecting trace logs and routing them to external systems (log aggregators, SIEM, etc.), check whether any historical data needs to be rotated or scrubbed. Going forward, no additional config is needed — redaction is automatic.

Contour v1.33.3 is a security-focused patch bumping Envoy to v1.35.9 and grpc-go to v1.79.3, with a minor cleanup to example manifests.

• securityUpgrade to get the Envoy security fixes

  The Envoy bump to v1.35.9 is the main reason to upgrade — it addresses real security vulnerabilities in the data plane. The grpc-go CVE-2026-33186 does not affect Contour, but the Envoy issues are reason enough to prioritize this patch. Plan a rollout soon, especially if your clusters are exposed to untrusted traffic.

• breakingCheck custom manifests for the removed hostPort: 8002

  If you copied or extended the example manifests and rely on hostPort: 8002 for scraping Envoy metrics directly from the node, that configuration is now gone from the upstream examples. Audit your manifests before upgrading to confirm whether you've inherited this setting and whether any monitoring pipelines depend on it.

Contour v1.32.4 is a security/stability patch bumping Envoy to v1.34.13 and grpc-go to v1.79.3 (CVE-2026-33186), with a minor manifest cleanup.

• securityUpgrade for the Envoy security fixes

  The Envoy bump to v1.34.13 is the real reason to update here. Envoy releases in this range carry security fixes — check the Envoy v1.34.13 changelog directly to understand which CVEs apply to your traffic patterns. The grpc-go CVE-2026-33186 does not affect Contour, but upgrading still gets you the fix in the dependency graph. Plan a rolling upgrade now rather than waiting.

• breakingCheck custom manifests that reference Envoy hostPort 8002

  The example manifests removed hostPort 8002 from the Envoy metrics container. If your deployment pipelines diff against or are derived from the upstream example manifests, this change will appear as a diff. More importantly, if you have firewall rules, monitoring scrapers, or Prometheus scrape configs targeting that host port directly, verify they still reach the metrics endpoint through an alternative path (e.g., ClusterIP Service or pod IP) before upgrading.