Releases

wasmCloud v2.5.0 is a feature release centered on the wasmtime 46 upgrade with wasip3 enabled by default, alongside a breaking change to the keyvalue bucket WIT interface and a medium-severity quinn-proto security fix. The rest of the release adds new async keyvalue/blobstore interfaces, operator hardening, and various runtime and tooling fixes.

• securityquinn-proto security fix (RUSTSEC-2026-0185)

  Applies if you build or update wasmCloud from source or run dependency scans: quinn-proto is patched for RUSTSEC-2026-0185 (medium) in this release. Upgrade to pick up the fix; no application code changes needed.

• breakingkeyvalue bucket moved to shared types interface

  Applies if any component uses the wasmcloud:keyvalue interface: the bucket type moved out of the inline interface definition into a shared types interface. Components and providers built against the old wasmcloud:keyvalue WIT must update their bindings and regenerate code before upgrading.

• breakingwasmtime 46 with wasip3 enabled by default

  Applies to all components running on this runtime: wasmtime is now 46 and wasip3 support is on by default. Test existing components against the new runtime before rolling out broadly, especially anything sensitive to wasip3 behavior changes.

Crossplane v2.3.3 patches a TOCTOU security flaw in OCI package signature verification (GHSA-mf7q-r4rv-jv94) and fixes a namespace injection bug in `crossplane render`. Routine CVE bumps for Go deps included.

• securityUpgrade immediately to fix OCI signature TOCTOU (GHSA-mf7q-r4rv-jv94)

  The TOCTOU flaw means a compromised or malicious OCI registry could serve unsigned package content after passing signature verification. Any Crossplane deployment that installs packages from OCI registries is exposed. Upgrade to v2.3.3 — this fix lives in crossplane-runtime and is bundled in this release. Review the crossplane-runtime v2.3.3 advisory for full technical details and assess whether any packages installed on affected versions should be reinstalled.

• securitygolang.org/x/net and x/sys CVE patches — rebuild or upgrade

  The apis module now pulls updated golang.org/x/net and golang.org/x/sys. If you build Crossplane from source or vendor these deps in your own providers/functions, update your dependency pins to pick up the same CVE fixes. Pre-built images in v2.3.3 already include the patched versions.

• breakingcrossplane render namespace behavior changed for namespaced XRs

  If you use `crossplane render` in CI pipelines or local testing with namespaced XRs, the injected resource refs no longer carry a namespace. This matches real reconciler behavior and fixes breakage with strict-schema functions (e.g., KCL-generated bindings). Re-run your render tests after upgrading to confirm output changes don't mask real issues in your composition logic.

KubeVirt v1.8.4 is a patch release fixing a gRPC connection leak in virt-handler that caused memory growth, patching CVE-2026-35469 in spdystream, and adding missing metrics/alerts.

• securityPatch CVE-2026-35469 by upgrading to v1.8.4

  The moby/spdystream dependency carried CVE-2026-35469 (GHSA-pc3f-x583-g7j2). If you're on any v1.8.x release before v1.8.4, upgrade now. Check your internal scanner results for this CVE to confirm exposure before and after the upgrade.

• breakinggRPC connection leak fix may change virt-handler resource footprint

  The connection leak in GetLauncherClient caused unbounded memory and goroutine growth when multiple controllers raced on the same VMI. After upgrading, virt-handler memory usage should drop noticeably in clusters with high VMI churn. If you have memory-based alerts or resource limits tuned to the leaked baseline, revisit those thresholds post-upgrade.

• enhancementNew metrics and alerts for virt components — update dashboards

  Missing metrics, recording rules, and alerts were added for virt components. Review what's new against your existing Prometheus/Alertmanager setup and add any new alerts to your runbooks. This is a good time to audit alert coverage gaps you may have been living with.

Dapr v1.18.1 is a focused bug-fix release for the workflow engine, patching five issues including reminder leaks, permanent sidecar unavailability after config reload, and stuck workflows.

• breakingHelm users: workflow concurrency limits were silently ignored before this release

  If you set globalMaxConcurrentWorkflowInvocations, globalMaxConcurrentActivityInvocations, or the per-name limit fields on a Configuration resource and installed via Helm, those limits were never enforced. After upgrading to 1.18.1 the CRD schema is correct and limits will actually take effect. Review your configured values before upgrading in production — limits that were previously ignored will now be applied, which could throttle throughput if the values are too conservative.

