Releases

Karmada v1.17.1 is a targeted patch fixing four bugs: a silent graceful eviction failure, a cert rotation loop, a Helm chart render issue, and an OpenAPI schema error.

• breakingSilent eviction failures: patch immediately if you rely on graceful eviction

  The race condition in graceful eviction is dangerous precisely because it fails silently. Workloads on tainted or failing member clusters may never get evacuated. If you run high-availability workloads across multiple clusters, upgrade to v1.17.1 now and verify any pending eviction tasks completed after the upgrade.

• breakingCertificate rotation was broken for karmada-agent — check your agent certs

  The SignerName mismatch meant CSRs submitted for cert rotation were never approved, leaving agents unable to renew certificates. Agents that have been running since v1.17.0 may have stale or near-expiry certs. After upgrading, check agent certificate expiry dates and manually trigger rotation if needed.

• enhancementHelm chart users: re-run upgrades after patching to fix TLS config

  If you upgraded karmada-chart on v1.17.0 and saw '{{ ca_crt }}' appear literally in your config, the CA cert was never injected. After upgrading to v1.17.1, re-apply your Helm upgrade to ensure the CA certificate is correctly rendered and TLS is not silently misconfigured.

Karmada v1.16.4 patches three bugs: a broken certificate rotation loop in karmada-agent, a Helm chart rendering failure on upgrades, and a race condition that silently dropped graceful eviction tasks.

• securityCertificate rotation was silently broken — rotate certificates after upgrading

  The SignerName mismatch meant that agent certificate rotation CSRs were never approved, so agent certificates were quietly expiring without renewal. After upgrading to v1.16.4, check the remaining validity of your karmada-agent certificates across all member clusters and manually trigger rotation if any are close to expiry. Don't assume rotation was working before this fix.

• breakingEviction race condition could leave workloads stranded on failing clusters

  If you run multiple controller replicas or have high-churn ResourceBindings, the race condition fixed in this release means your workloads may have silently failed to evacuate from tainted or unhealthy clusters. Upgrade to v1.16.4 immediately and verify that any in-flight eviction tasks complete. Check cluster taints and ResourceBinding status after upgrading to confirm nothing was left behind.

• breakingHelm chart upgrades with unrendered ca_crt will break TLS — re-run your upgrades

  The '{{ ca_crt }}' template variable was not being rendered during Helm upgrades, which would produce invalid TLS configuration silently. If you upgraded via Helm between v1.16.3 and this release, inspect your deployed chart values and secrets to confirm ca_crt is properly populated. Re-apply or re-upgrade using v1.16.4 if you suspect the broken rendering affected your environment.

Karmada v1.15.7 patches three bugs: a cert rotation deadlock in the agent, a Helm chart rendering failure on upgrade, and a race condition that silently dropped graceful eviction tasks.

• securityAudit agent certificates for expiry before upgrading

  The cert rotation bug could have left agents with expired certificates, creating an outage risk or a gap where mTLS wasn't enforced. Before upgrading, check the NotAfter field on agent certs. Post-upgrade, confirm the cert_rotation_controller and agent_csr_approving are now operating with matching SignerNames and that pending CSRs get approved.

• breakingCheck if cert rotation has been silently failing in your agents

  If your karmada-agent has been running for a while without certificate renewal, the SignerName mismatch bug means CSRs were never approved and certs may be expired or near expiry. After upgrading to v1.15.7, verify agent certificate validity and manually trigger rotation if needed. This is especially urgent in long-running clusters where cert TTLs are short.

• breakingSilent eviction failures may have left workloads on bad clusters — audit now

  The race condition in graceful eviction means any cluster that was tainted or marked unhealthy while multiple controllers were active may not have had its workloads evacuated. Before upgrading, check ResourceBinding and ClusterResourceBinding objects for stale taints or pending eviction conditions that were never resolved. Post-upgrade, re-trigger eviction for any affected bindings.

Dapr v1.16.12 patches a gRPC auth bypass CVE, fixes broken Pulsar Avro/JSON schema handling that blocked message delivery, and resolves a Scheduler cluster stall lasting up to 20 minutes after pod restarts.

• securityUpgrade immediately to patch gRPC auth bypass (CVE-2026-33186)

  CVE-2026-33186 allows unauthorized gRPC requests to bypass authorization under certain conditions. This affects all Dapr 1.16.x versions prior to 1.16.12. Upgrade now — there's no workaround that doesn't involve patching the dependency.

