Releases

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.

Knative v1.22.0 completes the EndpointSlices migration, consolidates TLS configuration across all components, and adds new autoscaling observability metrics.

• enhancementScrape the new queue/active request metrics for autoscaling tuning

  kn.revision.request.queued and kn.revision.request.active are now available from queue-proxy. If you're tuning concurrency targets or debugging cold-start behavior, add these to your Prometheus scrape config and dashboards. They give you direct visibility into the queue depth per revision, which was previously only inferable from aggregate metrics.

• enhancementVerify RBAC if running with minimal cluster permissions

  The ClusterRole now includes endpointslices/restricted permissions to support the EndpointSlices migration. If your cluster uses OPA, Kyverno, or any policy engine that audits ClusterRole changes, review and approve the updated role during upgrade. Missing this permission would break autoscaler stat forwarding.

• enhancementGraceful WebSocket shutdown reduces in-flight request drops during scale-down

  The queue-proxy now shuts down WebSocket connections gracefully. If your services handle WebSocket traffic, this directly reduces dropped connections during rolling updates or scale-to-zero events. No configuration change needed — the improvement is automatic on upgrade.

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.

Crossplane v1.20.7 was released, but the published notes are too brief to summarize. See the original release notes for details.

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.

v2.1.5 patches three behavioral bugs (ImageConfig upgrades, ResourceSelector matching, circuit breaker resets) and pulls in a broad sweep of security dependency updates including Go 1.25.9.

• securityUpgrade to v2.1.5 promptly — this release addresses multiple CVEs in core dependencies

  The dependency list here is long: grpc, go-git (patched twice), go-jose, cloudflare/circl, moby/spdystream, docker/cli, and the OTel OTLP trace exporter all received security updates, plus Go itself was bumped to 1.25.9. Any of these could carry CVEs relevant to your threat model. This isn't a routine chore bump — prioritize this upgrade over staying on v2.1.4.

• breakingCheck for silently stale packages if you use ImageConfig prefix rewrites

  If your environment uses ImageConfig to rewrite registry prefixes, dependent packages may have been silently pinned at outdated versions since the bug was introduced. After upgrading to v2.1.5, verify that your package dependency graph resolves to the expected versions — stale packages won't auto-upgrade retroactively, so you may need to trigger a reinstall or version bump manually.

• enhancementResourceSelector 'select all of a kind' unlocks cleaner composition function patterns

  If you've been working around the previous rejection of bare apiVersion/kind selectors — adding dummy matchLabels or splitting logic — you can now clean that up. A selector with no match fields is treated as 'give me all resources of this kind,' which is the intuitive behavior. Review your composition functions for any workarounds and simplify them after upgrading.

v2.0.8 fixes two user-reported bugs (ImageConfig prefix rewrite upgrades, ResourceSelector with no match field) and patches multiple security vulnerabilities in upstream dependencies.

• securityUpgrade to v2.0.8 immediately for dependency security patches

  Multiple upstream dependencies received security-tagged fixes in this release — go-git (two separate bumps to v5.17.1 then v5.18.0), go-jose, cloudflare/circl, and others. These aren't just routine bumps; they carry CVE-related fixes. If you're running any v2.0.x release prior to v2.0.8, upgrade now. There are no API changes, so the upgrade path is straightforward.

• breakingAudit packages installed via ImageConfig prefix rewrites for stale dependencies

  If your environment uses ImageConfig prefix rewrites to redirect package pulls (e.g., to a private registry), dependent packages may have been silently stuck on outdated versions since you adopted that configuration. After upgrading to v2.0.8, force a reconciliation and verify that all package dependencies are on their expected versions — don't assume the upgrade alone will catch everything already in a stuck state.

• enhancementUse bare ResourceSelector (apiVersion+kind only) for 'select all' semantics in composition functions

  Previously, omitting matchName and matchLabels from a ResourceSelector caused Crossplane to reject the request outright. That's now fixed — a bare selector correctly means 'all resources of this kind'. If you worked around this limitation by enumerating resources explicitly or adding dummy match conditions, clean up those workarounds after upgrading.

v1.20.6 is a security-focused patch release fixing multiple dependency CVEs and hardening CI workflows against script injection attacks.

• securityUpgrade to v1.20.6 immediately — multiple dependency CVEs patched

  Five separate security dependency updates landed in this release, covering cryptography (circl), git operations (go-git), HTTP/2 streaming (spdystream), and telemetry export (otelhttp). Any Crossplane v1.20.x deployment is exposed until upgraded. This isn't a theoretical risk — go-git had two separate security fixes within this single patch release, which signals active exploitation concern. Run your upgrade now.