• enhancementUpgrade if you run agentic or long-running loop workflows

  Three bugs in this release specifically affect workflows that loop via ContinueAsNew or repeatedly await the same external event name — patterns common in agentic workloads. The reminder leak accumulates garbage reminders over a workflow's lifetime; the ContinueAsNew deadlock causes indefinite hangs with no timeout or error. Both are fixed here. If you see workflows stuck in RUNNING or observe spurious wake-ups in loop workflows, upgrade to 1.18.1.

• enhancementConfig hot-reload now works reliably for workflow sidecars

  Before this fix, any SIGHUP-triggered config reload on a sidecar hosting workflow workers could permanently break the sidecar — port 50001 stops accepting connections and the only recovery was a pod restart. This is now fixed. If your team uses config hot-reload in any workflow-hosting deployment, 1.18.1 should be treated as a required upgrade.

Dapr 1.17.10 fixes a bug where resiliency retry policies with `matching` rules on pubsub publish operations were silently ignored, causing terminal errors to be retried unnecessarily. Teams using pubsub with resiliency retry configuration should upgrade to enforce intended retry behavior.

• breakingRetry behavior change for pubsub publish errors

  If you have resiliency policies with `matching` rules targeting pubsub outbound retry, publish errors will now be classified correctly and non-retriable errors will stop retrying immediately instead of exhausting maxRetries. Verify your resiliency configuration expectations: terminal errors (e.g., 401 Unauthorized, 404 Not Found) will no longer consume retry attempts. If your application relied on the old behavior of always retrying publish, adjust your retry policy or remove the `matching` constraint.

• enhancementEnforce resiliency policy intent for pubsub

  Upgrade to 1.17.10 if you've configured resiliency policies with explicit `matching` codes for pubsub publish — your configuration will now work as intended. This brings pubsub publish in line with service invocation, output bindings, and other operations that already respect retry `matching`. No code changes needed; the fix is transparent.

Dapr 1.16.16 fixes two downgrade-specific bugs: Sentry certificate signing failures after a 1.18→1.16 rollback, and Helm StatefulSet storage conflicts when downgrading from 1.17/1.18.

• breakingFollow specific Helm flags when downgrading to 1.16.16

  Use --reset-values and explicitly pass the original install values. Do NOT use --reuse-values — it carries over 1.17/1.18 chart defaults that are invalid in 1.16, including placement disseminateTimeout=8s (1.16 only accepts 1s–3s), which will cause placement to fail at startup. If you skipped deleting the scheduler StatefulSet before downgrading, you may still need to pass --set dapr_scheduler.cluster.storageSize=<current size> or delete the StatefulSet with --cascade=orphan.

• breakingClusters downgraded from 1.18 to 1.16 need this patch to fix Sentry

  If you rolled back from Dapr 1.18 to any earlier 1.16.x release, Sentry is likely crashing on startup due to the Ed25519/ECDSA key type mismatch in the trust bundle. Upgrade to 1.16.16 to resolve it — no manual certificate rotation is required after upgrading.

Dapr 1.16.15 fixes a sentry crash that blocks all mTLS identity issuance when the issuer key is Ed25519 or RSA — directly relevant to anyone who downgraded from 1.18 or rotated their issuer key type.

• breakingUpgrade to 1.16.15 if you downgraded from 1.18 or rotated your issuer key

  If your 1.16 control plane has an Ed25519 or RSA issuer key in the dapr-trust-bundle secret — which happens automatically after a 1.18 downgrade — dapr-sentry crash-loops and no new mTLS certificates are issued. Existing sidecars with unexpired certs keep working, but any pod restart or cert expiry will cause identity failures. Upgrade to 1.16.15 immediately. If you cannot upgrade right now, the only workaround is to replace the issuer key in dapr-trust-bundle with an ECDSA P-256 key.

Dapr 1.18 is a large release centered on workflow security and durability (tamper detection, access policies, history propagation, concurrency limits), with Jobs API and HotReload graduating to GA and several breaking changes requiring pre-upgrade review.