• breakingPulsar Avro + CloudEvents schema registration has changed — existing topics may need attention

  If you're running Dapr 1.16.0–1.16.11 with Pulsar topics using Avro schemas and CloudEvents wrapping (the default), the schema registered in Pulsar's Schema Registry was wrong. After upgrading, new schema registrations will use the correct CloudEvents envelope Avro schema. Check whether existing Pulsar topics have mismatched schemas in the registry and whether downstream non-Dapr consumers are affected. Use the new rawSchema metadata option only for topics intentionally serving raw payloads.

• enhancementScheduler HA deployments are no longer vulnerable to 20-minute stalls on pod restart

  Any HA Dapr deployment (3 Scheduler instances) with active workflows or actor reminders was at risk of a silent 20-minute outage after a pod restart. The fix makes engine shutdown context-aware, so in-flight triggers cancel immediately and the cluster re-establishes quorum in seconds. If you've been observing unexplained workflow/reminder gaps after rolling updates or node maintenance, this is the cause. Upgrade and also note that Dapr v1.17 redesigned the trigger path entirely to avoid this class of problem.

Volcano v1.13.2 is a focused patch release fixing five bugs: a panic in NUMA resource handling, GPU resource errors, scheduler snapshot corruption, and incorrect terminating pod behavior in jobs.

• securityPanic in NUMA snapshot could crash the scheduler — patch before scaling NUMA workloads

  A nil pointer / concurrent-write panic in NUMA resource info updating during snapshots can bring down the volcano-scheduler process. On NUMA-aware clusters, this means scheduling halts entirely until the pod restarts. If you're running topology-aware workloads, don't wait — patch to v1.13.2 before expanding those workloads.

