Releases

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.

containerd 2.3.0 is the first LTS release under the new Kubernetes-aligned 4-month cadence, offering 2+ years of support with major NRI, EROFS, and observability improvements.

• breakingRename NRI plugins with commas in their names before upgrading

  The new OCI hook owner accumulation logic uses commas as delimiters internally, so any NRI plugin whose name contains a comma will break. Audit your NRI plugin names now. If any contain commas, rename them before rolling out 2.3.0 — this affects both the plugin binary name and any configuration referencing it.

• enhancementPlan your 1.7 → 2.3 LTS migration now

  This is the designated upgrade target from containerd 1.7 LTS. The project explicitly tests and supports direct sequential LTS-to-LTS upgrades. If you're still on 1.7, this is the right time to build a migration plan — 2.3 gets at least two years of support, making it the stable foundation for Kubernetes clusters through roughly 2027.

• enhancementEnable trace propagation for better plugin and runtime observability

  OTel traces now flow through gRPC RPCs between containerd and its plugins, and trace IDs can be injected into log lines. If you run a distributed tracing stack (Jaeger, Tempo, etc.), configure the OTLP exporter in containerd's config and enable trace ID injection in logging. This closes a major gap where container lifecycle events were invisible to your tracing backend.

flagd core v0.15.5 fixes evaluation correctness bugs in fractional rollouts and JSONLogic and/or operators — teams relying on complex flag targeting rules should upgrade.

• securityDependency security alerts resolved

  Dependabot security alerts were resolved in this release. No CVEs are called out explicitly, but the dependency updates address known vulnerabilities in transitive deps. Upgrade if you're running flagd in a security-sensitive environment.

• breakingFractional evaluator fix: upgrade if you use targeting keys

  Null or missing targeting keys in fractional evaluators previously caused undefined behavior. If your flag rules use fractional/percentage rollouts and some users may lack a targeting key (e.g. anonymous users), upgrade to avoid incorrect bucket assignments.

• breakingJSONLogic and/or bug fix may change evaluation results

  The jsonlogic and/or operator bug could cause flag rules with compound boolean logic to evaluate incorrectly. Review any rules relying on and/or conditions after upgrading — results may change from what you saw in v0.15.4.

v3.3.9 is a focused patch addressing four bugs — including a panic in ApplicationSet DuckType Generator and a UI crash in pod logs — plus a Go version bump to resolve CVEs.

• securityUpgrade to patch Go-level CVEs

  The Go runtime was bumped specifically to resolve CVEs. The release notes don't enumerate the exact CVE IDs, but if you're running 3.3.x in production, upgrade to 3.3.9 now rather than waiting for your next maintenance window. All container images are cosign-signed and SLSA Level 3 provenance is available — verify signatures before deploying if your pipeline requires it.

• breakingApplicationSet DuckType Generator panic is now fixed — review affected ApplicationSets

  If you use DuckType Generators and have clusters with non-string label values, previous versions would silently panic. After upgrading, those ApplicationSets will now process correctly rather than crashing. Do a quick audit of your ApplicationSet resources post-upgrade to confirm they're reconciling as expected — you may see previously-failing sets suddenly become active.

• enhancementOCI metadata caching restored — expect reduced registry pressure

  The Redis cache for OCI metadata was broken, meaning every OCI source lookup was hitting the registry directly. With this fix, caching works again. If you use OCI-sourced ApplicationSets or Helm charts, you should see reduced latency and fewer registry requests after upgrading. No configuration change needed.

v1.16.0 brings new URI builtins, Data API metadata support, OTLP metrics export, and critical fixes for log dropping and log buffer eviction bugs introduced in v1.15.x.

• securityunits.parse_bytes exponent cap prevents timeout bypass

  Extremely large exponent values in units.parse_bytes could be used to cause evaluation timeouts, potentially bypassing policy enforcement. This is fixed in v1.16.0 by capping the exponent size. If your policies accept user-controlled input that gets passed to units.parse_bytes, this fix is directly relevant — upgrade and review any policies that parse byte strings from untrusted sources.

• breakingUpgrade from v1.15.x immediately — logs are silently dropped

  A BufferedLogger bug in v1.15.x caused bundle download logs, print() debug output, and plugin logs to be dropped after the first flush. This is silent data loss in your observability stack. If you're running v1.15.x in any environment where decision logs or debug output matter, upgrade to v1.16.0 now. Check your log pipeline for gaps if you've been running v1.15.x in production.

• enhancementUse new uri.parse / uri.is_valid builtins to replace fragile regex-based URL validation

  Many OPA policies today use regex or string manipulation to validate or decompose URLs — a brittle approach. The new uri.parse builtin returns structured RFC 3986 components (scheme, host, path, query, etc.), and uri.is_valid does a clean true/false structural check. If you have policies handling redirect URIs, webhook URLs, or any URL-bearing input, replace your custom parsing logic with these builtins. The structured output makes it easier to write precise, readable rules.

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.

Vitess v24 ships structured JSON logging by default, window function pushdown for sharded keyspaces, OpenTelemetry tracing, and a security fix for backup manifest command injection. 460 PRs merged.