• securityEnable WorkflowAccessPolicy in shared or multi-tenant clusters

  Before 1.18, any caller in the same trust domain could schedule, terminate, or query any other app's workflows. The new WorkflowAccessPolicy CRD lets you lock this down per-operation with glob-pattern rules. The default is still open (no policy = all calls allowed), so existing deployments are unaffected — but teams running shared clusters should define policies now. Also: redis common components previously skipped TLS cert verification unconditionally; this is fixed in 1.18, so verify your Redis TLS config is correct before upgrading.

• breakingDo not roll back from 1.18 directly to 1.17.6 or earlier

  Sentry 1.18 writes an Ed25519-keyed CA into the dapr-trust-bundle secret. Any Sentry version before 1.17.7 cannot parse this and will crash-loop, blocking all new certificate issuance. Before upgrading, confirm your rollback target is 1.17.7+. If you need to go below 1.17.7, downgrade to 1.17.7 first, stabilize, then continue. Also audit any code that relied on silent workflow ID reuse — it now gets a hard conflict error.

• breakingHop-by-hop headers stripped on service invocation — check your apps

  Standard HTTP hop-by-hop headers (Connection, Keep-Alive, Transfer-Encoding, etc.) are now stripped during service invocation per RFC 7230. Any app relying on these headers passing through will silently break. Audit service invocation call sites and move to non-hop-by-hop equivalents before upgrading.

• enhancementEnable workflow history signing for audit-sensitive workloads

  Workflow history signing is opt-in and disabled by default. It requires mTLS to be active. Before turning it on cluster-wide, let any in-flight unsigned workflows complete or purge them — enabling signing on a workflow that started unsigned is a hard verification error with no catch-up path. Once enabled, a tampered workflow is terminated and flagged with DAPR_WORKFLOW_HISTORY_TAMPERED, leaving the original state intact for forensic review. Good candidate for compliance-sensitive or multi-tenant workflow deployments.

KEDA 2.20.1 fixes a critical race condition that caused panics during concurrent scaling and restores missing startup events for ScaledJobs. Upgrade required if running 2.20.0.

• securityUpgrade to 2.20.1 if you saw panic crashes during concurrent scaling

  A concurrent map read/write race condition in the status update logic caused KEDA to panic when ScaledObjects or ScaledJobs scaled simultaneously (multiple triggers active at once). This is fixed in 2.20.1. If you experienced panics in 2.20.0 during periods of high scaling activity, upgrade immediately.

• breakingReview breaking changes in v2.20.0 before upgrading

  KEDA 2.20.0 introduced breaking changes. If you operate KEDA clusters on versions before 2.20.0, review the v2.20.0 release notes at the GitHub link provided in the warning before upgrading to 2.20.1. Do not skip directly from < 2.20.0 to 2.20.1 without reading those notes first.

• enhancementRestore ScaledJob scaler startup event visibility

  KEDA was failing to emit the KEDAScalersStarted event for ScaledJobs due to Kubernetes event aggregation key collision. Monitoring tools or dashboards relying on this event to track scaler initialization may have missed ScaledJob startup signals. Upgrade to 2.20.1 to restore proper event emission.

Patch release adding a v2 upgrade readiness scanner, a golang.org/x/net security fix, and a runtime bump. The new CLI command is the practical reason to upgrade now.

• securityUpdate immediately for golang.org/x/net fix

  golang.org/x/net was updated to v0.55.0 to address a security issue. The release notes tag this as a security dependency update, so treat it as mandatory. Upgrade to v1.20.9 before the next planned maintenance window, don't wait for a convenient moment.

• breakingTreat upgrade check findings as real blockers, not warnings

  The command reports usage of features that are removed or changed in v2 — native patch-and-transform Compositions, ControllerConfig, external secret stores, and unqualified package sources. These are not deprecation warnings; they are hard blockers. If your control plane has any findings, start migration work using the linked guides before attempting any v2 upgrade. Ignoring them and upgrading anyway will break running workloads.

