Releases

v0.153.0 stabilizes seven feature gates (breaking), fixes a critical memory corruption bug in gRPC Snappy compression, and ships several mdatagen enhancements for component authors.

• securityUpgrade immediately if you use gRPC with Snappy compression

  The Snappy fix in configgrpc addresses memory corruption that can cause fatal errors — this is a process-crash-level issue, not just a performance concern. If your exporters or receivers use gRPC with Snappy compression enabled, treat this as a priority upgrade. Check your exporter configs for compression: snappy settings.

• breakingAudit your feature gate overrides before upgrading

  All seven stabilized gates are now permanent behavior — you can no longer toggle them. If your collector config or startup flags reference configoptional.AddEnabledField, confmap.newExpandedValueSanitizer, exporter.PersistRequestContext, otelcol.printInitialConfig, pdata.useCustomProtoEncoding, telemetry.UseLocalHostAsDefaultMetricsAddress, or pdata.enableRefCounting, remove those references or the collector will fail to start. The metrics address change (UseLocalHostAsDefaultMetricsAddress) is the one most likely to surprise teams — your metrics endpoint is now localhost-bound by default.

• breakingmdatagen reaggregation config is now on by default

  If you maintain custom collector components using mdatagen, the reaggregation config fields are now generated by default. To preserve the old behavior (metrics config with only the enabled field), explicitly set reaggregation_enabled: false in your metadata.yaml. Run mdatagen on your components after upgrading and review the generated output before committing.

v1.20.8 is a security-only patch for the v1.20 line, bumping Go to 1.25.10 and patching multiple dependency CVEs across go-git, golang.org/x/net, x/crypto, and docker/cli.

• securityUpgrade v1.20 clusters to v1.20.8 now — multiple CVEs addressed

  This patch covers a broad sweep of dependency CVEs: go-git (two separate fixes), golang.org/x/net, golang.org/x/crypto, docker/cli, and in-toto-golang, plus Go stdlib CVEs via the 1.25.10 runtime bump. If you're running any v1.20.x version below this, you're exposed. The go-git and x/crypto vulnerabilities are particularly relevant if your Crossplane setup pulls packages from Git repositories. Plan the upgrade soon — this is not a 'schedule it next sprint' situation.

• enhancementConsider moving to v1.21+ if still on v1.20

  The v1.20 line is receiving security backports, but it won't get feature improvements. If you've been holding on v1.20 for stability reasons, this patch is a good opportunity to audit your upgrade blockers. The v1.21 line has been out long enough to be considered stable, and staying on an older minor version means you'll keep chasing security patches like this one.

v2.1.6 is a security-focused patch for the v2.1 line, bumping Go to 1.25.10 and patching several vulnerable dependencies including go-git, golang.org/x/crypto, and OpenTelemetry.

• securityUpgrade to v2.1.6 immediately if running v2.1.x

  This release patches multiple CVEs across Go stdlib, go-git, x/crypto, and x/net. These aren't theoretical risks — go-git vulnerabilities can affect package fetching behavior, and x/crypto/x/net issues can expose TLS and HTTP handling. If you're on any v2.1.x release, upgrade now. No API or behavioral changes are included, so the upgrade is low-risk.

• securityCheck your provider images for the same vulnerable dependencies

  Crossplane core is patched, but your installed providers (AWS, GCP, Azure, etc.) are separate images with their own dependency trees. Run a container image scan (Trivy, Grype) against your active provider pods to check if they carry the same vulnerable versions of go-git or x/crypto. Provider maintainers will need to release their own patches.

Pure security patch release: Go runtime bumped to 1.25.10 and several dependencies updated to address stdlib CVEs and git-related vulnerabilities.

• securityUpgrade to v2.2.2 immediately if running v2.2.x

  This release is entirely security-driven. Go 1.25.10 patches stdlib CVEs, go-git v5.19.1 addresses git-related vulnerabilities, and x/crypto v0.52.0 closes cryptographic issues. No feature or behavioral changes are included, so the upgrade risk is minimal. If your team scans images or has compliance requirements, staying on v2.2.1 or earlier will trigger findings — update now.

• securityCheck scanner results against the new image digest

  The go-git library was patched twice in quick succession, which suggests active exploitation pressure on that attack surface. After upgrading, re-run your vulnerability scanner against the new Crossplane image digest to confirm all findings are cleared. Pay particular attention to any CVEs tagged against git operations or supply-chain tooling, since in-toto-golang was also updated.

Crossplane v2.3.0 ships a high-fidelity local render engine, per-resource reconciliation control, alpha Provider deletion protection, and multiple security dependency bumps including Go stdlib CVE fixes.

• securityGo stdlib CVEs fixed — pull the new image

  Go was bumped to 1.25.10 specifically to address stdlib CVEs, on top of several other dependency security patches (grpc, go-git, go-jose, cloudflare/circl, golang.org/x/net). Update your Crossplane deployment to v2.3.0 promptly; if you mirror images internally, make sure the new digest is pulled before rolling out.

• breakingUpdate API import paths and bookmark the new CLI repo

  If you import Crossplane APIs in Go code, change `github.com/crossplane/crossplane/v2/apis` to `github.com/crossplane/crossplane/apis/v2` and note that `v1.Resource*` types are now `v2.ClusterManagedResource*`. Pin your CLI tooling to the new `github.com/crossplane/cli` repo — version numbers will diverge from core after this release, so update any scripts or CI pipelines that assumed aligned versioning.