• securityCI/CD supply chain hardening — audit your own pipelines

  The Crossplane team mitigated script injection in their release promotion workflow and tightened GitHub Actions job permissions. If you're running Crossplane forks, mirrors, or custom automation that builds on top of Crossplane's CI patterns, audit your own workflows for similar issues: untrusted input in run steps and overly broad GITHUB_TOKEN permissions are the two patterns to check.

• enhancementTrivy scanning dropped from CI — don't let it drop from yours

  Crossplane dropped Trivy from their CI pipeline in this release. This is an internal CI decision, but if your team was relying on Crossplane's upstream scan results as a proxy for your own security posture, that signal is now gone. Make sure you have independent vulnerability scanning on your Crossplane images and provider images in your own pipelines.

Critical security patch fixing ACL bypass via path traversal in service invocation — any deployment using access control policies must upgrade immediately.

• securityUpgrade immediately if you use service invocation ACLs

  This is a real ACL bypass, not a theoretical one. If your Dapr deployment uses access control policies for service invocation and the Dapr API is reachable by untrusted callers — even internal ones — you are vulnerable. The gRPC vector is especially dangerous since it passes method strings raw with no sanitization. Upgrade to v1.15.14 now. There is no workaround short of disabling service invocation or isolating the Dapr API entirely.

• securityAudit who can reach your Dapr API endpoints

  This vulnerability required API access, so the blast radius depends entirely on your network posture. After upgrading, take the opportunity to review which workloads and network paths can reach the Dapr HTTP and gRPC APIs. Sidecar-only access (localhost) is the safest posture — if you're exposing Dapr APIs more broadly, tighten that regardless of this fix.

• breakingVerify your service invocation method paths still route correctly after normalization

  The fix applies path.Clean normalization to all method paths and rejects any containing #, ?, null bytes, or control characters. If any of your services legitimately use encoded slashes (%2F) as path separators in method names — particularly over gRPC where these were previously passed through raw — those calls will now behave differently. Test your service-to-service invocation patterns before rolling this to production.

v1.17.5 is a security-only patch fixing a path traversal vulnerability that allowed attackers to bypass service invocation ACL policies via encoded URL characters.

• securityUpgrade immediately if you use service invocation ACLs

  Any deployment with access control policies for service invocation is vulnerable. An attacker with Dapr API access (HTTP or gRPC) could reach denied endpoints by encoding the path. gRPC is especially risky since method strings were passed raw. Upgrade to v1.17.5 now — there is no workaround short of removing Dapr API exposure entirely. After upgrading, audit your ACL policies to confirm expected paths are actually being enforced.

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix adds strict validation: method paths containing #, ?, null bytes, or control characters are now rejected at the invocation edge. If any of your services use these characters in method paths (uncommon but possible with gRPC), those calls will fail after upgrade. Test your service invocation paths in a staging environment before rolling this to production.

Critical security fix: path traversal and encoded characters in service invocation method paths could bypass ACL policies entirely. Upgrade immediately if you use access control policies.