• securityBackup MANIFEST command injection is now blocked by default

  Prior to v24, an attacker with write access to backup storage could modify the MANIFEST file to inject arbitrary shell commands that VTTablet would execute during restore. This is now blocked — the MANIFEST decompressor field is ignored unless you explicitly pass --external-decompressor-use-manifest. If you're on v23 or earlier, treat backup storage access controls as a security boundary and audit who can write to it.

• breakingAudit backup restore configs for MANIFEST decompressor

  If your VTTablet restore process relied on the decompressor command stored in backup MANIFESTs (i.e., you never set --external-decompressor but backups still decompressed), restores will silently skip decompression in v24 and likely fail. Add --external-decompressor-use-manifest to your VTTablet config to preserve old behavior, but read the security advisory first: a compromised backup store could execute arbitrary commands on your tablet. Evaluate whether you actually need this or can pass --external-decompressor explicitly instead.

• breakingRemove deprecated VTOrc API endpoint and metric references

  The /api/replication-analysis endpoint returns 404 in v24 — any monitoring scripts, Grafana dashboards, or alerting rules hitting that URL will break silently or with errors. Switch to /api/detection-analysis (same params, same response format). Also replace DiscoverInstanceTimings with DiscoveryInstanceTimings in dashboards. Do this before deploying v24 to production.

• enhancementMigrate tracing to OpenTelemetry now, not in v25

  opentracing-jaeger and opentracing-datadog are deprecated in v24 and will be removed in v25. The migration is straightforward: replace --tracer opentracing-jaeger with --tracer opentelemetry, and swap --jaeger-agent-host host:port for --otel-endpoint host:4317. Jaeger v1.35+ accepts OTLP on port 4317 by default. Datadog users should point to the Agent's OTLP ingestion endpoint. Do this upgrade cycle, not the next one.

• enhancementAdd --cell flag to VTOrc now

  --cell is optional in v24 but becomes required in v25. Multi-cell deployments especially should add it now — startup validation against the topology will catch misconfiguration early, and it unblocks future cross-cell recovery logic in VTOrc. One flag, no downtime, avoids a forced change next release.

Karmada v1.17.2 is a patch release fixing scheduler misrouting bugs, operator reconciliation failures, and a Job replica assignment error — plus an Alpine base image bump for security.

• securityRebuild or pull updated images to get the Alpine 3.23.4 base

  The base image was bumped from Alpine 3.23.3 to 3.23.4. If you're running air-gapped or mirrored image setups, make sure to pull and mirror the new v1.17.2 images. Check Alpine's changelog for the specific CVEs addressed if your compliance process requires it.

• breakingScheduler backoffQ misrouting may have masked real scheduling failures

  Bindings with insufficient cluster replicas were incorrectly queued in backoffQ instead of unschedulableBindings. This means your scheduler may have been retrying workloads on an exponential backoff schedule rather than surfacing them as unschedulable. After upgrading, expect some previously silent failures to become visible in unschedulableBindings — review any workloads that seemed stuck or slow to schedule.

• enhancementUpgrade if you use karmada-operator with custom tolerations/affinity or multi-cluster Jobs

  Two high-impact fixes landed here: operator-managed deployments were silently ignoring tolerations and affinity configs, which could cause pods to land on unintended nodes. And Job completion counts were being assigned incorrectly across clusters, which could corrupt Job semantics in distributed workloads. Both are straightforward regressions worth patching immediately if either feature is in use.

Karmada v1.16.5 is a focused patch release fixing scheduler queue misrouting, Job replica assignment errors, and operator reconciliation failures, plus an Alpine base image bump.

• securityAlpine 3.23.4 base image — rebuild and redeploy your Karmada components

  The Alpine bump from 3.23.3 to 3.23.4 addresses upstream security concerns. If you're running custom-built Karmada images or have image scanning in your pipeline, update your base images accordingly. The official images in this release already include the updated base.

• breakingScheduler queue misrouting causes stalled workloads — patch immediately

  The backoffQ vs unschedulableBindings misrouting bug means workloads with insufficient cluster replicas may have been stuck in the wrong queue, causing unexpected scheduling delays or failures. If you've seen bindings that appear perpetually pending despite enough cluster capacity becoming available, this fix directly addresses that. Upgrade to v1.16.5 and check for any bindings that are stuck — they should reschedule automatically after the upgrade.

• breakingJob completions were assigned to wrong clusters — review existing Job distributions

  The Job completion replica assignment bug could have led to incorrect work distribution across member clusters. Jobs that ran on this version may have had skewed completion counts per cluster. After upgrading, inspect any multi-cluster Jobs that were scheduled on v1.16.4 to verify their completion semantics were not affected in production.

Karmada v1.15.8 is a targeted bug-fix patch addressing scheduler queue misrouting, missing cluster info in events, and an operator reconciliation failure. Alpine base image bumped for security.

• securityRebuild and redeploy to pick up alpine:3.23.4 patches

  The alpine base image bump from 3.23.3 to 3.23.4 addresses unspecified security concerns. If you're running custom Karmada images built from the upstream base, rebuild against the new base. If you're using official images, pulling v1.15.8 is sufficient.