• breakingScheduler snapshot mutation bug can corrupt scheduling decisions — upgrade now

  The shared mutable objects bug in scheduler snapshot clones (PR #5093) is the most serious fix here. If multiple scheduling cycles inadvertently share state, you get non-deterministic scheduling behavior that's extremely hard to diagnose. Any cluster running GPU or multi-task batch jobs under load should treat this as urgent. Upgrade from v1.13.1 to v1.13.2 immediately.

• enhancementGPU resource fix prevents ghost allocations on GPU nodes

  The GPU resource error fix addresses incorrect resource accounting that could lead to nodes appearing over-allocated or under-utilized. If you've noticed GPU pods stuck in Pending despite apparent capacity, or unexpected scheduling failures on GPU nodes, this patch likely resolves it. After upgrading, force a reconciliation by restarting the scheduler pod to clear any stale resource state.

KubeVirt v1.8.1 is a small patch release fixing two specific bugs: virt-handler domain-notify server crashes and VMExport failures with long PVC names.

• breakingUpgrade if virt-handler crashes are disrupting VM lifecycle events

  The domain-notify server handles communication between virt-handler and running VMs. If it exits unexpectedly without restarting, VMs can become unresponsive to lifecycle operations (start, stop, migrate) without obvious errors. If you've seen unexplained VM management failures after a virt-handler pod restart, this is your fix. Patch as soon as possible on v1.8.0 clusters.

• enhancementVMExport now works reliably with long PVC names — review your naming conventions

  If you use VMExport for backup or migration workflows and your PVCs follow long naming patterns (common with dynamic provisioners or namespace-prefixed names), test VMExport after upgrading. The prior failure was silent enough to cause confusion — confirm your export pipelines are functional post-upgrade.

Dapr v1.17.3 patches two CVEs (gRPC auth bypass, TIFF OOM DoS) and fixes several high-impact runtime bugs including actor response data loss over h2c, a cascading placement failure, and a scheduler silent-stop bug.

• securityUpgrade immediately for two active CVEs

  CVE-2026-33186 allows gRPC authorization bypass — unauthorized requests could reach your services. CVE-2026-33809 allows a malicious 8-byte TIFF file to trigger ~4GB memory allocation and OOM-crash a sidecar. Both are fixed only in v1.17.3. There is no workaround short of upgrading. Treat this as an urgent patch, especially if your Dapr components process any image data or expose gRPC endpoints to untrusted callers.

• breakingActor + h2c users were silently losing response data — verify your setup

  If you run actors with --app-protocol h2c, every actor method invocation since v1.17.2 could have returned HTTP 200 with an empty body. Your app received no error, just missing data. After upgrading to v1.17.3, audit any actor calls that might have been silently failing and verify response payloads are intact. If you log or cache actor responses, replay or revalidate any data collected since upgrading to v1.17.2.

• enhancementHA Scheduler deployments: restart pods after upgrade to clear stale leadership state

  The scheduler silent-stop bug left stale etcd leadership keys that block quorum convergence. After upgrading, do a coordinated restart of all Scheduler pods to force a clean leadership election. Going forward, workflow timers, scheduled jobs, and actor reminders should be reliable after rolling updates. If you previously saw reminders or jobs randomly stop firing after a Scheduler pod restart, this is the fix.

Three critical Scheduler HA bugs fixed — cascading crashes, silent partition stalls, and Windows AKS sidecar failures — plus a Go security bump to 1.25.8.

• securityGo 1.25.8 security patches — rebuild or upgrade

  Go 1.25.8 fixes vulnerabilities in html/template, net/url, and os packages. If you're running Dapr v1.16.10 or earlier, the binary was built against a patched Go version that still carries these issues. Upgrading to v1.16.11 picks up the fixed runtime automatically. If you also maintain custom Dapr-adjacent services built with Go 1.25.7, rebuild those separately.

• breakingUpgrade immediately if running Scheduler in HA mode

  Any multi-instance Scheduler deployment on v1.16.0–v1.16.10 is exposed to two distinct failure modes: a cascading crash under high job load, and a silent stall where instances hold partition leases but never fire jobs. Both require restarting all Scheduler pods to recover. Neither has a workaround short of upgrading. If you're running Dapr Workflows, actor reminders, or scheduled jobs in HA, treat this as urgent — workflows can stop firing entirely after a routine pod eviction or rolling update.

• breakingWindows AKS users: broken since v1.16.9, fixed here

  If you deployed Dapr on AKS Windows nodes between v1.16.9 and v1.16.10, your daprd sidecars have been stuck in CrashLoopBackOff. The root cause was a Docker manifest tooling change that dropped the os.version field, causing the Windows container runtime to pull the wrong image variant. Upgrading to v1.16.11 restores correct behavior — no manifest or config changes needed on your end.

KubeVirt v1.8.0 is a large release (1242 changes, 77 contributors) adding a new VM backup API, VMPool auto-healing, containerpath volumes, and multiple network/storage improvements with several breaking removals.

• breakingRemove SLIRP and Macvtap network bindings before upgrading

  Both core SLIRP and Macvtap bindings are completely removed in v1.8.0. If any VMs in your cluster use these bindings, they will break post-upgrade. Audit your VM specs now with a label/annotation query, migrate affected VMs to passt or bridge bindings, and validate in a non-prod environment before rolling this to production.

• breakingUpdate migration metrics in dashboards before upgrading

  kubevirt_vmi_migration_data_total_bytes is deprecated and will eventually be removed. If you have Grafana dashboards, Prometheus alerts, or recording rules referencing this metric, update them to kubevirt_vmi_migration_data_bytes_total now. Also note the vCPU recording rule rename from kubevirt_vmi_vcpu_count to vmi:kubevirt_vmi_vcpu:count — both need updating together.

• enhancementAdopt explicit feature gate disabling for tighter cluster governance

  You can now explicitly block feature gates via disabledFeatureGates in the KubeVirt config rather than relying on gates simply being absent. For clusters where you want to enforce that certain alpha/beta features stay off (e.g., in regulated environments), add them to the disabled list. This is particularly useful if you're managing KubeVirt configs via GitOps and want auditable gate enforcement.

Knative v1.21.2 is a small patch release with one TLS improvement and a heads-up that secure-pod-defaults will flip to AllowRootBounded in v1.22.

• breakingAudit root-dependent workloads before v1.22 ships

  The AllowRootBounded secure-pod-defaults setting is coming as the new default in v1.22. If any of your Knative Services run containers that require root (e.g., legacy apps, certain base images), they will break after that upgrade. Right now, while you're on v1.21, test those workloads with AllowRootBounded explicitly enabled. If they fail, set secure-pod-defaults to 'disabled' in your config-features ConfigMap before upgrading to v1.22 — don't wait until upgrade day.

• enhancementConfigurable TLS via knative.dev/pkg/network/tls

  The shift to the shared knative.dev/pkg/network/tls library gives operators more control over TLS settings in Serving. If you manage custom TLS configurations or have internal PKI requirements, review whether this change aligns your TLS behavior with expectations — particularly in environments where cipher suites or minimum TLS versions are enforced by policy.

v2.0.1 is a minor housekeeping release — migrates the runtime-operator Go module to v2, regenerates protos, and cleans up a temporary go.work workaround.

• breakingUpdate import paths if you import the runtime-operator Go module

  The runtime-operator Go module moved to a v2 module path. Any Go code importing it directly must update import paths to include the /v2 suffix. If you're only running wasmCloud as an operator and not importing the module in your own code, no action is needed.

• enhancementUpgrade from v2.0.0 if you hit proto or lint issues

  This patch fixes regenerated protos and removes a temporary go.work shim that may have caused inconsistencies in local development builds. If you were building the operator from source against v2.0.0, pull this patch to avoid stale proto or dependency resolution issues.

wasmCloud v2.0.0 is the stable release of the v2 runtime, bringing HTTP/2+gRPC support, OpenTelemetry metrics, wasmtime 42, and a security fix for RUSTSEC-2026-0007.

• securityPatch RUSTSEC-2026-0007 by upgrading immediately

  The lock file was updated to address RUSTSEC-2026-0007. If you're running any pre-v2.0.0 build, treat this as a mandatory upgrade. Check your supply chain tooling (cargo-audit, Dependabot) to confirm the vulnerable dependency is resolved in your environment.

• breakingHelm users: CRD path changed, update your GitOps pipelines

  CRDs were moved from templates/crds to a top-level /crds directory. This is a structural change that will break ArgoCD, Flux, or any Helm-based GitOps pipeline that references the old path. Before upgrading, verify your Helm release and CI/CD tooling point to the new CRD location.

• enhancementEnable metrics now — observability is first-class in v2

  OpenTelemetry metrics support is included out of the box. If you're already running an OTEL collector, wire up wasmCloud v2 to it and start collecting runtime metrics. This is the right time to establish baseline dashboards before rolling this to production, not after.

Dapr v1.17.2 is a high-priority patch with three Go stdlib CVE fixes, a CRD breaking change requiring manual update, and fixes for cascading actor placement failures and streaming OOM issues.

• securityUpgrade immediately to patch three Go stdlib CVEs

  Go 1.24.x carried GO-2026-4601 (IPv6 SSRF via net/url), GO-2026-4602 (path escape via os.Root), and GO-2026-4603 (XSS via html/template). If your Dapr sidecars handle user-supplied URLs or template rendering in any adjacent service, exposure is real. Upgrade to v1.17.2 now — the fix is a Go toolchain bump, so no code changes are needed on your end.

• breakingManually update CRDs before Helm upgrade or daprd will fail to start

  The `stateRetentionPolicy` fields in the Configuration CRD changed from `type: integer` to `type: string`. Helm does not update CRDs automatically. If you run `helm upgrade` without updating the CRD first, any existing Configuration objects using duration strings will fail Kubernetes validation and daprd may fail to load its config. Run the CRD update step from the Kubernetes upgrade guide before touching Helm. If you're not using workflow state retention policies today, the risk is lower, but update the CRD anyway to stay consistent.

• enhancementLarge actor deployments and streaming workloads should prioritize this patch

  Two fixes deserve immediate attention beyond security. First, deployments with 50+ actor replicas were hitting cascading dissemination timeouts in 1.17.x — the placement service batching fix in this release resolves that. Second, any service invocation path passing large or streaming bodies (file uploads, SSE, chunked data) was silently OOM-killing sidecars by buffering everything in memory. Both are now fixed. If either pattern applies to your workload, treat this upgrade as urgent rather than routine.

Patch release bumping grpc from 1.78.0 to 1.79.3 and updating the Ansible operator plugin. Minimal surface area — safe to adopt quickly.

• securityUpgrade for gRPC dependency fix

  The grpc bump from 1.78.0 to 1.79.3 spans two minor versions and likely includes bug fixes that could affect stability or security of operator-to-registry communication. gRPC CVEs and transport-layer issues have historically been silent but impactful. Review the grpc changelog for your risk profile, then upgrade — this patch is low-risk and the dependency delta is well-contained.

• enhancementAnsible plugin users should rebuild operator images

  If you maintain Ansible-based operators, the plugin update in this release means your scaffolded or generated code may drift from the current baseline. After upgrading the SDK, re-run scaffolding checks or regenerate any plugin-managed files to stay aligned. Not urgent, but worth doing before your next operator release cycle.

KubeVirt v1.7.2 is a patch release fixing 7 bugs across networking, storage, monitoring, and backup — no new features, but several fixes that could unblock production issues.

• breakingCheck VMI specs if you're running mixed NIC configurations

  The infinite status loop fix targets VMIs where the primary network interface appears after a secondary one in the spec. If you have VMs stuck in update churn or virt-controller/virt-handler showing abnormal CPU/log volume, this is likely the cause. Upgrade to v1.7.2 and verify your VMI specs list the primary interface first to avoid re-triggering the issue on older clusters.

• enhancementWindows VM backup users should update for reliable Velero integration

  The QuiesceFailed-to-QuiesceTimeout change plus a 60s pre-backup hook timeout directly addresses flaky Windows VSS snapshot behavior during Velero backups. If you're backing up Windows VMs and seeing intermittent quiesce failures, this patch resolves it. Review your Velero backup policies to ensure the hook timeout aligns with your SLAs.

• enhancementGoogle Cloud NetApp Volumes storage migration is unblocked

  If you're running VMs on GCP with NetApp Volumes and tried live storage migration, it was silently failing. This patch fixes that. Test your migration workflows after upgrading — especially if you deferred any storage moves because of this bug.

KubeVirt v1.6.4 is a patch release with 108 changes targeting stability: a CVE fix in crypto, several hotplug/migration bugs squashed, and new vCPU queue alerting.

• securityPatch CVE-2025-47913 — upgrade to v1.6.4 now

  CVE-2025-47913 affects the golang/x/crypto dependency. This release pins it to OpenShift's patched fork. If you're running any v1.6.x release before v1.6.4, you're exposed. Upgrade immediately — no workaround exists short of patching the binary yourself.

• breakingCross-vendor live migrations are now blocked

  KubeVirt will now explicitly prevent live migrations between nodes with different CPU vendors (e.g., Intel to AMD). If your cluster has mixed CPU vendors and you've been relying on cross-vendor migration — intentionally or not — audit your node topology before upgrading. Migrations that previously succeeded may now fail with an error.

• enhancementAdd vCPU queue alerts to your monitoring setup

  Two new alerts ship in this release: GuestPeakVCPUQueueHighWarning and GuestPeakVCPUQueueHighCritical. If you're running KubeVirt with Prometheus, check that these alerts are picked up by your alerting rules. They give you early warning on guest CPU starvation, which is otherwise invisible until VMs start misbehaving under load.

Dapr 1.17.1 fixes critical runtime issues including WASM component registration failures on production architectures and workflow cleanup problems.

• breakingUpgrade immediately if using WASM components

  WASM binding and middleware components were completely broken on production architectures in v1.16.0-v1.17.0. Applications using these components failed to start. Test your WASM components after upgrading to confirm they register and function correctly.

• enhancementExpect placement service performance improvements

  Large clusters with many non-actor sidecars will see reduced placement overhead. Monitor placement service metrics and actor invocation latency—you should observe fewer lock cycles and improved performance, especially during sidecar restarts.

• enhancementReview workflow cleanup configurations

  Previously stalled workflows that became unstalled can now be properly cleaned up. Verify your state retention policies are working as expected and check for any workflow instances that should have been purged but weren't.

Dapr 1.16.10 fixes critical WASM component registration failures on production architectures and patches security vulnerabilities in Go runtime and OpenTelemetry SDK.

• securityUpdate for Go runtime and OpenTelemetry security patches

  This release patches vulnerabilities in Go 1.25.7 (crypto/tls, go command) and OpenTelemetry SDK (arbitrary code execution via PATH hijacking). Plan your upgrade within your normal security patching window, prioritizing environments where PATH manipulation is possible.

• breakingUpgrade immediately if using WASM components

  WASM binding and middleware components have been completely broken on production architectures since v1.16.0. If you're using these components and running v1.16.0-v1.16.9, upgrade to v1.16.10 immediately as your WASM components are silently failing to register.

• enhancementReview Pulsar Avro message publishing for early error detection

  Pulsar PubSub now validates JSON messages against Avro schemas before publishing, catching malformed data earlier. Test your Pulsar publishing workflows to ensure they handle the new validation errors gracefully and benefit from faster codec performance.