• enhancementRun upgrade check before any v2 planning work

  If your team is on a v1.x control plane and Crossplane v2 is anywhere on the roadmap, run `crossplane beta upgrade check` against your environment now. It surfaces exactly which Compositions, ControllerConfigs, and package references will block an upgrade — saving hours of manual audit. Pipe it with `-o json` into your CI pipeline to enforce a clean bill of health before any v2 upgrade PR is merged. The non-zero exit code makes gating trivial.

KubeVirt v1.8.3 is a patch release with 75 fixes targeting security, authorization, live migration stability, and GPU/DRA device handling — all worth deploying promptly.

• securityPatch CVE and symlink traversal — upgrade now

  Two security issues demand attention: a gRPC CVE (GHSA-p77j-4mvh-x3m3) and a symlink traversal in the VMExport dir handler. Both are fixed in this release. If you use VMExport or expose VM data externally, treat this upgrade as urgent. Verify no malicious symlinks exist in existing VMExport directories before and after upgrading.

• breakingRecording rule renames — update dashboards and alerts before upgrading

  kubevirt_vm_created_total and kubevirt_vm_created_by_pod_total are deprecated outright, and multiple other recording rules are being renamed for naming convention compliance. If your Grafana dashboards, alerting rules, or SLO queries reference these metrics, they will silently stop matching after upgrade. Audit your observability stack now and migrate to the new names before rolling this out to production.

• enhancementLive migration is more reliable — especially on IPv6 and cross-namespace setups

  Several live migration bugs are resolved here: cross-namespace migration on IPv6 clusters now works, duplicate kubevirt_vmi_info series no longer break VirtualMachineStuckOnNode and VMCannotBeEvicted alerts, and GuestAgentPing probes no longer cause spurious pod restarts during migration. If you've been avoiding live migration in IPv6 or multi-namespace environments due to instability, this release clears those blockers.

KubeVirt v1.7.4 is a patch release fixing a CVE in gRPC, authorization bugs, live migration on IPv6, and probe-triggered pod restarts during VM lifecycle events.

• securityPatch CVE-2026-33186 by upgrading to v1.7.4 now

  The gRPC dependency was vulnerable to CVE-2026-33186. This is a direct dependency bump to 1.79.3, so upgrading your KubeVirt installation to v1.7.4 is the only required action — no configuration changes needed. Prioritize this if your cluster runs workloads exposed to untrusted input over gRPC.