• breakingUpgrade sequentially from v2.2 — do not skip minor versions

  Crossplane migrates CRDs on upgrade, and skipping minor versions can leave the API server in an inconsistent state. If you are on v1.20, that branch receives extended support but you should plan your migration to v2.x. Always follow the sequential upgrade path documented in the Crossplane upgrade guide.

• enhancementUse per-resource poll annotations to reduce API server load

  Set `crossplane.io/poll-interval: 24h` on stable, infrequently-changing XRs to dramatically cut reconcile frequency. Pair it with `crossplane.io/reconcile-requested-at` to trigger on-demand reconciliation when needed. This is available immediately for XRs; for managed resources, wait for your providers to release versions based on crossplane-runtime v2.3.0 before relying on it.

• enhancementEnable Provider deletion protection in non-prod first

  The new `--enable-provider-deletion-protection` alpha flag auto-creates `ClusterUsage` resources that block Provider deletion while managed resources exist. Useful safety net in shared clusters. Enable it in staging environments first to validate that your existing `ClusterUsage` webhook setup handles the auto-created resources correctly before rolling to production.

containerd v2.2.4 is a security-focused patch release addressing two CVEs plus several runtime fixes for overlay, sandbox, AppArmor, and seccomp behavior.

• securityPatch both CVEs — update to v2.2.4 now

  Two CVEs are fixed here: one in containerd itself (CVE-2026-46680) and one in the go-jose dependency (CVE-2026-34986). Both affect production deployments. Don't wait for your next maintenance window — push this update through your standard emergency patch process. If you run containerd on Kubernetes nodes, this applies to all container runtimes backed by containerd regardless of the orchestrator.

• securityAF_ALG is now blocked by default seccomp — test custom workloads

  The default seccomp profile now blocks AF_ALG (kernel crypto API via sockets). This reduces attack surface, but any workload relying on AF_ALG sockets — unusual but possible in cryptography-heavy or hardware-offload scenarios — will start seeing syscall denials. Run a quick audit of workloads with custom or permissive seccomp profiles before upgrading in production.

• enhancementUserNS + overlay users should upgrade to fix layer extraction

  If you run rootless containers or pods using user namespaces with the overlay snapshotter, the previous 'rebase' capability caused layer extraction failures. This patch disables that capability automatically in UserNS contexts. No config change needed — just upgrade and verify your rootless workloads mount correctly post-update.

containerd 2.0.9 patches CVE-2026-46680 and fixes a TOCTOU race in tar extraction, lost container exit events on restart, and several security hardening issues.

• securityPatch CVE-2026-46680 now

  A security vulnerability tracked as CVE-2026-46680 is fixed in this release. Any containerd 2.0.x deployment should be upgraded to 2.0.9 immediately. Check the GHSA advisory for affected configurations and severity before scheduling maintenance windows — this shouldn't wait.

• securityTOCTOU fix in tar extraction reduces image unpack risk

  The TOCTOU race during tar extraction could be exploited with a crafted image layer to escape expected paths. This is relevant for any environment pulling untrusted or third-party images. Upgrade and consider auditing your image pull policies if you haven't already restricted sources.

• breakingCheck AppArmor configs if running pre-3.0 AppArmor

  The AppArmor ABI field is now set conditionally, so systems running AppArmor older than 3.0 won't have an incompatible ABI injected into generated profiles. If you've been working around this with custom profiles, test your AppArmor setup after upgrading to confirm behavior is as expected.

• enhancementFix for lost exit events matters for high-churn workloads

  If you've seen containers stuck in unexpected states after a containerd restart — particularly in Kubernetes environments with rapid pod cycling — this fix addresses the root cause. No config change needed; upgrading is enough.

containerd 1.7.32 is a security-focused patch addressing CVE-2026-46680, plus hardening the default seccomp profile by blocking AF_ALG sockets and fixing OCI spec USER handling.

• securityPatch CVE-2026-46680 now — upgrade to 1.7.32

  CVE-2026-46680 is the primary driver for this release. Details are in the containerd security advisory. If you're running any 1.7.x version, treat this as a mandatory upgrade. Check the advisory for severity and attack surface before deciding on your maintenance window — but don't defer this long.

• securityAF_ALG is now blocked in the default seccomp profile — verify custom profiles

  The default seccomp policy now blocks the AF_ALG (kernel crypto) socket family. Containers relying on AF_ALG for hardware crypto offloading will break after this upgrade. Audit your workloads — most standard containers won't be affected, but custom crypto or HSM-adjacent workloads might. If needed, override via a custom seccomp profile rather than relaxing the default.

• breakingOut-of-range USER values now fail explicitly — check your container images

  Previously, an out-of-range UID/GID in the OCI spec could silently trigger name lookups with unpredictable results. Now containerd returns an error. If you have images or specs with numeric USER values outside valid range, containers will fail to start instead of behaving unexpectedly. Run a pre-upgrade check on your image inventory, especially anything using high numeric UIDs.

• enhancementAppArmor < 3.0 compatibility restored — relevant for older distros

  If you're running containerd on Ubuntu 20.04, Debian Bullseye, or any distro shipping AppArmor 2.x, earlier 1.7.x releases may have caused AppArmor profile load failures. This fix conditionally omits the abi directive. Upgrade and verify AppArmor profile loading if you've been seeing related errors.

containerd 2.3.1 patches CVE-2026-46680 and fixes several runtime/snapshotter bugs including seccomp hardening that blocks AF_ALG sockets by default.

• securityPatch CVE-2026-46680 now — upgrade from 2.3.0

  CVE-2026-46680 is fixed in this release. Details are in the containerd security advisory. If you're on 2.3.0, treat this as a mandatory upgrade. Check your package manager or deployment pipeline to roll out 2.3.1 across all nodes before the vulnerability details are widely circulated.

