Releases

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.

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.

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.