リリース

wasmCloud v2.5.1がリリースされましたが、公開されたノートが短く要約できる内容がありません。詳細は元のリリースノートをご確認ください。

wasmCloud v2.5.0 はフィーチャーリリースです。wasmtime 46 への更新と wasip3 のデフォルト有効化、wasmcloud:keyvalue bucket WIT の破壊的変更、および quinn-proto の MEDIUM セキュリティ修正 (RUST-SEC-2026-0185) が主な変更点です。wasmcloud:keyvalue を利用しているコンポーネントは WIT の対応が必要です。

• securityquinn-proto のセキュリティ修正 (RUST-SEC-2026-0185)

  MEDIUM 深刻度の rust-sec-2026-0185 (quinn-proto) を修正しています。QUIC 通信を利用する環境では v2.5.0 へ更新してください。

• breakingwasmcloud:keyvalue bucket のWIT定義が破壊的変更

  wasmcloud:keyvalue の bucket 型がインターフェースごとのインライン定義から共有 types インターフェース経由の定義に移動しました。wasmcloud:keyvalue WIT を利用するコンポーネントやプロバイダは WIT の修正とリビルドが必要です。

• breakingwasip3 がデフォルト有効化

  wasip3 が v2.5.0 からデフォルトで有効になりました。wasip3 対応外のワークロードで予期しない動作が発生する場合は、設定で明示的に無効化してください。

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

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

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

Volcano v1.14.3 is a routine patch release consisting entirely of backported scheduler bug fixes. No new features, deprecations, or security changes are included.

Operator Framework v1.42.3 was released, but the published notes are too brief to summarize. See the original release notes for details.

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

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

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

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

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

• breakingcrossplane render namespace behavior changed for namespaced XRs

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

Crossplane v2.2.3 patches a TOCTOU vulnerability in package signature verification (GHSA-wfqx-gjrf-g28r) and bumps Go toolchain and dependencies for security fixes.

• securityPatch the TOCTOU signature verification flaw now if you use tag-based installs

  If your team installs Crossplane packages by tag (not digest) from registries you don't fully control, this TOCTOU flaw (GHSA-wfqx-gjrf-g28r) let a malicious registry pass signature verification with one image and then serve a different, unsigned image at install time. Upgrade to v2.2.3 immediately. As a defense-in-depth measure, consider switching package installs to digest references — that would have avoided this issue entirely regardless of the Crossplane version.

• securityGo 1.25.11 and golang.org/x/net v0.55.0 pick up upstream CVE fixes

  The Go toolchain bump and net package update carry security fixes from upstream. There is no separate action beyond upgrading to v2.2.3, but if you scan container images for CVEs, expect findings against older Crossplane images to include these — use v2.2.3 as your baseline for compliance scans.

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

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

wasmCloud 2.4.0 adds autoscaling for WorkloadDeployments, expands architecture support (s390x), and improves the wash CLI and host plugin API. Mostly incremental improvements with some operational benefits.

• enhancementEnable autoscaling for WorkloadDeployments if you manage variable-load services

  wasmCloud 2.4.0 adds autoscaling to WorkloadDeployments. If you currently run static replica counts and workload demand fluctuates (peak hours, batch processing windows, etc.), enable autoscaling to reduce manual scaling and idle cost. Review the autoscaling configuration in your Helm charts or YAML manifests and test thresholds in a staging environment before rolling to production.

• enhancementUpdate wash CLI if you deploy on s390x or other non-x86 systems

  wash now builds for s390x-unknown-linux-gnu. If your infrastructure uses IBM mainframes or other s390x systems, you can now build and run wash natively instead of via emulation or workarounds. Fetch the new binary from the release assets and validate it works with your host setup.

• enhancementReview container health check configuration to rely on NATS connectivity

  Container health checks now use NATS connectivity status rather than a separate probe. This simplifies failure detection: if the container loses NATS connection, it's marked unhealthy faster. Verify your health check thresholds and timeouts still work for your deployment, especially if you have high-latency or congested networks where NATS reconnection may take longer.

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

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

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

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

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

• enhancementNew metrics and alerts for virt components — update dashboards

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

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

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

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

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

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

• enhancementConfig hot-reload now works reliably for workflow sidecars

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

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

• breakingRetry behavior change for pubsub publish errors

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