• securityAF_ALG blocked in default seccomp policy — test workloads that use kernel crypto

  The default seccomp profile now blocks AF_ALG (Linux kernel crypto API via sockets). Most containerized applications won't touch this, but anything using AF_ALG directly for cryptographic operations will break. Before upgrading in production, verify your workloads don't rely on AF_ALG — run a quick strace or audit your application's socket calls. Custom seccomp profiles are unaffected.

• breakingNon-runc runtime users: test sandbox task API behavior after upgrade

  The sandbox task API endpoint fix and deprecation of task fields in Runc options targets non-runc runtime setups (e.g., Kata Containers, gVisor). If your cluster uses alternative runtimes, validate that container creation and task management still work as expected post-upgrade. The deprecation of task fields means you should audit any custom Runc options configs to remove deprecated fields before they're removed in a future version.

v1.16.0 patches a critical OIDC token rejection bug after key rotation, fixes two correctness bugs in experimental weighted_graph_check, and updates Go to address stdlib CVEs.

• securityUpdate immediately if using OIDC auth or any Go stdlib CVEs apply

  Two separate security concerns here. First, the OIDC JWKS refresh fix means deployments that rotate issuer keys were silently rejecting valid tokens — if you've seen 401s after a key rotation, this is why. Second, the Go 1.24.3 update patches stdlib vulnerabilities; review the Go 1.24.3 release notes to assess exposure. Upgrade to v1.16.0 promptly in both cases.

• breakingweighted_graph_check users: validate results after upgrading

  Two correctness bugs were fixed in the experimental weighted_graph_check feature. Cache key collisions and false-negative caching from cancelled goroutines mean prior versions could return incorrect 'false' results. If you're running this in any meaningful capacity, run a validation pass against known-good authorization scenarios after upgrading to confirm behavior is now correct.

• enhancementConfigure PingTimeout to catch datastore connectivity issues faster

  The new PingTimeout and PingRetryMaxElapsedTime config options give you explicit control over how long OpenFGA waits to confirm datastore connectivity at startup and during health checks. Set these to values aligned with your SLOs — tighter timeouts surface infrastructure problems earlier instead of letting the server spin up against a degraded datastore.

NATS v2.14.1 is a substantial patch release fixing ~30 bugs across JetStream, clustering, and core messaging — several of them data-integrity and panic-level issues worth deploying promptly.

• securitygolang.org/x/crypto bumped to v0.51.0 — update now if you embed nats-server

  The x/crypto and x/sys dependency updates often carry CVE fixes. If you embed nats-server as a Go library (common in edge/IoT deployments), rebuild and redeploy. For standard deployments, just upgrade the binary. Don't sit on this one — crypto library updates in a messaging server are not optional hygiene.

• breakingReview the 2.14 Upgrade Guide before deploying — 2.13.x was skipped

  The release notes explicitly reference backwards-compatibility notes against 2.12.x, not 2.13.x, because that minor version was never released. If your team is running 2.12.x and skipped 2.13.x, read the 2.14 upgrade guide carefully before rolling out. Pay attention to JetStream consumer and stream API changes that may affect your clients.

• enhancementUse the new client-traffic /varz metrics for baseline observability

  The four new metrics (in/out client msgs/bytes) give you a cleaner split between client traffic and internal cluster/leafnode chatter. Wire these into your Prometheus scrape or monitoring dashboard now to establish baselines. This is especially useful for capacity planning on servers that handle mixed client and cluster traffic, since previously you had to infer client load from total metrics.

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.

Flux v2.8.8 patches two go-git CVEs in source and image-automation controllers, fixes a memory leak in helm-controller, and adds GCP sovereign cloud registry support.

• securityUpgrade immediately to patch two go-git CVEs

  CVE-2026-45571 and CVE-2026-45570 affect source-controller and image-automation-controller. Both are fixed in go-git v5.19.1 bundled with this release. If you run either of these controllers — and most Flux installations do — upgrade to v2.8.8 now. There's no workaround short of disabling those controllers.

• breakingReview charts that place non-CRD resources under crds/ directory

  Helm-controller previously force-applied any object found under a chart's crds/ directory, not just actual CRDs. That behavior is now corrected. If you have Helm charts (especially community or third-party ones) that bundle non-CRD manifests under crds/ as a workaround for install ordering, those objects will no longer be force-applied. Audit your HelmRelease resources and test in a non-production environment before rolling this out broadly.

• enhancementInvestigate artifact fetch timeouts if reconciliations have been stalling

  The new configurable HTTP timeout for artifact fetching directly addresses indefinite blocking during fetches. If you've seen helm-controller or source-controller reconciliations hang without clear errors, this fix likely explains it. After upgrading, configure the timeout explicitly rather than relying on defaults — check the helm-controller v1.5.5 changelog for the specific field name. Also worth auditing memory usage before and after upgrade if your helm-controller pods have been growing steadily in memory.

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.

v0.152.1 is a bug-fix-heavy release with one useful new metric. The most operationally impactful changes are snappy decompression security fixes and a Prometheus metric naming regression fix.

• securityconfighttp snappy fixes limit memory exposure from compressed payloads

  Three snappy decompression fixes land in `pkg/confighttp`: body is now closed after reading, panics in decompression libraries return HTTP 400 instead of crashing with 500, and `max_request_body_size` is enforced before the decoded buffer is allocated. The size-check fix in particular prevents a potential memory spike from a maliciously crafted compressed payload. If you accept compressed OTLP over HTTP from untrusted sources, upgrade.