• breakingScheduler queue misrouting can cause workloads to be stuck — patch immediately

  The backoffQ bug is particularly dangerous in production: when a binding hits insufficient replicas, it gets retried with exponential backoff instead of being placed in unschedulableBindings where it belongs. This means your workloads silently wait longer than expected before rescheduling. If you're running ClusterAffinities with replica constraints, upgrade to v1.15.8 — don't wait on this one.

• enhancementOperator idempotency fix prevents init reconciliation crashes on restarts

  The non-idempotent secret creation in karmada-operator meant that if the operator restarted mid-initialization, reconciliation would fail. This is now fixed with an idempotent approach. If you've been seeing operator init failures after pod restarts or rolling updates, this patch resolves the root cause.

containerd API v1.11.0 ships a new shim bootstrap protocol, container filesystem copy transfer types, and sandbox spec field support — aligning with the containerd 2.3 runtime release.

• securitygRPC updated from v1.59.0 to v1.79.3 — multiple CVE fixes included

  A 20-minor-version jump in gRPC covers a significant span of security and stability fixes. If your environment pins or vendors gRPC separately, reconcile your dependency tree against v1.79.3. The golang.org/x/* packages also moved forward across the board, so a full dependency audit is warranted before deploying this API version in production.

• breakingSandbox API: Container field removed, update any sandbox metadata consumers

  The Container field has been dropped from sandbox metadata and replaced with a spec field. If you have tooling, controllers, or custom runtimes that read or write sandbox metadata directly, audit them now. This is an API-level change — anything compiled against the old proto definitions will break at runtime when targeting containerd 2.3.

• breakingShim bootstrap protocol is now protobuf — custom shim implementations need updating

  The new shim bootstrap protocol switches from JSON to protobuf and uses enums instead of strings for capabilities and log levels. If you maintain a custom shim or vendor the containerd API, you must update your bootstrap handling before deploying containerd 2.3. Third-party shims (e.g., kata-containers, nydus) likely need corresponding releases — check their compatibility before upgrading.

KServe v0.18.0 is a large release dominated by LLMInferenceService (llmisvc) maturation, two CVE fixes, and multi-node inference groundwork—teams running LLM workloads should review carefully before upgrading.

• securityApply immediately: three CVE fixes in this release

  CVE-2026-32597 (PyJWT critical header bypass), CVE-2026-33186 (gRPC authorization bypass), and CVE-2026-30922 (pyasn1 DoS) are all patched here. If you're running KServe with gRPC inference endpoints or Python-based runtimes exposed externally, these are not optional. Upgrade to v0.18.0 or apply the patches to your current version. The gRPC bypass in particular could allow unauthenticated requests to reach protected inference endpoints.

• breakingPYTHONPATH is now blocked in webhooks—audit your ServingRuntimes

  A new webhook validation blocks PYTHONPATH from being set in InferenceService or ServingRuntime specs. If any of your custom ServingRuntimes or ISVCs set PYTHONPATH (a common pattern for custom Python module paths), they will be rejected at admission after this upgrade. Audit all your ServingRuntime and ISVC manifests before upgrading and remove or replace PYTHONPATH usage.

• breakingHelm chart renamed to 'kserve-resources'—update your Helm releases

  The KServe Helm chart name changed from 'kserve' to 'kserve-resources'. If you manage KServe via Helm, a naive upgrade will not find the old release name. Plan a migration: either rename the existing Helm release or uninstall/reinstall. CI pipelines, GitOps configs, and any tooling referencing the chart name need updating before you run the upgrade.

• enhancementLLMInferenceService autoscaling is production-ready—evaluate for LLM workloads

  v0.18.0 ships KEDA/HPA and WVA-based autoscaling for LLMInferenceService, plus LWS as an autoscaling target for multi-node workloads. If you're running vLLM-backed inference at scale and hitting manual scaling pain, now is a good time to test llmisvc autoscaling in staging. The WVA dependency was bumped to v0.6.0-rc3, so treat it as near-stable but not fully GA.

This is a redirect release pointing to individual Kubeflow sub-project repositories. No actual code or features were released here.

• breakingStop watching kubeflow/kubeflow for release updates

  If your team tracks Kubeflow releases via the kubeflow/kubeflow repository, you're now missing actual releases. Each sub-project ships independently. Update your watch list, RSS feeds, or release notification pipelines to follow the individual repos: manifests, pipelines, trainer, katib, notebooks, spark-operator, model-registry, sdk, and dashboard.

• enhancementAdopt per-component upgrade cadence instead of monolithic updates

  With each component on its own release cycle, you can now upgrade just Katib or Model Registry without touching Pipelines or Trainer. Build your upgrade strategy around component-level semver tracking rather than waiting for a single Kubeflow platform release. Check kubeflow/manifests releases for the reference compatibility matrix between components.

Microcks 1.14.0 adds Kafka request-reply for async mocking and expands Callback/Sync-to-Async support across REST, gRPC, and the UI. A bug fix prevents HTTP method mutation on mocked operations.

• securityRebuild custom images on updated UBI9 base

  The base image bumps to UBI9 9.7-1776833838. If you build custom Microcks images on top of the official one, rebuild and re-test after upgrading to pick up the upstream OS patches included in this UBI update.

• breakingVerify REST mock routing after operation method fix

  The fix for issue #2028 prevents the operation HTTP method from being overridden — a subtle bug that could cause mocks to respond incorrectly if the method was being mutated. Verify any existing REST mocks that rely on method-specific routing to confirm they behave as expected after upgrade.

• enhancementAdopt Kafka request-reply for async testing

  Kafka async mocks now support request-reply semantics. If your team uses Microcks to mock event-driven services over Kafka, this unlocks proper two-way interaction testing without external tooling. Review the updated API for Callback and Sync-to-Async support alongside the new triggers UI before migrating existing Kafka mock setups.

Rook v1.19.5 patches several operator bugs including a CSI priority class swap, OSD CRUSH device class fix, and more reliable mon drain behavior.

• breakingAudit CSI priority classes after upgrade — they were swapped

  The provisioner and plugin priority class names were assigned to the wrong CSI components. If you set custom values for these fields, verify that your workloads are getting the priority you intended post-upgrade. Clusters running latency-sensitive storage I/O with tiered priority classes are most at risk. Check the assigned priority classes on CSI pods after the upgrade and adjust your Helm values if needed.

• enhancementUpgrade if you've hit silent CRUSH device class failures on OSD re-discovery

  When OSDs were re-discovered (e.g., after node replacement or OSD recreation), the CRUSH device class wasn't being reapplied. This caused OSDs to land in the wrong CRUSH bucket, potentially breaking data placement rules. If you use device classes (hdd/ssd/nvme) for pool or rule targeting, verify your OSD tree after upgrading to confirm correct class assignments.

• enhancementSet ROOK_UNREACHABLE_NODE_TOLERATION_SECONDS via Helm now

  Previously this required patching the operator deployment directly. With this release it's a first-class Helm value. If you've been working around this with post-install patches or custom operator manifests, clean those up and move the setting into your values file to avoid drift.

v0.151.0 has one API-level breaking change in the OTLP receiver config struct and changes the default behavior of the builder's go.mod generation. Dual-stack gRPC connection fixes and a pprofile data corruption fix are the most operationally relevant improvements.

• breakingUpdate OTLP receiver config field access in custom collectors

  The OTLP receiver's Config.Protocols is now a named field — any code accessing cfg.GRPC or cfg.HTTP directly will fail to compile. Update those references to cfg.Protocols.GRPC and cfg.Protocols.HTTP before upgrading collector builds that embed or extend the OTLP receiver.

• breakingCheck generated collector go.mod if you commit builder output

  cmd/builder now writes relative paths in Go module replace statements by default. For teams that build the collector, commit the generated source, and run it on multiple machines, this is an improvement. If you have tooling that depends on absolute paths (e.g., scripts parsing go.mod), set dist::use_absolute_replace_paths: true to preserve the old behavior while you migrate.

• enhancementFix dual-stack DNS connection issues with passthrough gRPC resolver

  Teams running OTLP gRPC exporters in dual-stack DNS environments have reported connection issues since the grpc.NewClient migration. You can now work around this by setting the endpoint to passthrough:///host:port in your exporter config. If you've seen intermittent connection failures in IPv4/IPv6 mixed environments, try this first.

Single targeted bug fix: messages arriving during graceful shutdown or pub/sub component hot-reload no longer get silently routed to dead-letter queues.

• breakingAudit your dead-letter queues for silently lost messages

  If you run pub/sub with dead-letter queues configured, messages diverted there during past rolling deployments or restarts were never retried — they just sat in the DLQ. Before upgrading, inspect those queues for messages that should have been processed. After upgrading to 1.17.6, plan to replay or reprocess any legitimate messages found there. Going forward, monitor DLQ depth during deployments as a health signal; a spike should now indicate actual processing failures, not shutdown timing artifacts.

• enhancementUpgrade if you do rolling deployments or frequent restarts

  Any team doing Kubernetes rolling updates or frequent pod restarts with pub/sub workloads should treat this as a high-priority patch. The previous behavior was silent — no errors surfaced to your app, messages just disappeared into DLQs. The fix is low-risk (a targeted behavior change in the shutdown path), so upgrading from any 1.17.x release is straightforward.

v1.120.1 is a patch release focused on carbon cost fixes, AWS Spot pricing performance, memory optimization, and a security-relevant MCP server default change.

• breakingCheck if MCP server was relied upon — it's now off by default

  The MCP server flipped from opt-out to opt-in. If any tooling or integrations depended on the MCP server being active without explicit configuration, they will silently stop working after this upgrade. Before deploying, audit whether MCP_SERVER_ENABLED needs to be explicitly set to true in your environment config.

• enhancementAWS Spot users: Spot Price History caching reduces API pressure

  If you run workloads on AWS Spot instances, OpenCost was previously hitting the Spot Price History API more aggressively. The new caching layer cuts down on AWS API calls, which matters both for rate limiting and for cost attribution latency. No action required, but worth validating your Spot cost data accuracy after upgrading.

• enhancementCarbon cost data was wrong — upgrade if you track emissions

  The carbon cost fixes address incorrect provider detection and broken fallback logic, meaning prior carbon cost figures may have been inaccurate. If you surface carbon/emissions data to teams or dashboards, re-baseline your metrics post-upgrade rather than comparing historical data across this version boundary.

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.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.

Flatcar stable-4593.2.0 is a large security + infrastructure release: 150+ kernel CVEs patched, openssh/openssl/curl/intel-microcode updated, and significant initrd/partition layout changes that need attention before upgrading.

• securityMass CVE remediation across kernel and userspace — update now

  Linux kernel patches cover 150+ CVEs, and userspace components (openssh 10.2_p1, openssl 3.5.4, curl 8.16.0, intel-microcode, gnupg, pam) each carry their own CVE fixes. This is a large security catch-up from Stable 4459.2.4. Any Flatcar node on stable should be updated promptly — the auto-update mechanism will handle it, but verify nodes are actually cycling through updates if you have update pauses configured.

• breakingsshd now uses OpenSSH upstream defaults including post-quantum key exchange

  sshd_config no longer hard-codes Ciphers, MACs, and KexAlgorithms; OpenSSH upstream defaults now apply, which includes post-quantum key exchange. If your environment requires specific legacy algorithms (e.g., for compliance tooling or older SSH clients), add drop-in config to /etc/ssh/sshd_config.d/ before upgrading. Test SSH connectivity after the update in a non-prod node first.

• breakingPartition layout changed; kernel module availability in first-stage initrd is reduced

  Partition sizes have grown: /boot to 1 GB, /usr to 2 GB, /oem to 1 GB. Existing nodes can still update, but new disk images will use the larger layout. If you have tight disk quotas, pre-provision or verify disk images have room. Also, the kernel+initrd on /boot is now half the size due to a two-stage initrd split — if any required drivers were only in the first-stage initrd, you may see boot issues. Report regressions to the Flatcar team immediately.

Cortex v1.21.0 graduates several experimental features to stable, fixes multiple PRW2 data corruption and panic bugs, and introduces a new Parquet mode for Store Gateway alongside an Overrides API.

• breakingAudit and update renamed flags before upgrading

  Several flags were renamed: -experimental.ruler.enable-api → -ruler.enable-api, -experimental.alertmanager.enable-api → -alertmanager.enable-api, -distributor.otlp.enable-type-and-unit-labels is now a no-op (consolidated into -distributor.enable-type-and-unit-labels), and parquet cache flags/configs dropped 'queryable' from their names. The users-scanner cleanup-interval became update-interval. Old flags are deprecated but not removed yet — audit your config files and Helm values now, before they disappear in a future release.

• breakingPRW2 data corruption and panic fixes require validation of existing pipelines

  Three separate bugs in the Remote Write V2 handler were fixed: shallow copying of Samples/Histograms caused data corruption, dirty sync.Pool reuse caused index-out-of-range panics, and Symbols backing array wasn't cleared on pool return causing memory leaks. If you're using PRW2, treat this upgrade as mandatory. Validate your ingestion pipeline after upgrading and check that downstream metrics are intact.

• enhancementBucket index is now on by default — verify storage permissions

  The bucket index is enabled by default in this release. If your object storage IAM policies restrict list operations or your Cortex deployment had bucket index disabled intentionally, verify that the bucket index can be written and read correctly post-upgrade. Cortex will generate and maintain the index automatically, but storage permission errors will surface as query failures rather than obvious configuration errors.

Patch release upgrading to Wasmtime 44 and fixing a pooling allocator crash, plus new glibc builds for GPU workloads on Linux.

• securityUpgrade if you hit pooling allocator crashes — the fix prevents silent failures

  The pooling allocator was being enabled without checking whether the host hardware actually supports it, which could cause runtime crashes or unpredictable memory behavior. If you've seen wash-runtime instability on certain host types, this fix directly addresses that. Upgrade and monitor memory allocation behavior post-deploy.

• breakingTest Wasmtime 44 upgrade in staging before rolling to production

  Wasmtime 44 is a major version bump for the underlying runtime. While wasmCloud wraps it, Wasmtime releases frequently carry behavior changes in memory handling, WASI interfaces, or component model semantics. Validate your component workloads in a non-production environment before upgrading clusters.

• enhancementGPU workloads on Linux now have proper glibc builds — start testing if relevant

  If you're running or planning wasmCloud workloads that touch GPU features on Linux, the new glibc builds resolve compatibility issues with standard Linux distributions that expect dynamically linked runtimes. Pull the new artifacts and validate against your target GPU host environment.

KubeVirt v1.7.3 is a focused patch release fixing 11 bugs across live migration, ARM64/s390x guest support, VMExport, and virt-handler stability.

• breakingBackend storage volume name has changed — check existing VMs

  VMs using backend storage volumes will now report the volume name as 'persistent-state-for-this-vm' instead of a name derived from the VM name. If you have monitoring, automation, or tooling that references the old volume name pattern, update those references before upgrading. Verify existing VMs with backend storage in your environment to understand impact before rolling out v1.7.3.

• enhancementUpgrade if you run ARM64 or s390x guests, or use decentralized live migration

  Three targeted fixes land for non-x86 architectures: ARM64 SMBIOS visibility and s390x PCIe controller errors are both resolved. Separately, decentralized live migration now correctly reports success and supports Windows VMs requiring Hyper-V enlightenments. If any of these scenarios apply to your cluster, this patch is worth prioritizing over staying on v1.7.2.

• enhancementvirt-handler socket recovery is now automatic — no more manual pod restarts

  Two separate fixes address domain-notify server crashes and socket deletion. Previously, a deleted or crashed notify socket would leave virt-handler in a broken state requiring manual intervention. After upgrading, this recovers automatically. If you've been seeing unexplained VM communication failures on nodes, this is likely the culprit.

KubeVirt v1.6.5 is a patch release with 61 fixes targeting decentralized live migration reliability, virt-handler stability, and monitoring accuracy.

• breakingBackend storage volume rename may affect existing tooling

  VMs using backend storage volumes will now report the volume name as 'persistent-state-for-this-vm' rather than a name derived from the VM name. If you have scripts, dashboards, or alerts that reference the old volume naming pattern, update them before upgrading. Check if any PVC-based tooling depends on that name convention.

• enhancementUpgrade if you rely on decentralized live migration

  Three separate bugs in decentralized live migration are fixed here: cross-volumeMode failures, broken migration for enlightened (Hyper-V) VMs, and incorrect 'succeeded' status reporting after compute migration. If your cluster runs Windows VMs or mixes volume modes, this patch directly unblocks those scenarios. Prioritize this upgrade over staying on v1.6.4.

• enhancementMonitoring alert baselines are now more accurate

  The low-count alert for KubeVirt components now fires based on the configured replica count in the deployment, not a hardcoded value. Non-schedulable nodes are also excluded from kubevirt_allocatable_nodes. Review your existing alert thresholds after upgrading — alerts may behave differently if your environment has non-schedulable nodes or custom replica counts.

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.16.4 is a security-focused patch release addressing 15+ CVEs across Kyverno's dependency chain, plus a critical behavioral change that disables HTTP in namespaced policies by default.

• securityUpgrade immediately — 15+ CVEs patched, including supply chain components

  This release patches CVEs across sigstore/rekor, go-tuf, docker/cli, Go stdlib, and Kyverno's own code. Several of these touch the image verification and policy fetch paths. If you're running any image signing workflows with Kyverno, the rekor and go-tuf bumps are directly relevant. Plan an upgrade in your next maintenance window — do not wait for the next major cycle.

• breakingHTTP disabled by default in namespaced policies (CVE-2026-4789) — test before upgrading

  Namespaced policies that fetch external data over plain HTTP will silently stop working after this upgrade. If you use URL context sources or external data fetches in namespaced ClusterPolicy or Policy resources, audit them for HTTP (non-HTTPS) endpoints before upgrading. This is a security hardening change, but it will break existing policies that relied on insecure endpoints. Switch those endpoints to HTTPS or migrate to HTTPS-capable data sources first.

• breakingRestricted ConfigMap access for namespaced policies — RBAC may need review

  Namespaced policies now have reduced ConfigMap access scope. If your policies rely on reading ConfigMaps outside their namespace for context or configuration, those reads will fail post-upgrade. Review your policy definitions for cross-namespace ConfigMap references and adjust either the policy logic or the access grants accordingly before rolling out this version.

v1.17.2 is a security-heavy patch release addressing multiple CVEs and fixing critical bugs in MutatingPolicy, ValidatingPolicy, webhook reconciliation, and namespaced policy handling.

• securityUpgrade immediately — 6+ CVEs fixed in this release

  This release patches at least six CVEs across dependencies and Go stdlib, plus CVE-2026-4789 which disables HTTP in namespaced policies by default. If you run namespaced policies that rely on HTTP-based external data sources or webhooks, audit those configurations before upgrading — they will stop working silently. Upgrade path: update your Helm chart or manifests to v1.17.2 and validate policy behavior in a staging environment first.

• breakingNamespaced policies: HTTP disabled and ConfigMap access restricted

  Two separate hardening changes affect namespaced policies. HTTP is now disabled by default (CVE-2026-4789), and ConfigMap access has been scoped down. If your namespaced policies fetch context from HTTP endpoints or read ConfigMaps outside their namespace, those policies will fail silently or error post-upgrade. Run a dry-run or audit scan against your namespaced policies before deploying to production.

• enhancementWebhook reconciliation loop fix — reduces controller churn in large clusters

  Inconsistent webhook rule ordering was causing repeated reconciliation loops, which generates excess API server load and noisy controller logs. This is fixed. If you've been seeing constant webhook object churn in your audit logs or elevated kyverno-controller CPU, this release resolves it. No action needed post-upgrade, but worth monitoring controller metrics after rollout to confirm stabilization.

Kubernetes v1.36 is a large release with multiple GA promotions, significant DRA expansions, new gang-scheduling APIs, and several metric renames that require immediate action before upgrading.

• breakingUpdate monitoring before upgrading: two metric renames

  The metrics `volume_operation_total_errors` and `etcd_bookmark_counts` have been renamed to `volume_operation_errors_total` and `etcd_bookmark_total` respectively. Any Prometheus alerts or Grafana dashboards using the old names will silently stop firing after upgrade. Audit your monitoring stack and update all references before rolling out v1.36 to production.

• breakingDRA RBAC changes required if using DRAResourceClaimGranularStatusAuthorization

  The `DRAResourceClaimGranularStatusAuthorization` feature gate is beta and on by default in v1.36. DRA schedulers and controllers now need explicit `update`/`patch` on `resourceclaims/binding`, and DRA drivers need `associated-node:update` or `arbitrary-node:update` on `resourceclaims/driver` scoped to their specific `resourceNames`. If you run DRA drivers, audit and update their RBAC manifests before upgrading, or pods will fail to schedule.

• breakingflex-volume and git-repo volume plugin removals

  kubeadm no longer mounts the flex-volume plugin directory automatically, and the git-repo volume plugin is permanently disabled. If any workloads still use git-repo volumes, they will stop working — there's no flag to re-enable it. Migrate to an init container pattern or a CSI driver. For flex-volumes in kubeadm environments, you must manually configure extraVolumes and a non-distroless KCM image before upgrading to v1.36.

• breakingStrictIPCIDRValidation on by default — check your IP/CIDR fields

  API fields now reject IPs with leading zeros (e.g., `010.0.0.1`) and CIDRs with host bits set (e.g., `192.168.1.5/24` instead of `192.168.1.0/24`). Existing objects are preserved via validation ratcheting, but new creates and updates will fail if they use these formats. Audit your manifests, Helm charts, and automation for non-canonical IP/CIDR values before upgrading.

• enhancementMutatingAdmissionPolicy is now GA — consider replacing webhook boilerplate

  MutatingAdmissionPolicy (CEL-based mutation) is now v1 and enabled by default. If you're running simple mutating webhooks that set defaults or inject labels/annotations, this is a good time to evaluate replacing them with MutatingAdmissionPolicy resources. CEL-based policies eliminate the need to maintain webhook servers, certificates, and availability concerns. Start with low-risk, stateless mutations.

CoreDNS v1.14.3 ships full TSIG verification across all transports, multiple Go security CVE fixes, cache prefetch improvements, and a new forward plugin max_age option — a solid operational hardening release.

• securityUpgrade immediately for 13 Go CVE fixes and TSIG transport hardening

  Go 1.26.2 in this build addresses 13 CVEs. Beyond the runtime fixes, TSIG verification gaps in DoH, DoH3, QUIC, and gRPC transports are now closed — if you run any of those transports with TSIG, unauthenticated requests could previously slip through. Upgrade to v1.14.3 and verify your TSIG configurations are still valid after the stricter enforcement.

• breakingDoH oversized GET requests are now rejected — validate your clients

  CoreDNS now rejects oversized dns query parameters in DoH GET requests. Any client sending unusually large DNS-over-HTTPS GET queries will start getting errors. Test your DoH clients against this build in staging before rolling out; most well-behaved clients are unaffected, but custom or non-standard DoH implementations should be checked.

• enhancementUse max_age in the forward plugin to prevent stale upstream connections

  Long-lived upstream connections can silently degrade or get dropped by middleboxes. The new max_age option in the forward plugin lets you set an absolute connection lifetime. If you've seen sporadic upstream timeouts or resolution failures that resolve themselves, configure max_age to force periodic reconnection — start with something like 30s–5m depending on your upstream stability.

v2.0.4 is a minor maintenance release with TLS improvements for wash dev/host, a Helm chart fix for gateway routing, and governance updates.

• breakingCheck your Helm chart values if using local gateway routing

  The gateway is now disabled in values.local.yaml, and the hello-world example routes through a Kubernetes Service instead. If you forked or customized local Helm values with gateway-based routing, your setup may stop working after this update. Review your local values files against the updated defaults before upgrading.

• enhancementEnable TLS on wash dev/host if you're running local or production clusters

  TLS support now works across both wash dev and wash host. If you've been skipping TLS for local dev because it was unsupported, that excuse is gone. Test your TLS config in dev to catch certificate or connection issues before they surface in production.

Argo CD v3.3.8 is a patch release with six bug fixes targeting core mode syncs, AppSet resource limits, CLI diff accuracy, and informer cache staleness.

• breakingRefresh behavior changed again — validate your autosync pipelines

  The revert of the informer resync fix means refresh behavior is back to pre-3.3.7 state. If you tuned anything around reduced refresh frequency after upgrading to 3.3.7, re-examine those assumptions. Check autosync event logs to confirm expected behavior before promoting to production.

• enhancementCore mode users: upgrade immediately to unblock syncs

  The missing server.secretkey bug caused silent sync failures in core mode deployments — a serious operational gap that's easy to miss in monitoring. If you run Argo CD in core mode, this patch is not optional. Upgrade, then verify sync status across all applications post-upgrade.

• enhancementLarge ApplicationSets now default to 5,000 resource status entries

  If you manage ApplicationSets with hundreds of apps, you may have hit the old resource status count ceiling without realizing it. After upgrading, review any ApplicationSets that showed truncated or missing resource statuses and confirm they now report correctly.

Argo CD v3.2.10 is a pure bug-fix patch that resolves five regressions, including a critical core-mode sync failure and a stale cache issue in RevisionMetadata.

• breakingCore-mode deployments: upgrade immediately if apps are stuck out-of-sync

  If you run Argo CD in core mode (no API server) and recently saw apps failing to sync with secret-related errors, the missing server.secretkey bug was silently blocking all syncs. Upgrade to v3.2.10 and verify affected apps reconcile cleanly afterward.

• breakingAutosync event message format reverted — re-check any alerting rules you updated

  A message format change introduced recently and then reverted means the autosync event messages are back to their original format. If you updated Prometheus alerting rules, Grafana queries, or log parsers to match the new format, roll those changes back before upgrading to avoid false positives or missed alerts.

• enhancementsourceHydrator users: upgrade to get correct app diff behavior

  The CLI was using the wrong source revision for app diff and manifests commands when sourceHydrator was in use, meaning you could be reviewing diffs against the wrong state. After upgrading, re-run any diff checks you performed on v3.2.9 to confirm the output is accurate.

Patch release with two targeted bug fixes: a revert of a problematic refresh prevention change and a core mode sync failure when server.secretkey is absent.

• breakingRevert of refresh-prevention fix may re-expose original behavior

  The cherry-picked fix for preventing automatic refreshes from informer resyncs and status updates was reverted because it caused problems in 3.1. If you upgraded to 3.1.x specifically expecting that behavior to be fixed, it's gone again. Watch the upstream issue for a corrected implementation before relying on it. No action needed otherwise, but be aware of potential extra refresh churn in large clusters.

• enhancementUpgrade immediately if running Argo CD in core mode without server.secretkey

  A bug caused the application controller to fail syncing entirely when running in core mode and the server.secretkey was absent from the cluster secret. If your core-mode installations have ever had intermittent sync failures that were hard to diagnose, this is likely the culprit. Upgrade to 3.1.15 and verify syncs resume normally after rollout.

Flux v2.8.6 is a patch release fixing helm-controller post-renderer conflicts, a notification-controller regression for generic providers, and adding a MigrateAPIVersion feature gate in kustomize-controller.

• breakingAdd 'audience' to GCR Receiver secrets before upgrading to v2.9

  The 'audience' field on GCR Receiver secrets is currently optional but will become mandatory in v2.9. Audit your Receiver resources now and add the audience field to any GCR-backed secrets. Doing this proactively prevents a hard failure on your next major upgrade.

• breakingGeneric provider commit status events were broken — upgrade immediately if you rely on them

  A regression in notification-controller stopped generic providers from forwarding commit status events. If your CI/CD pipelines depend on those webhooks for pipeline gating or observability, they have been silently failing since the prior release. This patch restores that behavior — upgrade to v2.8.6 without delay.

• enhancementUse MigrateAPIVersion feature gate when managing resources with deprecated API versions

  If kustomize-controller manages resources that use older API versions tracked in managed field entries, the new MigrateAPIVersion feature gate handles migration automatically. Enable it in environments where you're seeing API version drift or drift detection noise from deprecated APIs.

KubeVirt v1.8.2 is a patch release with 12 bug fixes covering hotplug volumes, live migration, TLS config, qcow2 disk handling, and multi-arch VM stability.

• breakingBackend storage volume naming changed — check for impacts

  VMs using backend storage volumes will now report the volume name as 'persistent-state-for-this-vm' instead of a name derived from the VM name. If you have monitoring alerts, scripts, or tooling that match on the old volume name pattern, they will silently break. Audit any automation that references backend storage volume names before upgrading.

• enhancementUpgrade s390x and ARM64 clusters — arch-specific VM failures resolved

  Two separate fixes land here: ARM64 guests now correctly expose SMBIOS system info, and s390x VMs failing to create due to unsupported PCIe root-port controllers from the v3 PCI topology change are fixed. If you're running multi-arch clusters and held back on v1.8.x due to these issues, v1.8.2 is the version to move to.

• enhancementTLS config from KubeVirt CR now respected by sync-controller and virt-exportserver

  Previously, the sync-controller healthz server and virt-exportserver ignored the TLSConfiguration set in the KubeVirt CR, potentially using weaker defaults. After upgrading, verify your KubeVirt CR TLS settings are correct — they'll actually take effect now. This matters most for clusters with strict cipher or TLS version requirements.

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.

Crossplane v2.2.1 patches two user-reported bugs — ImageConfig prefix rewrite dependency upgrades and ResourceSelector handling — plus a broad sweep of security dependency updates.

• securityUpgrade to v2.2.1 immediately for dependency security fixes

  This release pulls in security patches for at least 8 upstream libraries including cosign, go-git, go-jose, and cloudflare/circl. These are not cosmetic bumps — go-git had two separate security-tagged updates in this release alone (v5.17.1 and v5.18.0). If you're running v2.2.0, plan the upgrade now. The patch is a drop-in replacement with no breaking changes.

• breakingVerify your ImageConfig prefix rewrite setups after upgrading

  If you use ImageConfig prefix rewrites to redirect package pulls (e.g., to a private registry mirror), your packages may have been silently stuck on stale dependency versions before this fix. After upgrading to v2.2.1, expect Crossplane to reconcile and potentially upgrade dependent packages that were previously frozen. Review installed package versions post-upgrade to confirm the expected state.

• enhancementComposition functions can now use broad ResourceSelectors safely

  Composition functions that need to select all existing resources of a given kind no longer need workarounds. A ResourceSelector with only apiVersion and kind set is now valid. If you patched around this limitation with explicit matchLabels or matchName wildcards, you can simplify those selectors in your function logic.