• breakingAudit authorization if you use VNC, SEV, or evacuate subresources

  The SubjectAccessReview truncation bug meant RBAC checks were being evaluated against incorrect subresource names — which could have allowed access that should have been denied, or denied access that should have been allowed. After upgrading, verify that your RBAC policies for vnc/screenshot, sev/*, and evacuate/cancel subresources behave as intended. This is not just a security fix; it's a correctness fix for authorization logic.

• enhancementVMs using GuestAgentPing probes during migrations or pauses should no longer bounce

  If you've been seeing unexpected virt-launcher pod restarts during live migrations or VM pause operations, this was a known probe behavior issue. The fix suppresses false-positive probe failures during pre-copy target, post-copy source, user pause, snapshot, save, and dump states. No action required — just upgrade. If you had workarounds in place (e.g., disabling GuestAgentPing during migrations), you can now remove them.

KubeVirt v1.6.6 is a patch release fixing 9 notable bugs including a CVE remediation, authorization bypass in virt-api, and broken cross-namespace live migration on IPv6 clusters.

• securityPatch CVE-2026-33186 by upgrading to v1.6.6

  The grpc dependency was bumped to remediate CVE-2026-33186. If your KubeVirt deployment exposes gRPC endpoints or you're running in a multi-tenant cluster, this is the main reason to push this upgrade now. Check your current version and plan the rollout — this is a patch release so the upgrade path should be straightforward.

• securityFix incorrect SubjectAccessReview checks in virt-api — audit your RBAC

  virt-api was constructing SubjectAccessReviews with truncated subresource names for deep paths like vnc/screenshot and sev/*. This means authorization checks were running against wrong resource names, potentially allowing or denying access incorrectly. After upgrading, audit any RBAC policies that restrict access to VNC, SEV, or evacuation subresources to confirm they behave as intended.

• breakingIPv6 clusters: cross-namespace live migration was silently broken — verify after upgrade

  If you're running KubeVirt on an IPv6 cluster and rely on cross-namespace live migrations, those migrations were failing. This fix restores the expected behavior. After upgrading, run a test migration across namespaces in your IPv6 environment to confirm the fix holds before relying on it in production workflows.

• enhancementPCI hostdev users on mixed machine types: restart reliability improved

  VMs using PCI passthrough hostdevices were failing to restart after hotplugging a block volume. The root cause was PCI topology being gated only on architecture, not machine type. If you manage VMs with PCI hostdevices and have seen unexplained restart failures post-hotplug, this patch resolves it — no config change needed, just the upgrade.

Knative Serving v1.22.1 is a focused patch fixing an idle connection leak in the network prober, a memory leak in webhook matchers, and adding a 3MiB webhook request body size limit.

• securityApply the 3MiB webhook body limit immediately

  The new hard cap on webhook request body size closes a potential vector for memory exhaustion via oversized payloads. If you run Knative Serving in a multi-tenant or externally-exposed environment, upgrade to v1.22.1 now — don't wait for your next maintenance window.

• breakingWebhook requests larger than 3MiB will now be rejected

  If any of your workloads submit unusually large objects to Knative's admission webhooks (e.g., Services or Configurations with very large env var blocks or annotations), those requests will start failing after this upgrade. Audit object sizes before rolling out, and trim any oversized metadata or spec fields.

• enhancementUpgrade to stop slow memory and connection accumulation

  The prober connection leak and the expired-matcher memory leak are both cumulative — they degrade pod health gradually over time rather than causing immediate crashes. Clusters that have been running v1.22.0 for a while may already be affected. After upgrading, watch activator and webhook pod memory trends to confirm they stabilize.

v1.17.9 fixes a targeted bug where workflows using Azure Cosmos DB as their actor state store get permanently stuck in a purge loop when the customStatus row is absent.

• breakingUpgrade immediately if using Cosmos DB for workflow state

  Any deployment using state.azure.cosmosdb as the workflow actor state store is at risk. Affected workflows never get purged past their TTL, and the scheduler fires a purge attempt every second forever — burning CPU, generating log noise, and inflating your dapr_runtime_workflow_operation_count{status=failed} metrics. Upgrade to 1.17.9 and restart sidecars; stuck workflows recover on the next retention reminder fire automatically. No manual cleanup needed after upgrade.

• enhancementCheck metrics now to assess blast radius before upgrading

  Before upgrading, query dapr_runtime_workflow_operation_count with labels operation=purge_workflow and status=failed. A non-zero and growing count on a Cosmos DB deployment confirms you have stuck workflows. This tells you how many workflows will self-heal post-upgrade and gives you a clear before/after signal to verify the fix took effect.

KEDA v2.20 ships four breaking removals, an RBAC migration for Kubernetes events, two new scalers, and a wave of bug fixes including credential-leak and connection-leak patches across several scalers.

• securityPatch credential-leak and connection-leak issues in Pulsar, RabbitMQ, and AWS scalers

  The Pulsar scaler was leaking bearer/basic auth credentials on cross-host redirects or HTTPS-to-HTTP downgrades. RabbitMQ had an AMQP connection leak. AWS scalers (SQS, Kinesis, DynamoDB, CloudWatch) leaked TCP connections on scaler close. If you run any of these scalers, upgrading to v2.20 closes real attack surface and resource exhaustion vectors. No config changes needed, but consider rotating credentials used by Pulsar scalers as a precaution.

• breakingUpdate RBAC before upgrading — events.k8s.io migration is not optional

  If you use custom or restricted RBAC for KEDA, add create/patch on events.k8s.io/events to the operator role before you upgrade. The official Helm chart and manifests already handle this, but any out-of-tree RBAC will silently break event recording. Also audit your ScaledObjects for the four removed settings (GCP PubSub subscriptionSize, Huawei minMetricValue, IBM MQ tls, InfluxDB authToken in triggerMetadata) — resources using these will fail validation after upgrade.

• enhancementAWS cross-account scaling now works natively via External ID support

  The new External ID field in TriggerAuthentication podIdentity covers all AWS scalers. If you've been using workarounds for cross-account IAM assume-role scenarios, you can now use the native field. Update your TriggerAuthentication manifests to set the externalId field — no more custom IAM boundary hacks required.

Volcano v1.15.0 ships gang-aware preemption/reclamation, DRA queue quota, autoscaler-friendly scheduling gates, and a batch of critical scheduler stability fixes addressing double-counting, race conditions, and rollback correctness.

• securityApply CVE-2026-44247 webhook DoS fix and Prometheus XSS patch

  v1.15.0 includes a mitigation for CVE-2026-44247, which allowed oversized webhook request bodies to exhaust webhook server memory. The Prometheus dependency is also updated for a stored XSS advisory (GHSA-vffh-x6r8-xx99). Upgrade to v1.15.0 if you expose Volcano admission webhooks — there's no workaround short of upgrading.

• breakingDon't mix gangPreempt/gangReclaim with legacy preempt/reclaim

  The new gangPreempt and gangReclaim actions are mutually exclusive with the legacy preempt and reclaim actions in a scheduler action list. If you upgrade and add gang-aware actions without removing the old ones, you'll get undefined behavior. Audit your scheduler ConfigMap before upgrading — pick one set or the other. Also note that DRA scheduling is now on by default; if your cluster doesn't have DRA-capable drivers, explicitly set predicate.DynamicResourceAllocationEnable: false.

• enhancementEnable Scheduling Gates to stop autoscaler over-scaling on queue limits

  If you run Cluster Autoscaler or Karpenter alongside Volcano, queue-blocked pods previously triggered unnecessary node scale-ups. The new scheduling gate feature fixes this cleanly. It's opt-in per pod via the scheduling.volcano.sh/queue-allocation-gate: 'true' annotation. Enable the feature gate on both the scheduler and webhook-manager, then annotate workloads that should respect queue admission before autoscaler signals fire. Good candidate workloads: batch jobs with strict queue quotas where you want to avoid wasted node provisioning.

v1.17.3 fixes a chart upgrade blocker, corrects multi-cluster search visibility, prevents over-scheduling, and stabilizes cluster readiness detection during credential rotation.

• breakingUnblock chart upgrades: ConfigMap size issue resolved

  The karmada-operator-chart had a ConfigMap size overflow when embedding the Karmada CRD, blocking chart upgrades. This is fixed in v1.17.3. If you are stuck on an older chart version due to this error, upgrade immediately to restore your ability to update Karmada deployments.

• breakingScheduler now respects cluster resource limits

  The scheduler previously allowed multiple workload replicas to land on a single cluster even when it had insufficient resources. v1.17.3 fixes over-scheduling. Audit your current deployments after upgrade to verify actual placement against your expectations, and adjust replica counts if needed.

• enhancementSearch now reflects recovered cluster resources correctly

  karmada-search now correctly watches recovered clusters and reflects their resources without delay. If you rely on search functionality across cluster recovery scenarios (failover or restoration), upgrade to v1.17.3 to ensure visibility into newly recovered member clusters.

• enhancementCluster readiness now waits for failure threshold

  A temporary credential rotation failure (missing SecretRef) now waits for the ClusterFailureThreshold before marking a cluster NotReady, instead of failing instantly. This prevents hair-trigger failovers during routine rotation. No action required if you already have a stable credential rotation process; this reduces false positives for teams that do.

Karmada v1.16.6 fixes three reliability issues: watch-based resource discovery on cluster rejoin, scheduler over-committing resources under concurrent scheduling, and hair-trigger cluster failover on temporary credential errors.

• breakingFix scheduler resource exhaustion vulnerability

  The scheduler previously allowed workloads to land on clusters with insufficient resources if multiple template resources were being placed simultaneously. Upgrade to v1.16.6 to enforce proper resource availability checks. Review your cluster resource limits and current deployments to confirm they respect intended capacity constraints post-upgrade.

• breakingCluster readiness now respects failure threshold

  Transient credential issues during secret rotation no longer immediately mark clusters as unready and trigger failover. Karmada now respects the ClusterFailureThreshold before degrading cluster status. If you tune ClusterFailureThreshold or rely on rapid failover behavior, test cluster credential rotation in a staging environment to confirm failover timing matches your expectations.

• enhancementWatch discovery now reflects recovered cluster resources

  Karmada-search now properly mirrors resources from clusters that rejoin after network issues or restarts. If you run multi-cluster deployments with watch-based resource discovery, verify after upgrading that recovered clusters' resources reappear in search results without manual intervention. Monitor search logs for any delays in resource reconciliation on rejoined clusters.

v1.18.0 adds overflow cluster affinities for hybrid cloud burst scheduling and a scheduling overcommit protection mechanism. Mandatory step: upgrade to v1.17.3+ before applying this release.

• securityAlpine base image updated to 3.23.4

  The base Alpine image moved from 3.23.3 to 3.23.4. No action needed beyond the normal upgrade, but if you pin image digests in your deployment, update them accordingly.

• breakingUpgrade to v1.17.3+ before moving to v1.18.x

  Before upgrading to v1.18.x, you must first be on v1.17.3+. Skipping this step will break the operator upgrade. Check your current version with `karmadactl version` and upgrade to v1.17.3+ first if you are behind.

• breakingDeprecated gRPC fields in scheduler-estimator require plugin updates

  Several deprecated gRPC fields in karmada-scheduler-estimator are now replaced: `resourceRequest` → `resourceRequestBytes`, `nodeAffinity` → `nodeAffinityBytes`, `tolerations` → `tolerationsBytes`. If you have custom estimator plugins or tooling that reads these fields directly, update them before upgrading. The old fields still exist in v1.18 but are deprecated and will be removed in a future release.

• breakingRemoved flags and metric labels will break existing configs

  Two flags removed from karmada-controller-manager: `--cluster-lease-duration` and `--cluster-lease-renew-interval-fraction`. Also, `Etcd.Local.InitImage` is gone from Karmada Init Configuration. If your deployment scripts or Helm values reference these, remove them before upgrading or the components will fail to start. Also check your Prometheus dashboards: the `cluster` and `cluster_name` metric labels are gone, replaced by `member_cluster`.

• enhancementCritical scheduler and eviction bug fixes

  Two significant scheduler bugs are fixed in this release. First, bindings with insufficient cluster replicas were retrying via exponential backoff (1–10s) instead of the correct 5-minute timer queue — workloads may have appeared stuck. Second, a race condition could silently drop graceful eviction tasks when multiple controllers modified the same ResourceBinding concurrently, meaning workloads might not have been evacuated from failing clusters. If you have observed unexplained scheduling delays or failed evictions, upgrade to v1.18.0 and re-examine affected workloads.

• enhancementEnable SchedulingOvercommitProtection in high-throughput clusters

  SchedulingOvercommitProtection (disabled by default via feature gate) closes the window where back-to-back scheduling decisions could over-commit a cluster's capacity before Pods are actually bound to nodes. Enable it in high-throughput environments where you see workloads going Pending due to resource exhaustion shortly after scheduling. Set `--feature-gates=SchedulingOvercommitProtection=true` on karmada-scheduler and karmada-scheduler-estimator once you've validated in staging.

• enhancementOverflow Cluster Affinities for hybrid cloud burst scheduling

  The new `overflowAffinities` field in PropagationPolicy/ClusterPropagationPolicy lets you define fallback cluster groups. The scheduler fills the primary group first, then spills to supplementary groups in order. On scale-down, replicas are reclaimed from supplementary groups first. Useful for IDC-primary / public-cloud-overflow patterns. This is a new API field — existing policies are unaffected unless you add it.

v1.17.8 fixes two issues: workflows getting permanently stuck when reusing completed instance IDs, and a Sentry OIDC security flaw (CWE-346) that allows discovery document poisoning via X-Forwarded-Host.

• securityFix OIDC discovery document poisoning via X-Forwarded-Host

  Sentry OIDC deployments running without `--jwt-issuer` or `--oidc-allowed-hosts` are vulnerable to CWE-346: an attacker who can send requests with a forged `X-Forwarded-Host` header can poison the discovery document, and HTTP caches may serve the poisoned response for up to an hour. If you can't upgrade immediately, set `--jwt-issuer` (pins the issuer statically, simplest fix) or `--oidc-allowed-hosts`. If you use a reverse proxy that needs to advertise its public hostname via `X-Forwarded-Host`, set `--oidc-allowed-hosts` to your expected hostname — this is now required for that header to take effect.

• breakingUpgrade to fix stuck workflows with reused instance IDs

  Any workflow using deterministic/stable instance IDs is affected. After upgrading sidecars to 1.17.8, stuck workflows recover automatically on the next retention reminder fire — no manual scheduler cleanup needed. Check your `dapr_runtime_workflow_operation_count{operation=purge_workflow,status=failed}` metric; if it's incrementing at ~1/sec per workflow, you're hitting this bug.

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.

wasmCloud v2.2.0 adds WASI Preview 3 TLS support, a customizable HTTP outgoing request handler, and several operator fixes for namespace-scoped deployments.

• breakingOperator users with `watchNamespaces` must verify RBAC after upgrade

  The fix for namespace-scoped role usage in the runtime operator changes which role bindings are applied when `watchNamespaces` is set. After upgrading, confirm your operator's RBAC permissions are correct and that it can still watch resources in the intended namespaces. A misconfigured role here means silent failures in component reconciliation.

• enhancementUse `wasi:tls` for native TLS in Wasm components

  WASI Preview 3 TLS support means you can now handle TLS connections directly inside Wasm components rather than relying on host-side termination or workarounds. If you're building components that make secure outbound connections, test against the new `wasi:tls` interface. This is early-stage — treat it as experimental in production until the WASI spec stabilizes further.

• enhancementUnblock CI pipelines with `--non-interactive` in `wash new`

  If you've been working around interactive prompts in `wash new` inside CI, this fix removes that friction. Update your pipeline scripts to use `--non-interactive` cleanly — no hacks required. Also worth re-examining your `wash config` flows now that validation and cleanup are built in.

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.

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.

A maintenance release focused on operator reliability, security hardening, and CI improvements. Key fixes address NATS workload readiness and Kubernetes operator deployment status accuracy.

• securityWasmtime bump + cargo audit added — review your own Wasm supply chain

  This release bumps wasmtime and drops rustls-pemfile, while adding cargo audit to CI. If you're building custom wasmCloud components or providers in Rust, add cargo audit to your own pipelines now. The removal of rustls-pemfile suggests a dependency consolidation — check if any of your code directly imports it and update accordingly.

• breakingOperator WorkloadDeployment readiness semantics changed

  The Ready condition on WorkloadDeployment now reflects actual replica availability rather than just the existence of the deployment. Any automation or health checks that relied on Ready=True firing quickly after deployment creation will now correctly wait for replicas to be up. Review any CD pipelines or readiness probes that poll WorkloadDeployment status — they should now behave more accurately, but may appear 'slower' to reach Ready.

• enhancementNATS subscription readiness fix reduces false-positive healthy states

  Previously, hosts could report as ready before NATS subscriptions were actually established. After this fix, readiness is tied to actual subscription availability. If you're running wasmCloud in Kubernetes and using readiness gates or traffic routing based on host health, upgrade to get accurate readiness signals and avoid routing traffic to hosts that aren't yet fully connected.

A maintenance release focused on operator reliability, NATS subscription readiness, and security dependency bumps — no API changes, but a few fixes matter in production.

• securityUpgrade to pick up wasmtime security bump and new audit pipeline

  wasmtime was bumped and rustls-pemfile was removed as a dependency in this release. cargo audit has also been wired into CI, meaning future vulnerabilities in the dependency tree will be caught earlier. If you're running 2.0.5 or earlier, upgrade now — there's no reason to stay on an older wasmtime in a Wasm runtime.

• breakingOperator readiness behavior changed — review your health checks and rollout strategies

  WorkloadDeployment Ready status is now gated on replica availability, not just the existence of a deployment object. If your CI/CD pipelines or monitoring systems check for the Ready condition to gate traffic or proceed with rollouts, they'll now see a more accurate (and potentially longer) 'not ready' window. Verify your rollout wait conditions and alerting thresholds won't false-alarm during normal startup.

• enhancementNATS subscription readiness fix — relevant if you've seen premature ready signals

  The fix for NATS subscription workload readiness means the host now correctly waits before reporting ready. If you've dealt with race conditions at startup where components tried to subscribe before NATS connections were fully established, this should resolve those. No config changes needed — just upgrade and validate your startup sequence behaves as expected.

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.

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.

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.

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.

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.

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.