• breakingPrometheus metric name format may change if you customized telemetry host

  If you explicitly set the `host` field in the telemetry metrics section of your collector config, check whether your Prometheus metric names changed after upgrading to recent versions. The bug caused `WithoutScopeInfo`, `WithoutUnits`, and `WithoutTypeSuffix` to default to false instead of true in that code path, which means your metrics may have had unexpected suffixes or scope labels. This release restores the correct defaults — metric names may shift again on upgrade, so update dashboards and alerts accordingly.

• enhancementAdd in-flight exporter metric to your dashboards

  The new `otelcol_exporter_in_flight_requests` UpDownCounter metric is available in `pkg/exporterhelper`. Add it to your dashboards to see when exporters are queuing up requests or saturating worker pools — it's a direct signal of export backpressure that was previously hard to observe without custom instrumentation.

Keycloak 26.6.2 is a security-heavy patch release addressing 16 CVEs spanning session fixation, XSS, access control bypass, redirect URI validation, and cryptographic weaknesses. Upgrade immediately.

• securityUpgrade immediately — multiple account takeover and data leakage CVEs

  This release patches session fixation (CVE-2026-7507) enabling account takeover, redirect URI bypass (CVE-2026-7504), access token disclosure (CVE-2026-7571), stored XSS in org templates (CVE-2026-37980), and PII enumeration via account resource lookup (CVE-2026-37981). These are not theoretical — they affect standard OIDC flows and admin APIs. Any Keycloak 26.x deployment should be upgraded to 26.6.2 without delay. Check your change management process, but treat this as an emergency patch.

• securityFreeMarker RCE risk — audit custom login themes before upgrading

  CVE tracked under #47915 allowed FreeMarker templates to instantiate arbitrary Java objects and execute OS commands. If you have custom login themes that accept any user-influenced input in FTL files, audit them now. The fix adds proper expression escaping in JS blocks within FTL pages. After upgrading, test your custom themes to ensure the new escaping doesn't break existing behavior — especially in frontchannel-logout.ftl.

• securityWebAuthn AAGUID policy bypass — re-verify authenticator enrollment policies

  CVE-2026-6856 allowed packed self-attestation to bypass AAGUID allowlist policies during WebAuthn registration. If you rely on AAGUID restrictions to enforce specific authenticator hardware (e.g., FIDO2 security keys in regulated environments), credentials may have been enrolled that violate your policy. After upgrading, review recently enrolled WebAuthn credentials and consider requiring re-enrollment if strict hardware attestation is a compliance requirement.

v2.9.0 adds HAMi-DRA for NVIDIA (now production-ready), Ascend HAMi-core mode, VastAI support, and patches a scheduler DoS vulnerability. Prometheus metric renames require dashboard updates before upgrading.

