リリース

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 対応外のワークロードで予期しない動作が発生する場合は、設定で明示的に無効化してください。

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.

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

• securityEnable WorkflowAccessPolicy in shared or multi-tenant clusters

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

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

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

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

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

• enhancementEnable workflow history signing for audit-sensitive workloads

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

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

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

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

• breakingReview breaking changes in v2.20.0 before upgrading

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

• enhancementRestore ScaledJob scaler startup event visibility

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

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

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

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

• breakingTreat upgrade check findings as real blockers, not warnings

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

• enhancementRun upgrade check before any v2 planning work

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

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

• securityPatch CVE and symlink traversal — upgrade now

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

• breakingRecording rule renames — update dashboards and alerts before upgrading

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.18.0 adds overflow cluster affinities for hybrid cloud burst scheduling and a scheduling overcommit protection mechanism. Mandatory step: upgrade to v1.17.3+ before applying this release.

• securityAlpine base image updated to 3.23.4

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

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

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

• breakingDeprecated gRPC fields in scheduler-estimator require plugin updates

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

• breakingRemoved flags and metric labels will break existing configs

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

• enhancementCritical scheduler and eviction bug fixes

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

• enhancementEnable SchedulingOvercommitProtection in high-throughput clusters

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

• enhancementOverflow Cluster Affinities for hybrid cloud burst scheduling

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

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

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

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

• breakingUpgrade to fix stuck workflows with reused instance IDs

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

v1.20.8 is a security-only patch for the v1.20 line, bumping Go to 1.25.10 and patching multiple dependency CVEs across go-git, golang.org/x/net, x/crypto, and docker/cli.

• securityUpgrade v1.20 clusters to v1.20.8 now — multiple CVEs addressed

  This patch covers a broad sweep of dependency CVEs: go-git (two separate fixes), golang.org/x/net, golang.org/x/crypto, docker/cli, and in-toto-golang, plus Go stdlib CVEs via the 1.25.10 runtime bump. If you're running any v1.20.x version below this, you're exposed. The go-git and x/crypto vulnerabilities are particularly relevant if your Crossplane setup pulls packages from Git repositories. Plan the upgrade soon — this is not a 'schedule it next sprint' situation.

• enhancementConsider moving to v1.21+ if still on v1.20

  The v1.20 line is receiving security backports, but it won't get feature improvements. If you've been holding on v1.20 for stability reasons, this patch is a good opportunity to audit your upgrade blockers. The v1.21 line has been out long enough to be considered stable, and staying on an older minor version means you'll keep chasing security patches like this one.

v2.1.6 is a security-focused patch for the v2.1 line, bumping Go to 1.25.10 and patching several vulnerable dependencies including go-git, golang.org/x/crypto, and OpenTelemetry.

• securityUpgrade to v2.1.6 immediately if running v2.1.x

  This release patches multiple CVEs across Go stdlib, go-git, x/crypto, and x/net. These aren't theoretical risks — go-git vulnerabilities can affect package fetching behavior, and x/crypto/x/net issues can expose TLS and HTTP handling. If you're on any v2.1.x release, upgrade now. No API or behavioral changes are included, so the upgrade is low-risk.

• securityCheck your provider images for the same vulnerable dependencies

  Crossplane core is patched, but your installed providers (AWS, GCP, Azure, etc.) are separate images with their own dependency trees. Run a container image scan (Trivy, Grype) against your active provider pods to check if they carry the same vulnerable versions of go-git or x/crypto. Provider maintainers will need to release their own patches.

Pure security patch release: Go runtime bumped to 1.25.10 and several dependencies updated to address stdlib CVEs and git-related vulnerabilities.

• securityUpgrade to v2.2.2 immediately if running v2.2.x

  This release is entirely security-driven. Go 1.25.10 patches stdlib CVEs, go-git v5.19.1 addresses git-related vulnerabilities, and x/crypto v0.52.0 closes cryptographic issues. No feature or behavioral changes are included, so the upgrade risk is minimal. If your team scans images or has compliance requirements, staying on v2.2.1 or earlier will trigger findings — update now.

• securityCheck scanner results against the new image digest

  The go-git library was patched twice in quick succession, which suggests active exploitation pressure on that attack surface. After upgrading, re-run your vulnerability scanner against the new Crossplane image digest to confirm all findings are cleared. Pay particular attention to any CVEs tagged against git operations or supply-chain tooling, since in-toto-golang was also updated.

Crossplane v2.3.0 ships a high-fidelity local render engine, per-resource reconciliation control, alpha Provider deletion protection, and multiple security dependency bumps including Go stdlib CVE fixes.

• securityGo stdlib CVEs fixed — pull the new image

  Go was bumped to 1.25.10 specifically to address stdlib CVEs, on top of several other dependency security patches (grpc, go-git, go-jose, cloudflare/circl, golang.org/x/net). Update your Crossplane deployment to v2.3.0 promptly; if you mirror images internally, make sure the new digest is pulled before rolling out.

• breakingUpdate API import paths and bookmark the new CLI repo

  If you import Crossplane APIs in Go code, change `github.com/crossplane/crossplane/v2/apis` to `github.com/crossplane/crossplane/apis/v2` and note that `v1.Resource*` types are now `v2.ClusterManagedResource*`. Pin your CLI tooling to the new `github.com/crossplane/cli` repo — version numbers will diverge from core after this release, so update any scripts or CI pipelines that assumed aligned versioning.

• breakingUpgrade sequentially from v2.2 — do not skip minor versions

  Crossplane migrates CRDs on upgrade, and skipping minor versions can leave the API server in an inconsistent state. If you are on v1.20, that branch receives extended support but you should plan your migration to v2.x. Always follow the sequential upgrade path documented in the Crossplane upgrade guide.

• enhancementUse per-resource poll annotations to reduce API server load

  Set `crossplane.io/poll-interval: 24h` on stable, infrequently-changing XRs to dramatically cut reconcile frequency. Pair it with `crossplane.io/reconcile-requested-at` to trigger on-demand reconciliation when needed. This is available immediately for XRs; for managed resources, wait for your providers to release versions based on crossplane-runtime v2.3.0 before relying on it.

• enhancementEnable Provider deletion protection in non-prod first

  The new `--enable-provider-deletion-protection` alpha flag auto-creates `ClusterUsage` resources that block Provider deletion while managed resources exist. Useful safety net in shared clusters. Enable it in staging environments first to validate that your existing `ClusterUsage` webhook setup handles the auto-created resources correctly before rolling to production.

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.

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.

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.