• securityUpgrade immediately if you use Dapr ACL policies

  Any deployment with service invocation access control policies is vulnerable. An attacker with access to the Dapr HTTP or gRPC API can craft method paths that the ACL permits but route to denied endpoints. The gRPC vector is especially dangerous since no client-side sanitization occurs. Upgrade to v1.16.14 now — there is no viable workaround short of removing Dapr API access entirely. After upgrading, audit your ACL policy rules to confirm they match the normalized path forms (resolved ../ and no encoded separators).

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix actively rejects method paths containing fragment (#), query (?), null bytes, or control characters rather than silently normalizing them. If any of your services invoke methods with these characters (unlikely but possible via programmatic gRPC calls), those calls will fail after upgrading. Review your service invocation call sites — especially any that construct method paths dynamically — before rolling this out to production.

Dapr v1.16.13 fixes a critical scheduler reliability bug affecting multi-replica deployments, patches a silent Pulsar misconfiguration that could cause OOM crashes, and rebuilds with Go 1.25.9 for security fixes.

• securityUpgrade immediately for Go 1.25.9 security patches

  This build patches vulnerabilities in Go's crypto/x509, crypto/tls, archive/tar, and html/template packages. Any Dapr deployment still on 1.16.12 or earlier is exposed. Upgrade to 1.16.13 now — there's no workaround short of rebuilding from source with Go 1.25.9 yourself.

• breakingPulsar users: processMode will now actually take effect — verify your config

  If you have processMode set in your Pulsar component YAML, it was silently ignored before this release. After upgrading, that config will be enforced. If you set processMode: sync expecting ordered processing but were actually running async, behavior changes on upgrade. Review your Pulsar component metadata and subscription behavior before rolling this out to production. Also check maxConcurrentHandlers: if it was set to 0, it previously caused a deadlock; now it falls back to 100.

• breakingMulti-replica scheduler deployments: patch this immediately

  The scheduler bug is severe in practice. A routine pod restart — due to a rolling update, OOM kill, or node eviction — would silently stop all job triggers across your deployment until some unrelated cluster event re-established connections. There's no alerting or visible failure; jobs just stop firing. If you run multiple scheduler replicas (standard HA setup), this fix is critical. Upgrade and verify your scheduled jobs are firing after any scheduler pod restart.

v2.0.3 patches a NATS race condition, adds Kubernetes EndpointSlice support, hardens container security with non-root ownership, and expands Helm chart configurability.

• securityUpgrade now: containers finally run as non-root by default

  Previous releases ran with root ownership, which is a container security red flag. This release sets non-root ownership by default. If you have volume mounts or init containers with root-dependent file permissions, test before rolling to production — you may need to adjust fsGroup or runAsUser settings in your pod specs.

• breakingHelm chart image tag behavior changed — audit your values files

  The default image tag no longer falls back to a hardcoded value; it now uses the chart's appVersion. If you rely on overriding the tag in your values files, this likely works as-is. But if you were depending on the old default tag behavior for pinning, verify your deployed image versions after upgrading the chart.

• enhancementEnable EndpointSlice support if running Kubernetes 1.21+

  EndpointSlice is the modern replacement for Endpoints and scales better with large service backends. If your cluster runs Kubernetes 1.21 or later, enable this feature — it reduces load on kube-apiserver and avoids the scaling limits of the classic Endpoints API. Check your Helm values for the new endpointslice configuration option.

Dapr 1.17.4 patches seven bugs spanning workflow correctness, Pulsar OOM risk, actor freeze under placement pressure, and a Go stdlib security update. Deploy promptly if you use any of these features.

• securityUpgrade immediately for Go stdlib CVE fixes

  Go 1.25.9 patches vulnerabilities in archive/tar, crypto/tls, crypto/x509, html/template, and the compiler. All Dapr binaries and Docker images are rebuilt with the patched toolchain. Update your Dapr runtime to 1.17.4 now — no config changes needed, just the version bump.

• breakingPulsar processMode behavior has changed — validate your component config

  If you set processMode in Pulsar component YAML before this fix, it was silently ignored and you were running in default mode. After upgrading, the setting takes effect. If you had processMode: sync expecting ordered processing but were unknowingly running async, behavior will change. Also, async mode now caps concurrency at maxConcurrentHandlers (default 100). Review your Pulsar component metadata and test throughput behavior before rolling to production.

• enhancementEliminate actor/workflow freeze risk from placement slowness

  The placement dissemination freeze bug could cause cascading health check failures during rolling updates — Kubernetes would declare pods unhealthy and restart them, worsening the cycle. With 1.17.4, a slow peer triggers reconnect rather than a fatal teardown. If you've seen unexplained actor hangs or zombie daprd processes during rollouts, this is likely the cause. No configuration change needed; upgrading is sufficient.

v2.0.2 is a focused patch: wasmtime runtime bumped to v43, a new Kubernetes Host pod reconciler added, and install scripts smoothed out.

• enhancementUpdate to pick up wasmtime 43 runtime improvements

  Wasmtime 43 includes upstream bug fixes and performance work. If you're running v2.0.1 in production, this is a low-risk upgrade worth taking. No API changes expected on the wasmCloud side — just redeploy your hosts.

• enhancementKubernetes operators: test the new Host pod reconciler

  The Host pod reconciler adds smarter lifecycle handling for wasmCloud hosts running as Kubernetes pods. If you're using the wasmCloud operator, deploy this in a staging cluster first and validate that host pod restarts and scheduling behave as expected before rolling to production.

• enhancementWindows users can now install wash via winget

  wash is now in the winget package registry. Windows-based teams can standardize installs with 'winget install wash' instead of manual binary downloads — useful for onboarding and CI pipelines on Windows runners.

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.