• enhancementEnforce resiliency policy intent for pubsub

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

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

• breakingFollow specific Helm flags when downgrading to 1.16.16

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

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

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

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

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

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

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

• securityEnable WorkflowAccessPolicy in shared or multi-tenant clusters

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

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

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

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

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

• enhancementEnable workflow history signing for audit-sensitive workloads

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

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

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

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

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

• breakingReview breaking changes in v2.20.0 before upgrading

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

• enhancementRestore ScaledJob scaler startup event visibility

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

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

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

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

• breakingTreat upgrade check findings as real blockers, not warnings

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

• enhancementRun upgrade check before any v2 planning work

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

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

• securityPatch CVE and symlink traversal — upgrade now

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

• breakingRecording rule renames — update dashboards and alerts before upgrading

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

v2.3.0 ships workload env/config/secrets management in wash, wasmtime 45 upgrade with security patches, and improved OTel tracing across workloads and HTTP spans.

• securityApply wasmtime 45 upgrade and dependency security patches immediately

  This release includes two wasmtime bumps: 44.0.2 was a targeted security patch, and 45 followed shortly after. On top of that, additional dependency security advisories were patched separately. If you're running wasmCloud in production, upgrade to v2.3.0 now rather than waiting — the cumulative security surface covered here is non-trivial.

• enhancementScope Kubernetes RBAC to namespaces instead of cluster-wide

  The runtime.wasmcloud.dev apiGroup RBAC can now be namespaced rather than cluster-scoped. If you're running the wasmCloud operator in multi-tenant Kubernetes clusters, revisit your RBAC configuration and tighten it to namespace scope where possible. This is a meaningful security posture improvement for shared clusters.

• enhancementStart using wash workload env/config/secrets for structured configuration

  Configuration and secrets management is now surfaced directly in the wash CLI. This is the workflow shift wasmCloud has been building toward — rather than managing config out-of-band, you can now handle env vars, config, and secrets as first-class workload concerns. Check the new otel-config example in the repo to see the intended pattern before adopting it in production.

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

• securityApply the 3MiB webhook body limit immediately

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

• breakingWebhook requests larger than 3MiB will now be rejected

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

• enhancementUpgrade to stop slow memory and connection accumulation

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

Knative Serving v1.21.3 is a patch release fixing memory leaks, a connection leak in the network prober, and adding a 3MiB webhook request body size limit.

• security3MiB webhook body limit now enforced — test before upgrading

  The webhook request body is now hard-limited to 3MiB. If your workloads send large Knative resource specs (e.g., Services with extensive annotations, large env var blocks, or embedded configs), they could start getting rejected after this upgrade. Audit your largest Knative Service manifests before rolling this out to production. Anything approaching or exceeding 3MiB in a single admission request will fail.

• enhancementPatch memory and connection leaks — upgrade promptly

  Two resource leaks are fixed here: a memory leak in expired matchers and an idle connection leak in the network prober. In long-running clusters with frequent reconciliation or active health-checking, these leaks accumulate. If you've noticed gradual memory growth in the Knative controller or networking components, this patch is the likely fix. No config changes needed — just upgrade.

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

• breakingUpgrade immediately if using Cosmos DB for workflow state

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

• enhancementCheck metrics now to assess blast radius before upgrading

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• breakingUnblock chart upgrades: ConfigMap size issue resolved

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

• breakingScheduler now respects cluster resource limits

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

• enhancementSearch now reflects recovered cluster resources correctly

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

• enhancementCluster readiness now waits for failure threshold

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

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

• breakingFix scheduler resource exhaustion vulnerability

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

• breakingCluster readiness now respects failure threshold

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

• enhancementWatch discovery now reflects recovered cluster resources

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

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

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

• securityAlpine base image updated to 3.23.4

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

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

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

• breakingDeprecated gRPC fields in scheduler-estimator require plugin updates

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

• breakingRemoved flags and metric labels will break existing configs

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

• enhancementCritical scheduler and eviction bug fixes

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

• enhancementEnable SchedulingOvercommitProtection in high-throughput clusters

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

• enhancementOverflow Cluster Affinities for hybrid cloud burst scheduling

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

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

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

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

• breakingUpgrade to fix stuck workflows with reused instance IDs

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

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

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.

wasmCloud v2.2.1 was released, but the published notes are too brief to summarize. See the original release notes for details.