• securityPatch scheduler DoS vector and Go security upgrades

  Two scheduler-level security fixes land in this release: an io.LimitReader guard on scheduler HTTP routes to prevent DoS (issue #554), and a Go runtime upgrade to 1.26.2 for upstream security fixes. If you run HAMi scheduler exposed to any untrusted network path, upgrade promptly.

• breakingPrometheus metric names changed — update dashboards before upgrading

  Prometheus metric and label names have been realigned to follow best practices (renamed fields). If you have dashboards or alerts built against HAMi vGPU metrics, audit your metric names after upgrading. The existing dashboard.md has been updated — cross-reference it. The new ServiceMonitor Helm chart options also make scrape config cleaner if you're on the Prometheus Operator stack.

• enhancementHAMi-DRA for NVIDIA is production-ready — start evaluating

  HAMi-DRA (Dynamic Resource Allocation) for NVIDIA is now marked ready for use. If you're on Kubernetes 1.26+ and want finer-grained GPU resource management without relying solely on device plugins, this is the release to start evaluating DRA. Test in a non-prod cluster first — DRA changes how the scheduler sees GPU resources.

v1.120.2 is a substantial release with security fixes, memory leak patches, AWS CUR 2.0 support, OVH cloud provider, and supply chain security improvements via cosign image signing.

• securityUpgrade immediately for CVE-2026-34986 fix

  This release patches GHSA-xmrv-pmrh-hhx2 and CVE-2026-34986 in Go dependencies. If you're running any prior v1.120.x or v1.119.x version, upgrade to v1.120.2 now. Check your vulnerability scanner output to confirm the affected packages are resolved post-upgrade.

• enhancementVerify cosign image signatures in your admission pipeline

  OpenCost images are now signed with cosign keyless signing and include SLSA provenance attestations. If your cluster uses an admission controller (e.g., Kyverno, Connaisseur), add a policy to enforce signature verification on opencost images. This closes a real supply-chain gap for teams running OpenCost in regulated environments.

• enhancementEnable AWS CUR 2.0 and tune spot data feed behavior

  If your AWS billing is already on CUR 2.0, you can now configure OpenCost to use it directly. Additionally, if you don't use the AWS spot data feed, set the new toggle to disable it — this suppresses noisy warnings and avoids unnecessary config polling. Teams with spot-heavy workloads should also benefit from the new spot price API caching layer reducing API call volume.

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.

Litmus 3.29.0 patches a gRPC CVE, fixes duplicate chaos triggers under concurrent reconciles, and adds Prometheus metrics support for experiment observability.

• securityPatch CVE-2026-33186 by upgrading to 3.29.0 now

  The gRPC library was upgraded to v1.79.3 to fix CVE-2026-33186. If you're running any Litmus version prior to 3.29.0, your control plane is exposed. Upgrade immediately — this isn't a 'schedule it next sprint' situation.

• breakingVerify event-tracker behavior after the duplicate-trigger fix

  The fix for duplicate chaos experiment triggers under concurrent reconciles changes how the event-tracker handles race conditions. If you rely on the event-tracker for automated chaos injection, test your pipelines post-upgrade to confirm expected trigger counts. Duplicate runs may have been masking gaps in your experiment coverage.

• enhancementWire up Prometheus metrics to your existing dashboards

  Prometheus metrics are now natively exposed by ChaosCenter. The release includes a getting-started guide and unit tests, so integration is straightforward. Add Litmus as a scrape target and start tracking experiment pass/fail rates, run durations, and infra connectivity — this fills a long-standing observability gap for chaos workflows.

v7.0.0 fixes a Windows-specific security vulnerability in delegation path matching and tightens the ngclient API with one breaking constructor change.

• securityPatch Windows deployments immediately for GHSA-qp9x-wp8f-qgjj

  Delegation path matching was broken on Windows, meaning a malicious or misconfigured repository could match targets it shouldn't. If any of your TUF clients run on Windows, upgrade to v7.0.0 now. Linux/macOS deployments are unaffected, but upgrading is still the right move before paths diverge further.

• breakingUpdate all Updater() call sites to use the named bootstrap argument

  The Updater() constructor signature changed: 'bootstrap' is now a required keyword argument. Any code calling Updater() without explicitly passing 'bootstrap' will break. Audit your code for Updater instantiations — if you weren't passing a bootstrap value before, add bootstrap=None to restore the previous behavior. This is a one-line fix per call site, but it will cause an immediate TypeError if missed.

• enhancementWatch for securesystemslib.hash removal in upcoming releases

  This release starts phasing out the securesystemslib.hash dependency. If your codebase or any custom TUF extensions directly import or rely on securesystemslib.hash, start planning a migration now rather than scrambling when a future release drops it entirely.

Dapr v1.17.7 is a dense bug-fix release targeting workflow reliability, messaging correctness, and control-plane resilience. Fourteen production-grade fixes land here — upgrade if you run workflows, Kafka, or RabbitMQ.

• securityUpgrade sentry immediately if you downgraded from 1.18 or use Ed25519/RSA issuer keys

  A type-switch bug in dapr/kit caused sentry to crash on startup with 'unsupported key type' for Ed25519 and RSA issuer keys. Sentry enters a crash-loop, stops issuing mTLS identities, and halts cert rotation. Sidecars with unexpired certs keep running, but any pod restart or cert expiry silently breaks identity. If your trust bundle was generated by 1.18 or you manually rotated to Ed25519/RSA keys, this is a crash-loop waiting to happen. Upgrading to 1.17.7 is the only fix — no trust bundle migration needed.

• breakingScheduler etcd compaction mode change requires PVC capacity review

  The embedded etcd compaction mode switches from periodic (10 min) to revision-based (1,000,000 revisions), and the default storage size jumps from 1Gi to 16Gi. Kubernetes StatefulSet volumeClaimTemplates are immutable, so existing 1Gi PVCs are NOT automatically resized. If you're running the scheduler at any real workflow throughput, check your current PVC utilization now. If you're close to capacity, expand the PVC on the cluster before upgrading. The helm chart uses a lookup helper to avoid overwriting existing PVC sizes, but it cannot expand them for you.

• enhancementAdd workflow payload size ratio dashboards before upgrading

  Two new histograms — dapr_runtime_workflow_payload_size_ratio and dapr_runtime_workflow_activity_payload_size_ratio — report payload size as a fraction of --max-body-size. Before upgrading, set up a Prometheus alert on histogram_quantile(0.99, ...) > 0.9 so you catch workflows trending toward the 0.95 stall threshold before they freeze. This is especially useful for workflows with large activity payloads or long histories. Note: metrics are only recorded when --max-body-size is explicitly configured.

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.

Helm v3.21.0 bumps Kubernetes client libs to v1.36, patches OpenTelemetry CVEs, fixes OCI index chart pulling, and corrects nil value preservation in chart merging. Helm v3 EOL is approaching.

• securityUpgrade immediately to patch OpenTelemetry CVEs

  OpenTelemetry packages were patched specifically to address CVEs. If you're running Helm in CI/CD pipelines or as part of automation tooling, upgrade to v3.21.0 now. Don't wait for the next patch release.

• breakingPlan your Helm v4 migration — v3 EOL is real

  The release explicitly warns that Helm v3 is approaching end-of-life. This is not a distant concern — v3.22.0 targets Kubernetes v1.37 and v3.21.1 is just a bug fix release. Start evaluating Helm v4 changes now, especially if you maintain custom plugins or automation built around Helm's CLI or Go SDK.

• enhancementTest OCI index-based chart pulls if you use multi-arch registries

  The fix for pulling charts from OCI indices means setups using image index manifests (common in multi-arch environments) should now work reliably. If you previously worked around this with direct digest references or manifest-specific tags, revisit those workarounds — they may no longer be necessary.

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.

Argo CD v3.3.10 is a patch release fixing a nil-pointer panic in permission validation, a log line UI overflow bug, and bumping Go to 1.25.9 to address CVEs.

• securityUpgrade immediately — Go 1.25.9 fixes CVEs in the runtime

  The Go runtime was bumped from a prior version to 1.25.9 specifically to resolve CVEs. The release notes don't enumerate the CVE IDs, but any patch that upgrades the runtime for security reasons on a stable branch deserves prompt action. If you're running 3.3.x, upgrade to 3.3.10 now rather than waiting for your next maintenance window.

• breakingServer-side diff now correctly hides secrets — verify diff outputs if you rely on them

  The fix to apply HideSecretData to server-side diff results means that previously exposed secret values in diff views will now be redacted. If any automation, alerting, or audit tooling parses diff output expecting raw secret values, it will break. Review your diff-dependent workflows before upgrading.

• enhancementNil APIResource panic fix prevents unexpected controller crashes

  The permission validator could panic when an APIResource was nil — a condition that can occur with certain custom or non-standard API groups. If you've seen intermittent ArgoCD controller restarts without clear cause, this is a likely culprit. Upgrade to 3.3.10 to stabilize those environments.

Argo CD v3.4.2 is a patch release fixing a panic in the permission validator, reverting a problematic revision update optimization, and patching secret data exposure in server-side diffs.

• securitySecret values could appear in diff output — patch now

  Server-side diff results for Secret resources were not having HideSecretData applied, meaning secret values could be exposed in diff views through the UI or API. If you use server-side apply or server-side diff previews, upgrade to 3.4.2 immediately. Audit your ArgoCD API access logs if you suspect exposure.

• breakingUpdateRevisionForPaths revert may re-introduce previous behavior

  The optimization that avoided unnecessary UpdateRevisionForPaths calls (merged in 3.4.x) caused regressions and has been reverted. If you were relying on that behavior for performance or correctness, expect the pre-fix behavior to return. Monitor sync operations after upgrading, especially for path-filtered applications.

• enhancementPermission validator panic fix improves stability

  A nil APIResource in the permission validator could crash the ArgoCD server process. This is now guarded. If you've seen unexpected pod restarts on the ArgoCD server, especially in environments with non-standard CRDs or API aggregation, this patch likely addresses it.

v1.34.8 is a focused bug-fix patch addressing IPv6 CIDR allocation errors, a scheduler memory leak, Windows DNS routing failures, and several kubeadm cluster lifecycle issues.

• securitykubeadm now uses a dedicated ClusterRole for kube-apiserver kubelet access

  The kube-apiserver's kubelet client is now bound to 'system:kubelet-api-admin' instead of a shared role. For kubeadm-managed clusters, re-running 'kubeadm init phase bootstrap-token' or upgrading via kubeadm will apply this change. Existing clusters upgraded in-place will get this tighter RBAC scoping automatically — verify with 'kubectl get clusterrolebinding' post-upgrade.

• breakingIPv6 clusters: audit ServiceCIDR allocations before upgrading

  The 64-bit IPv6 ServiceCIDR bug means some clusters may have services with IPs that technically fall outside the configured subnet. After upgrading to v1.34.8, check whether any existing service IPs are out-of-range and consider recreating affected services. This primarily impacts clusters using /64 IPv6 service CIDRs.

• enhancementLarge clusters: kube-proxy full-sync elimination reduces control plane pressure

  If you're running clusters with 1000+ endpoints, kube-proxy was performing expensive full-sync operations unnecessarily in large-cluster mode. This patch stops that. The benefit is lower CPU and latency spikes during endpoint churn. No config changes needed — upgrade and monitor kube-proxy CPU usage to confirm the improvement.

v1.33.12 is a focused patch release with four kubeadm bug fixes targeting cluster init reliability, etcd health checks, and RBAC hardening for kubelet API access.

• securityRBAC isolation for kube-apiserver's kubelet client is now enforced

  The kube-apiserver now uses a dedicated ClusterRole 'system:kubelet-api-admin' for its kubelet client credentials. This tightens RBAC boundaries and reduces blast radius if credentials are ever misused. No immediate action required for existing clusters, but verify your RBAC audits reflect this role after upgrading kubeadm.

• enhancementUpgrade kubeadm if you use external load balancers during cluster init

  Previously, kubeadm init would write kubeconfigs pointing at the load balancer endpoint, which fails when the LB isn't provisioned until after the first apiserver starts — a chicken-and-egg problem common with cloud providers. The fix makes init use the local API endpoint instead. If you've been working around this with retry scripts or manual kubeconfig edits, this patch removes the need for those hacks.

• enhancementEtcd quorum-based health check prevents false failures in partially degraded clusters

  The old all-members health check would fail kubeadm operations if any etcd member was unhealthy, even when quorum was maintained. Now it only blocks when quorum is actually lost. If you run 3- or 5-node etcd clusters and have hit spurious kubeadm upgrade or join failures due to a single unhealthy member, this patch resolves that.

Flux v2.8.7 patches a CVE in go-git and fixes a destructive reconciliation bug where non-namespaced resources with ssa:IfNotPresent were being deleted and recreated every cycle.

• securityPatch CVE-2026-45022 by upgrading now

  go-git v5.19.0 fixes CVE-2026-45022, which affects source-controller and image-automation-controller — two components that actively clone and interact with Git repos. If your Flux installation pulls from any external or semi-trusted Git source, treat this as a priority upgrade. Run 'flux install' or update your Helm release to v2.8.7 immediately.

• breakingCheck non-namespaced resources using ssa:IfNotPresent for unintended churn

  If you're managing ClusterRoles, CRDs, or other cluster-scoped resources with the kustomize.toolkit.fluxcd.io/ssa: IfNotPresent annotation, those resources were being silently deleted and recreated on every reconciliation loop before this fix. Audit your Kustomization objects and verify resource state after upgrading to confirm the churn has stopped. Any dependent workloads may have experienced disruptions you weren't aware of.

• enhancementFollow the v2.7+ upgrade procedure if coming from v2.6

  The Flux team has a specific upgrade discussion thread for v2.7+ migrations. Skipping it when jumping from v2.6 to v2.8.7 can cause issues. Review the linked procedure before applying this update in environments running older Flux versions.

Flatcar stable-4593.2.1 is a security-only update: 130+ Linux kernel CVEs patched and the kernel bumped to 6.12.87. Reboot nodes to apply.

• security130+ Linux kernel CVEs patched — reboot nodes promptly

  This release patches 130+ Linux kernel CVEs (CVE-2026-31xxx and CVE-2026-43xxx series), rolling up kernel versions 6.12.82 through 6.12.87. The sheer volume suggests a large stable-kernel backport batch. Treat this as a high-priority update — schedule a node rolling restart via your update operator or manually drain and reboot nodes running stable-4593.2.0 as soon as your change window allows.

• enhancementCA certificates updated to NSS 3.123.1 — check custom CA chains

  ca-certificates updated to NSS 3.123.1. If you have services doing TLS certificate validation at the OS level (not inside containers), verify that trust store changes don't affect any pinned or custom CA chains after the node reboots.

Harbor v2.14.4 is a patch release fixing session management bugs, scanner API issues, and DockerHub token auth, with Go 1.25.9 and dependency security bumps.

• securityUpgrade immediately for go-jose and OTel SDK dependency fixes

  The go-jose/go-jose and go.opentelemetry.io/otel/sdk packages were explicitly bumped in this release, which typically signals CVE remediation. If your Harbor instance handles sensitive registry credentials or is exposed to external traffic, this patch should be prioritized. Plan an upgrade from v2.14.3 to v2.14.4 — it's a patch release with no breaking changes, so the risk of upgrading is low.

• breakingSession behavior changes — test SSO and long-lived browser sessions before rollout

  Two session-related fixes land here: background polling no longer refreshes session TTL, and SessionRegenerate args/lifetime were corrected. If your users rely on the UI staying logged in while background tabs are open, their sessions will now expire as configured rather than being silently extended. Validate your session timeout settings in Harbor's config and communicate expected behavior changes to your users before upgrading in production.

• enhancementDockerHub replication broken? This patch fixes the token auth flow

  If you've been seeing replication failures from DockerHub registries (especially after DockerHub API changes), the fix to use the /v2/auth/token endpoint should resolve them. After upgrading, verify your DockerHub replication rules by triggering a manual sync and checking the replication job logs. Also retest any distribution instance edits that involve credentials — a separate fix addresses a bug where editing a distribution instance without credentials caused issues.

v1.12.4 is a security patch release fixing a DoS vulnerability in the webhook server plus two scheduler correctness bugs. Upgrade immediately if running v1.12.3 or earlier.

• securityPatch the webhook server OOM vulnerability now

  CVE-2026-44247 lets any pod with network access to the webhook endpoint kill the webhook server by sending an oversized HTTP body, taking down admission control for the entire cluster. The CVSS scope is 'Changed', meaning the blast radius extends beyond the attacking pod. Any workload that can reach the webhook service is a potential attacker. Upgrade to v1.12.4 immediately. If you cannot upgrade right now, restrict network access to the webhook endpoint using NetworkPolicy to limit which pods or namespaces can reach it.

• breakingMulti-queue preemption may have been silently producing wrong results

  The preemptorTasks overwrite bug means clusters using multi-queue preemption could have been making incorrect scheduling decisions — lower-priority jobs potentially not being preempted correctly, or QueueOrderFn being ignored entirely. After upgrading, review preemption behavior in your queues. If you have queue ordering policies configured, verify they're now being applied as expected and check whether any jobs were stuck or incorrectly scheduled before the upgrade.

• enhancementStartup race condition in the scheduler is resolved

  The event handler completion fix addresses a subtle race where the scheduler could begin making decisions before all event handlers were ready. This was most likely to surface during controller restarts or rolling upgrades. No action required beyond upgrading, but if you've seen intermittent scheduling failures shortly after Volcano restarts, this is likely the cause.

v1.13.3 patches a DoS vulnerability in the webhook server (CVE-2026-44247) plus four scheduler bug fixes. Upgrade immediately if running v1.13.2 or earlier.

• securityPatch CVE-2026-44247 immediately — all v1.13.x ≤ v1.13.2 are vulnerable

  Any pod with network access to the Volcano webhook endpoint can send an arbitrarily large HTTP body and OOM-kill the webhook server, blocking all admission for jobs and queues. CVSS 6.8 (Moderate) but the blast radius is high in multi-tenant clusters. Upgrade to v1.13.3 (or v1.12.4 / v1.14.2 depending on your branch). If you can't upgrade immediately, restrict network access to the webhook service via NetworkPolicy to limit who can reach port 443 on the webhook server.

• breakingMulti-queue preemption behavior changes — validate workloads after upgrade

  Two preemption fixes alter scheduling decisions: preemptorTasks no longer get overwritten across queues, and QueueOrderFn is now enforced during preemption. If you rely on specific preemption outcomes in multi-queue setups, run a staging environment validation after upgrading. Jobs that were previously preempting others may no longer do so, or vice versa, depending on your queue priority configuration.

• enhancementScheduler startup race eliminated — relevant for frequent restarts

  The fix ensuring event handlers complete before scheduling starts matters most in environments where the scheduler pod restarts frequently (e.g., OOM restarts, rolling updates). Previously, a narrow race window could cause the scheduler to miss events. No config change needed — just upgrade and monitor scheduler logs at startup for any anomalies.

v1.14.2 patches a denial-of-service CVE in the webhook server plus a dense cluster of scheduler correctness bugs — upgrade immediately if you're on any 1.12/1.13/1.14 branch.

• securityPatch CVE-2026-44247 now — all prior 1.12/1.13/1.14 versions are affected

  Any pod with network access to the Volcano webhook endpoint can send an arbitrarily large request body and OOM-kill the webhook server, blocking all workload admission. CVSS 6.8 (Moderate) but the blast radius is high — a downed webhook halts job submission cluster-wide. Upgrade to v1.14.2, v1.13.3, or v1.12.4 depending on your branch. If you cannot upgrade immediately, consider restricting network access to the webhook service via NetworkPolicy to limit which pods can reach the endpoint.

• breakingCheck for scheduler panic-on-install if you recently deployed 1.14.x

  A race condition caused the scheduler to panic and restart during initial install. If you observed unexplained scheduler CrashLoopBackOffs after a fresh 1.14.x deployment, this is the fix. Upgrade and verify the scheduler pod stabilizes. No config changes needed, but review your monitoring alerts — silent restarts in production may have caused missed scheduling cycles.

• enhancementMulti-queue preemption and queue ordering are now reliable — re-validate your preemption policies

  Two distinct bugs in multi-queue preemption (preemptorTasks overwrite and QueueOrderFn not being honored) are fixed. If you rely on preemption across queues with custom ordering functions, the scheduler was likely not behaving as configured. After upgrading, run a validation cycle against your preemption scenarios to confirm jobs are being preempted in the priority order you expect. No configuration changes are required, but the behavioral change is real.

wasmCloud v2.1.0 delivers operator reliability fixes, plugin support in services, and a wave of CI security hardening — a solid incremental release with a few operator-side changes worth watching.

• securityBump wasmtime and run cargo audit in your own builds

  wasmtime was bumped alongside the removal of rustls-pemfile and the addition of cargo audit to the build pipeline. If you build wasmCloud components from source or maintain forks, add cargo audit to your own CI now. The dependency surface for WASM runtimes shifts fast, and catching advisories early matters.

• breakingOperator readiness behavior changed — review your health checks

  The operator now only marks WorkloadDeployment as Ready when replicas are actually available. If your CI/CD pipelines or monitoring poll readiness status, they'll behave more correctly — but any tooling that relied on the previous optimistic Ready state may see deployments appear 'stuck' longer. Validate your rollout timeout thresholds after upgrading.

• enhancementPlugin support in services opens new extension patterns

  Services now support plugins, which means you can attach custom behavior at the service layer without forking core components. If you've been waiting to extend service behavior in a maintainable way, this is the release to experiment with. Start by reviewing the updated service plugin API in the docs before designing new integrations.

v23.0.4 is a stability-focused patch release fixing multiple panics in VTOrc, VTGate, and ERS, plus critical VReplication and routing rule bugs that could silently misdirect traffic.

• securityGo upgraded to 1.25.9 — check your custom builds

  The Go runtime was bumped from 1.25.8 to 1.25.9 within this release cycle. If you build Vitess from source or maintain custom images, rebuild against go1.25.9 to pick up any runtime-level fixes included in that Go patch release.

• breakingUpgrade immediately if you use ERS or semi-sync replication

  Three separate ERS bugs were fixed: nil pointer panics during errant GTID detection, broken cancellation logic, and IO threads not restarting on replicas after ERS failure. Any of these can leave your cluster in a degraded state after a failover. If you run semi-sync with VTOrc, the ReplicationStopped + PrimarySemiSyncBlocked deadlock fix is equally critical — it could stall recovery entirely. Upgrade before your next planned maintenance window at the latest.

• enhancementRouting rule and schema-tracker fix affects multi-keyspace setups

  VTGate was not rebuilding routing rules after schema-tracker updates, and was dropping the target keyspace during routing rule AST rewrites. Both are silent bugs — queries appear to work but may land on the wrong keyspace. If you use routing rules with multiple keyspaces, validate query routing behavior after upgrading to confirm traffic is going where you expect.

v1.15.1 is a stability patch fixing two serious runtime bugs — a potential deadlock in Check and a semaphore leak under context cancellation — plus a cache collision in the experimental weighted graph check.

• securityCache key collision in `weighted_graph_check` could return incorrect authorization results

  If you're running the experimental `weighted_graph_check` feature, the cache collision bug means Check could return stale or wrong results for relationships in unions with direct types, wildcards, TTU paths, or intersections. This is an authorization correctness issue — wrong answers on permission checks. Upgrade before relying on this feature in any environment where correctness matters. If you can't upgrade immediately, disable the experimental feature flag.

• breakingUpgrade immediately — deadlock and semaphore leak bugs affect production stability

  Two bugs here can quietly degrade running services. The deadlock in Check (message streams held open on error) can starve request processing over time. The semaphore leak in the bounded tuple reader under context cancellation means goroutine/resource exhaustion under load or timeout-heavy workloads. Neither requires config changes — just upgrade. If you've seen unexplained Check hangs or increasing resource pressure after cancellations, these are the culprits.

• enhancementListObjects now handles short-circuit errors correctly

  A subtle bug was causing expected errors (non-fatal path short-circuits) to bubble up incorrectly in ListObjects responses. If you've seen unexpected errors returned from ListObjects queries that should have silently short-circuited, this fix resolves that. No action needed beyond upgrading — but worth re-validating ListObjects behavior in your test suite after the upgrade.