リリース

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

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

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

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

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

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

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

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

• securityCertificate rotation was silently broken — rotate certificates after upgrading

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

• breakingEviction race condition could leave workloads stranded on failing clusters

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

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

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

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

• securityAudit agent certificates for expiry before upgrading

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

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

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

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

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

v2.17.0 ships a security fix for XSS in the UI, two major UI features (side panel span details, trace log aggregation), and several backend stability fixes including a panic guard and clock skew correction.

• securityUpdate UI immediately to fix XSS vulnerability

  The UI was rendering user-supplied trace data using innerHTML, which opens the door to XSS if trace attribute values contain malicious HTML. This is fixed by switching to textContent. If you expose Jaeger UI to users who can influence span data (e.g., shared environments, multi-tenant setups), treat this as a priority upgrade. Pull the v2.17.0 image and redeploy.

• breakingClock skew fix changes span end timestamps — verify your trace data expectations

  The clock skew adjuster previously only corrected span start times, leaving end timestamps unadjusted. Now both are corrected. For teams with strict SLO calculations or latency assertions based on adjusted trace data, this behavioral change could shift computed durations. Validate your dashboards and alerting rules against real traces after upgrading.

• enhancementSide panel span view reduces trace analysis friction

  Span details previously expanded inline, collapsing the trace timeline context. The new side panel mode keeps the timeline visible while inspecting a span. Useful immediately for deep trace debugging — no configuration needed, just click a span in the UI. Worth showing to your team as a workflow improvement.

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

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

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

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

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

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

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

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

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

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

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

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

• enhancementGPU resource fix prevents ghost allocations on GPU nodes

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

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

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

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

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

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

v1.20.1 is a targeted patch fixing an OpenShift upgrade blocker, a Gateway API duplicate parentRef bug, and a scanner-flagged gRPC dependency bump.

• securitygRPC bump is cosmetic — but clear your scanner alerts

  The gRPC dependency was bumped purely to satisfy vulnerability scanners. The reported CVE does not affect cert-manager's code paths. No runtime risk, but if your supply chain tooling (Trivy, Grype, etc.) was flagging v1.20.0, this update will resolve those alerts. Good reason to upgrade, but no urgency beyond scanner hygiene.

• breakingOpenShift users: upgrade to v1.20.1, skip v1.20.0

  v1.20.0 introduced a regression where the order controller lacked the necessary finalizer RBAC, breaking upgrades on OpenShift due to stricter RBAC enforcement. If you're on OpenShift and held back from v1.20.0, go straight to v1.20.1. If you somehow applied v1.20.0, verify that the ClusterRole for the order controller now includes the issuer finalizer permissions after upgrading.

• enhancementGateway API users: fix parentRef duplication before it causes routing issues

  If you're using Gateway API integration with cert-manager and specify parent references in both the issuer config and via annotations, v1.20.0 would generate duplicate parentRef entries. This can cause unpredictable behavior depending on your gateway implementation. Upgrading to v1.20.1 resolves this — review any existing certificates using both mechanisms to confirm they're clean post-upgrade.

Argo CD v3.3.6 is a focused bug-fix patch addressing a false-positive diff detection during app normalization and a wrong installation ID returned from cache.

• breakingCheck for ghost sync loops before upgrading

  If your ArgoCD controller has been triggering unexpected syncs or showing phantom diffs on apps that haven't changed, this patch fixes that normalization bug. Upgrade to 3.3.6 promptly if you're seeing this — it's a common source of noisy alerts and wasted reconciliation cycles.

• enhancementRoutine patch — safe to apply quickly

  This is a two-bug patch with no schema changes, no API changes, and no migration steps. If you're already on 3.3.x, roll this out through your normal process. No special precautions needed.

Emissary v4.0.1 is the true first release of Emissary 4, built on distroless images and stock Envoy 1.36.2, with five breaking changes that require immediate attention before upgrading.

• securityApply this release for CVE fixes in dependencies and Python

  Multiple dependency updates and a Python interpreter upgrade were included specifically to resolve CVEs. The release notes don't enumerate the CVEs, so check the CHANGELOG for specifics. If you're running any prior Emissary version, upgrading to 4.0.1 is the right move for the security fixes alone — just plan for the breaking changes in the same window.

• breakingAudit all five breaking changes before upgrading

  This is a major version jump with five distinct breaking changes. Before upgrading: (1) Update your Helm repo URL to GHCR and pin chart version to 4.0.1. (2) If you use v1 or v2 CRDs, explicitly set enableLegacyVersions: true in your values file. (3) Remove any --metrics-endpoint flags from your diagd configuration. (4) Migrate banner endpoint config to the AMBASSADOR_DIAGD_BANNER_ENDPOINT env var. (5) Verify you have no dependency on Edge Stack's custom error responses or header-case features — pure Emissary users should be unaffected, but double-check.

• enhancementUse the new multiarch images for ARM64 clusters

  Emissary 4 ships multiarch Docker images covering both amd64 and arm64. If you run mixed-arch or ARM-only clusters (common with Graviton or Ampere nodes), you can now deploy Emissary without custom builds or workarounds. The image pull just works — no node affinity hacks needed.

OPA v1.15.0 adds a pluggable logging system with file rotation, breaks custom HTTPAuthPlugin implementations, and extends AWS signing to support web identity credentials.

• breakingAudit and fix custom HTTPAuthPlugin implementations before upgrading

  If you've built a custom HTTPAuthPlugin, NewClient() is now called once per Client instance, not per request. Any per-request logic (counters, transport wrapping, logging side effects) sitting in NewClient() will now execute exactly once and silently produce wrong behavior. Before upgrading, audit your plugin and move all per-request logic to Prepare(). OPA's own built-in plugins are already updated, so this only affects teams with custom plugins.

• enhancementAdopt the file logger plugin to consolidate OPA log management

  The new file_logger plugin writes structured JSON logs with automatic rotation, covering both runtime and decision logs through a single configuration block under server.logger_plugin. If you're currently tailing OPA stdout or piping to an external log shipper, switching to the file logger reduces operational complexity and gives you rotation out of the box. Decision log plugin output via the same logger plugin is a clean alternative to the HTTP bundle endpoint for low-latency environments.

• enhancementEnable web identity credentials for AWS-backed OPA deployments on EKS

  OPA running on EKS with IRSA (IAM Roles for Service Accounts) can now use Web Identity tokens directly for Assume Role credential flows in AWS Signing. If you've been working around this with instance profile credentials or manual token injection, you can now configure this natively. Update your REST plugin AWS signing config to use the web identity provider and align with standard EKS IAM patterns.

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

• securityUpgrade immediately for two active CVEs

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

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

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

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

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

gRPC v1.80.0 delivers TLS private key offloading, EventEngine enabled by default in Python, and a raft of Python async/AIO bug fixes that affect production stability.

• securityPrivate key material no longer needs to live in process memory

  The private key offload feature means TLS signing can be delegated externally. For teams running in regulated environments, upgrade to v1.80.0 and migrate to the offload-backed credential provider to eliminate the attack surface of in-process key storage. This applies to both the Python signer implementation and the core C++ offload path.

• breakingEventEngine is now the default I/O backend in Python — test before upgrading

  EventEngine replacing the legacy polling engine by default changes how gRPC Python handles I/O, threading, and fork behavior. A fork-support env var default was reverted (PR #41769) in this same release, signaling the area is still stabilizing. Run your existing Python gRPC workloads in a staging environment before promoting to production, and pay attention to any fork-based server patterns (e.g., gunicorn pre-fork).

• enhancementAdopt Private Key Offload for secrets-safe TLS

  The new TLS Private Key Offload implementation and InMemoryCertificateProvider let you keep private keys in an HSM or KMS and rotate certs at runtime. If you run gRPC servers with compliance or secrets-management requirements, this is the right upgrade path. Wire up the new signer interface and drop file-based credential loading where you can.

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

• securityGo 1.25.8 security patches — rebuild or upgrade

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

• breakingUpgrade immediately if running Scheduler in HA mode

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

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

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

A targeted patch release fixing a gRPC CVE, a false-diff bug in app normalization, and a UI glitch in RollingSync — upgrade promptly for the security fix alone.

• securityPatch CVE-2026-33186 by upgrading to v3.2.8 now

  The grpc-go CVE-2026-33186 fix is the primary reason to move quickly on this release. If you're running any 3.2.x version, upgrade to 3.2.8. Verify your container images using cosign against the published provenance — the Argo CD docs cover the exact verification steps. Don't wait on this one.

• breakingCheck for spurious sync operations before and after upgrade

  The normalization diff bug could have been silently triggering syncs on apps that were actually in-sync. After upgrading, review your sync history for apps that synced frequently without visible config changes — those were likely false positives. The fix should stop them, but any automation or alerts built around sync frequency may need recalibration.

• enhancementRollingSync UI fix improves progressive delivery visibility

  If you use ApplicationSets with RollingSync and have ever wondered why a step appeared blank or unclear in the UI, this fix addresses that. No action needed beyond upgrading, but it's worth re-examining your RollingSync step configurations in the UI post-upgrade to confirm everything displays as expected.

Argo CD v3.3.5 is a patch release fixing a stack overflow bug, hook ordering issues, and UI improvements — low risk, high value to upgrade.

• breakingCircular ownerRef crash is now fixed — upgrade if you hit mysterious crashes

  If your cluster has resources with circular ownership references (common in some operators or misconfigured CRDs), Argo CD could stack overflow and crash during graph processing. This is now fixed. If you've seen unexplained application-controller crashes, this is almost certainly the cause. Patch immediately.

• breakingPostSync hooks silently skipped when PreDelete/PostDelete hooks coexist — fixed

  Workflows relying on PostSync hooks for notifications, cleanup, or validation were silently broken if the same app also defined PreDelete or PostDelete hooks. Verify your hook-based pipelines after upgrading to confirm they now execute correctly.

• enhancementgrpc dependency bumped to 1.79.3

  The grpc library was bumped from 1.77.0 to 1.79.3. This picks up several upstream fixes. No action required beyond upgrading, but if you run Argo CD in a security-sensitive environment, review the grpc changelog for any CVEs addressed in that range.

Chaos Mesh v2.8.2 is a security-focused patch that resolves CVEs across Go and UI dependencies, drops install.sh, and fixes cert-manager webhook conflicts.

• securityUpgrade now — this release exists specifically to fix CVEs

  Both Go and UI packages were upgraded in bulk to address vulnerabilities tracked in issue #4830. No specific CVE IDs are listed in the release notes, but the scope (all direct dependencies) suggests broad exposure. If you're running v2.8.1 or earlier, treat this as an urgent upgrade, especially for clusters where Chaos Mesh's dashboard is internet-accessible or exposed internally to untrusted users.

• breakingStop using install.sh — it's been deleted, not just deprecated

  install.sh is physically removed in this release. Any CI/CD pipelines, runbooks, or onboarding docs that reference it will break immediately. Migrate to the Helm chart or the official quick-start guide before upgrading. Check your automation scripts and internal documentation now.

• enhancementFix cert-manager server-side apply conflicts before they hit you in prod

  If you use cert-manager to manage Chaos Mesh's webhook certificates, the caBundle placeholder in webhook templates was causing server-side apply (SSA) field ownership conflicts — a subtle issue that silently breaks reconciliation. After upgrading to v2.8.2, re-apply your Helm release or manifests to let SSA recalculate field ownership cleanly. If you've been seeing unexpected webhook certificate errors or Helm diff noise, this is likely the cause.

Rook v1.19.3 delivers targeted fixes and additions across CSI, pool management, OSD operations, and RGW — with a notable shift to ceph-csi-operator for CSI deployments.

• breakingCSI now deploys via ceph-csi-operator — verify your deployment model

  The shift to ceph-csi-operator for deploying Ceph-CSI/NVMe-oF changes how CSI components are managed. If you have customized CSI sidecar configurations or rely on specific deployment behavior, audit your setup before upgrading. The ceph-csi-operator introduces its own CRDs and reconciliation loop, so any direct overrides you've applied to CSI DaemonSets or Deployments may be overwritten or ignored post-upgrade.

• enhancementEncrypted OSD users: apply the lockbox key rotation fix now

  The lockbox key rotation bug for encrypted OSDs could leave your cluster in an inconsistent encryption state over time. If you're running encrypted OSDs, upgrade to v1.19.3 and verify key rotation is functioning correctly afterward. This is especially relevant if you've observed any anomalies during OSD replacement or key rotation workflows.

• enhancementRGW on IPv6? The secret formatting fix is a must

  The incorrect IPv6 formatting in object store user secrets would cause connection failures in IPv6-only or dual-stack environments. If your RGW deployment uses IPv6 addressing, this fix directly unblocks proper user secret generation. After upgrading, recreate or reconcile affected object store users to pick up correctly formatted secrets.

Rook v1.18.10 patches several OSD reliability issues, tightens RBAC permissions, and adds minor operational improvements to the Ceph exporter and NFS server.

• securityAudit your Rook RBAC after upgrading — nodes/proxy grant is gone

  The operator's nodes/proxy RBAC permission has been removed. If any custom tooling or monitoring in your environment relied on Rook's ServiceAccount having that grant, it will break silently after upgrade. Review any pipelines or dashboards that use the Rook operator ServiceAccount before rolling this out to production.

• breakingEncrypted OSD users should test key rotation after upgrading

  The lockbox key rotation logic for encrypted OSDs was updated. Encrypted OSD clusters should run a non-production upgrade first and explicitly verify key rotation still works end-to-end. The CephX key init fix (no overwrite on failure) also changes behavior during error recovery — test any failure/retry scenarios you have documented.

• enhancementUse the new CephNFS image fields to pin or customize NFS server images

  The new spec.server.image and spec.server.imagePullPolicy fields let you specify a custom NFS Ganesha image per CephNFS resource. This is useful if you need to pin a specific version for compliance or test a patched image without waiting for a Rook release. Update your CephNFS manifests if you currently work around this with other hacks.

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

• breakingRemove SLIRP and Macvtap network bindings before upgrading

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

• breakingUpdate migration metrics in dashboards before upgrading

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

• enhancementAdopt explicit feature gate disabling for tighter cluster governance

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

v2.12.6 is a critical security release fixing 11 CVEs across MQTT, JetStream, WebSockets, leafnodes, and mTLS. Also fixes a JetStream regression from 2.12.5 that could lose consumer assignments.

• securityUpgrade immediately — 11 CVEs patched across core subsystems

  This release patches CVEs in MQTT (3), JetStream (2), leafnodes (2), WebSockets (1), mutual TLS (1), command-line credentials (1), and publish permissions (1). If you run any of these features in production, there is no safe reason to stay on an older build. Review your deployment against the affected subsystems and prioritize accordingly — MQTT and leafnode users face the highest exposure count.

• breaking1MB JWT size limit is now enforced

  JWTs larger than 1MB will be rejected. This is unlikely to affect most deployments, but if you use deeply nested or unusually large account/user JWTs (e.g., with large permission sets), validate your JWT sizes before upgrading. Check your operator's JWTs and any dynamically issued credentials.

• breakingJetStream consumer assignments could be silently lost on 2.12.5 — fix requires upgrade

  A regression in 2.12.5 caused stream updates on clustered JetStream with async snapshots to drop consumer assignments. If you're running 2.12.5 with clustered JetStream, audit your consumer counts before and after upgrading to confirm no silent data loss occurred. This is the most operationally dangerous bug in this release cycle.

v2.11.15 is a critical security release patching 11 CVEs across MQTT, leafnodes, WebSockets, JetStream, and mTLS. Upgrade immediately if you run any of these features.

• securityUpgrade now — 11 CVEs, multiple remote attack surfaces

  This release patches CVEs across nearly every major NATS feature area. MQTT users face the most exposure: password leakage in monitoring endpoints, session hijacking via mismatched client IDs, and malformed packet panics. WebSocket deployments had an unbounded memory allocation path exploitable for DoS. Leafnode and mTLS users also have targeted fixes. There is no safe reason to delay this upgrade. Pin your deployments to v2.11.15 and roll it out across all clusters — dev, staging, and production.

• breakingMQTT client ID restrictions may break existing clients

  NATS special characters (`.`, `>`, `*`, spaces, tabs) are now rejected in MQTT client IDs. If any of your MQTT clients use these characters — common in some IoT device naming schemes — they will fail to connect after upgrade. Audit your MQTT client ID naming conventions before rolling out this version in production. Also verify that your MQTT clients do not rely on the previously broader implicit permission scope, which is now restricted to `$MQTT.sub.*` and `$MQTT.deliver.pubrel.*` prefixes.

• enhancementTrace logging and monitoring endpoints now redact secrets

  Command-line secrets were previously visible in expvar monitoring output and trace logs. This is fixed. If you've been scraping the monitoring port or collecting trace logs and routing them to external systems (log aggregators, SIEM, etc.), check whether any historical data needs to be rotated or scrubbed. Going forward, no additional config is needed — redaction is automatic.

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

• breakingAudit root-dependent workloads before v1.22 ships

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

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

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

Contour v1.33.3 is a security-focused patch bumping Envoy to v1.35.9 and grpc-go to v1.79.3, with a minor cleanup to example manifests.

• securityUpgrade to get the Envoy security fixes

  The Envoy bump to v1.35.9 is the main reason to upgrade — it addresses real security vulnerabilities in the data plane. The grpc-go CVE-2026-33186 does not affect Contour, but the Envoy issues are reason enough to prioritize this patch. Plan a rollout soon, especially if your clusters are exposed to untrusted traffic.

• breakingCheck custom manifests for the removed hostPort: 8002

  If you copied or extended the example manifests and rely on hostPort: 8002 for scraping Envoy metrics directly from the node, that configuration is now gone from the upstream examples. Audit your manifests before upgrading to confirm whether you've inherited this setting and whether any monitoring pipelines depend on it.

Contour v1.32.4 is a security/stability patch bumping Envoy to v1.34.13 and grpc-go to v1.79.3 (CVE-2026-33186), with a minor manifest cleanup.

• securityUpgrade for the Envoy security fixes

  The Envoy bump to v1.34.13 is the real reason to update here. Envoy releases in this range carry security fixes — check the Envoy v1.34.13 changelog directly to understand which CVEs apply to your traffic patterns. The grpc-go CVE-2026-33186 does not affect Contour, but upgrading still gets you the fix in the dependency graph. Plan a rolling upgrade now rather than waiting.

• breakingCheck custom manifests that reference Envoy hostPort 8002

  The example manifests removed hostPort 8002 from the Envoy metrics container. If your deployment pipelines diff against or are derived from the upstream example manifests, this change will appear as a diff. More importantly, if you have firewall rules, monitoring scrapers, or Prometheus scrape configs targeting that host port directly, verify they still reach the metrics endpoint through an alternative path (e.g., ClusterIP Service or pod IP) before upgrading.

Contour v1.31.5 is a security/stability patch: Envoy bumped to v1.34.13, grpc-go updated to patch CVE-2026-33186 (Contour itself unaffected), and a minor manifest cleanup.

• securityUpgrade for Envoy security fixes — don't wait on this one

  Envoy v1.34.13 carries security vulnerability fixes. The release notes don't enumerate specific CVEs, but Envoy patches at the .13 point release level are serious. Upgrade Contour to pull in the new Envoy image. If you run a heavily customized Envoy config, verify behavior in staging first, but don't sit on this.

• securityCVE-2026-33186 in grpc-go: patched, Contour not affected — no emergency action needed

  The grpc-go update closes CVE-2026-33186, but Contour's own code doesn't hit the vulnerable path. You still benefit from upgrading since the dependency is bundled in the Contour binary. No emergency rollout required, but include this in your next maintenance window.

• breakingCheck custom manifests if you rely on Envoy metrics hostPort 8002

  The example manifests no longer expose hostPort: 8002 for Envoy metrics. If you copy or base your deployment manifests on Contour's examples and depend on host-level metrics scraping via that port, update your scrape configs and manifests accordingly. Production installs using the operator or Helm are unlikely to be affected unless you explicitly templated this.

OpenFGA v1.13.0 ships AuthZen v1.0 support, separates Check v1/v2 caches, and hardens the resolver pipeline against panics.

• securityUpgrade to stop resolver panics from taking down the server

  Unhandled panics in the pipeline base resolver previously had the potential to crash the OpenFGA process entirely. The fix converts these to returned errors, keeping the server running. If you've seen unexpected OpenFGA restarts under complex authorization graph evaluations, this is likely why. Upgrade promptly — this is a reliability fix with meaningful availability implications.

• breakingSeparate Check v1/v2 caches may change cache hit behavior — review your cache sizing

  Previously, Check v1 and v2 shared a single cache, which could lead to cross-contamination but also inadvertent cache hits. Now they're isolated. If you're running both API versions concurrently, your effective cache hit rate may drop and memory usage could shift. Revisit your cache capacity configuration after upgrading and monitor cache hit ratios in your observability stack.

• enhancementEvaluate AuthZen v1.0 for cross-system authorization interop

  AuthZen v1.0 is the emerging standard for authorization API interoperability across CNCF and broader ecosystem tools. If you're integrating OpenFGA with other policy engines or building a multi-system authz layer, test the new AuthZen endpoint now. Early adoption means your integration patterns align with where the ecosystem is heading rather than needing a retrofit later.

Cilium v1.19.2 is a patch release focused on stability: fixes span IPSec key rotation races, L7 LB policy bypass, clustermesh goroutine leaks, and a world-accessible Envoy admin socket.

• securityPatch the world-accessible Envoy admin socket immediately

  The Envoy admin socket was being created accessible to all users on the node (world-accessible). Any workload on the same node could interact with the Envoy admin API. If you're running Cilium with L7 policies or Envoy-based features, upgrade to v1.19.2 now. No config change needed — the fix is in the binary.

• securityIPSec users: silent packet drops during key rotation are fixed

  A race condition in IPSec key rotation caused packets to be dropped when a peer started using the new key before local XFRM states were ready. If you use IPSec encryption and do rolling key rotations, you were likely seeing unexplained connectivity blips. Upgrade and review your key rotation procedures — the fix also adds logging to the rotation flow, so you'll have better visibility going forward.

• breakingL7 LB ingress policy bypass — check your enforcement posture

  A bug allowed traffic to bypass ingress policies for local backends when L7 load balancing was active. If you rely on Cilium network policy enforcement for local service backends with L7 LB enabled, your policies may not have been enforced as expected. After upgrading to v1.19.2, verify that traffic is behaving as your policies intend — this fix restores correct enforcement, which could change observed traffic patterns.

Cilium v1.18.8 is a bug-fix patch with one critical caveat: GKE users must skip it due to a known regression introduced by the XDP jumbo MTU change.

• securityPatch the world-accessible Envoy admin socket immediately

  The Envoy admin socket was being created with world-readable/writable permissions, exposing it to any process on the node. This is fixed in v1.18.8. If you're running Cilium with L7 policy or any Envoy-based features, upgrade promptly. On existing nodes, verify socket permissions at /var/run/cilium/envoy/sockets/ — world access means any container with host path access could interact with the admin API.

• breakingGKE users: do not deploy v1.18.8

  The XDP jumbo MTU support (PR #44499) introduced a regression on GKE. If you're on GKE, skip this version entirely and upgrade to v1.19.2 instead. Running v1.18.8 on GKE risks network disruption. Non-GKE users are not affected by this specific issue.

• enhancementL7 LB policy bypass and FQDN SNI fixes are worth prioritizing

  Two policy-enforcement bugs are fixed here. First, local backends could bypass ingress policies under L7 LB — meaning traffic wasn't being filtered as expected. Second, wildcard FQDN policies weren't propagating correctly to Envoy when SNI-based matching was in use. If your environment uses either L7 load balancing or FQDN network policies with SNI, this release closes real security gaps. Plan the upgrade accordingly.

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

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

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

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

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

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

• securityPatch RUSTSEC-2026-0007 by upgrading immediately

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

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

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

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

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

etcd v3.6.9 is a maintenance release. The release notes are sparse — check the full CHANGELOG for the actual diff before upgrading.

• breakingRead the CHANGELOG before upgrading — release notes are incomplete

  The published release notes for v3.6.9 contain no change details. Before upgrading any etcd cluster, pull up CHANGELOG-3.6.md directly and diff the entries since your current version. The 3.6 series has known breaking changes, and skipping this step on a stateful system like etcd is a real risk.

• enhancementVerify container image source if you pull from quay.io

  etcd's primary registry is gcr.io/etcd-development/etcd. If your pipelines pull from quay.io/coreos/etcd, confirm that image is current and matches the gcr.io digest. Secondary registries can lag. Pin by digest, not just tag, to avoid silent version mismatches.

etcd v3.5.28 is a patch release in the 3.5 series. Release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingRead the CHANGELOG before upgrading — release notes are incomplete

  The published release notes for v3.5.28 contain no actual change details. Before upgrading any etcd cluster, pull the full CHANGELOG-3.5.md from the etcd repo and review entries since your current version. Skipping this on a stateful system like etcd is a real risk.

• enhancementStick to the primary container registry for pulls

  gcr.io/etcd-development/etcd is the authoritative image source. quay.io/coreos/etcd is secondary and may lag. If your cluster pulls from quay.io, verify the image digest matches the primary before deploying in production.

etcd v3.4.42 is a maintenance release on the 3.4 branch. The release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingCheck the upgrade guide even for patch releases

  The release explicitly calls out that breaking changes may exist. On a 3.4.x patch bump this is unlikely but not impossible — particularly around snapshot or WAL handling. Verify the upgrade guide is clean for your version before rolling out to production clusters.

• enhancementReview the full CHANGELOG before upgrading

  The release notes published here are essentially empty. Before applying this update to any environment, pull the CHANGELOG-3.4.md directly from the etcd repo to understand what bug fixes or patches are included. Blind upgrades on a critical consensus store are a bad idea.

Harbor v2.15.0 delivers proxy cache connection limits, per-endpoint CA certs, Cosign v3 bundle support, and a critical bearer token security fix alongside a Trivy supply chain incident bump.

• securityUpdate immediately: Trivy supply chain incident and bearer token bypass

  Two separate security issues landed in this release. First, Trivy was bumped to v0.69.3 after a supply chain incident affecting the scanner — run this update before your next scan cycle. Second, the bearer token fix rejects tokens issued before their associated project was created, which plugs an authorization gap. Both issues warrant prompt upgrades rather than waiting for a maintenance window.

• breakingGCR replication adapter removed — migrate any existing GCR replication rules

  The Google Container Registry adapter is gone. If you have replication rules targeting GCR endpoints, they will break silently after upgrading. Migrate those rules to use Artifact Registry (GAR) endpoints before upgrading to v2.15.0. Also, if you were using proxy cache projects pointed at GCR, those need to be reconfigured.

• enhancementCap proxy cache upstream connections to protect upstream registries

  The new `max_upstream_conn` parameter lets you throttle outbound connections per proxy cache project. If you're running Harbor as a pull-through cache for Docker Hub or other rate-limited registries, set this to avoid hitting upstream rate limits or overwhelming self-hosted registries. Configure it per-project via the UI or API after upgrading.

v1.12.1 is a focused maintenance release fixing OTLP endpoint URI parsing and improving ListObjects pipeline internals with Go native channels.

• breakingOTLP https:// scheme now forces TLS regardless of your config flag

  If you set OTEL_EXPORTER_OTLP_ENDPOINT with an https:// scheme, TLS will be enabled even if trace.otlp.tls.enabled is false. Audit your observability configs before upgrading — any environment using https:// endpoints with TLS explicitly disabled will now have TLS enabled. This is almost certainly the correct behavior, but verify your collector setup accepts TLS connections.

• enhancementOTLP endpoint URIs with schemes finally work — clean up your workarounds

  Previously, passing a full URI like http://host:4317 to OTEL_EXPORTER_OTLP_ENDPOINT would break because the scheme wasn't stripped before reaching the gRPC exporter. If you've been working around this by omitting the scheme, you can now use standard URI formats. Update your deployment configs and remove any manual scheme-stripping logic.

• enhancementListObjects performance improvement — no action needed, just upgrade

  Replacing the custom Pipe implementation with Go native channels reduces internal complexity and can improve throughput for ListObjects calls under concurrent load. No API changes, no config changes needed. The tuple validation refactor compounds this. If you're running OpenFGA at scale with heavy ListObjects usage, this patch is worth taking.

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

• securityUpgrade immediately to patch three Go stdlib CVEs

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

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

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

• enhancementLarge actor deployments and streaming workloads should prioritize this patch

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

Keycloak 26.5.6 is a critical security release patching 8 CVEs spanning SSRF, token reuse, IDOR, privilege escalation, and multiple information disclosure vulnerabilities. Upgrade immediately.

• securityPatch all 8 CVEs — upgrade to 26.5.6 now

  This release fixes eight CVEs covering SSRF, token replay, privilege escalation, IDOR, and multiple information disclosure paths. Three of these (SSRF via jwks_uri, privilege escalation via manage-clients, and auth session contamination) are particularly dangerous in multi-tenant or public-facing deployments. There is no workaround — upgrade is the only fix. If you're on any 26.x version, treat this as an emergency patch.

• securityAudit manage-clients grants and OIDC Dynamic Client Registration usage

  CVE-2026-3121 (privilege escalation via manage-clients) and CVE-2026-1180 (SSRF via jwks_uri in dynamic client registration) both require reviewing your current permission grants and feature flags. After upgrading, audit which users/service accounts hold manage-clients. If you don't use OIDC Dynamic Client Registration, disable it at the realm level to eliminate the SSRF attack surface entirely.

• breakingVerify Operator DB config and multi-realm startup behavior post-upgrade

  The 26.5.0 Operator regression for DB targetServerType=primary (affecting master-replica failover) and the O(N²) startup scan introduced in 26.5.4 are both fixed here. If you hit either of these bugs, validate your DB connection failover behavior and startup times after upgrading. Large deployments with many realms should see noticeably faster restarts.

v1.33.10 is a small patch fixing a kube-controller-manager nil pointer crash in ValidatingAdmissionPolicy and two kubeadm operational bugs. No dependency changes.

• breakingPatch immediately if you use ValidatingAdmissionPolicy with open schemas

  Any ValidatingAdmissionPolicy referencing an object schema with `additionalProperties: true` will crash kube-controller-manager outright — not degrade gracefully. If you're running v1.33.x and using VAP, check your policies now. Upgrade to v1.33.10 before deploying any new policies with open schemas, or you risk taking down the controller manager.

• enhancementkubeadm etcd learner fix matters for HA cluster joins

  When adding control plane nodes, etcd temporarily registers new members as learners. The previous behavior incorrectly included learner endpoints in the etcd client pool, which could cause client errors during promotion. If you run kubeadm-managed HA clusters and have experienced intermittent etcd client failures during control plane joins, this patch resolves it. Upgrade before your next control plane scaling operation.

• enhancementkubeadm reset now handles stubborn bind mounts cleanly

  On nodes with bind-mounted /var/lib/kubelet directories, `kubeadm reset` previously failed with EINVAL during unmount, leaving cleanup incomplete. The fix silently ignores EINVAL — which is expected for peer mounts — so resets complete cleanly. Useful if you automate node decommissioning with kubeadm reset in scripts.

v1.14.3 patches a TLS session resumption bypass that could skip certificate chain validation, plus fixes node cache rebuild and several reliability issues in AWS and federation scenarios.

• securityUpgrade immediately to fix TLS session ticket bypass

  TLS session resumption on SPIRE Server's TCP endpoint was allowing reconnecting clients to skip SPIFFE certificate chain validation — meaning a client with an expired or revoked cert could potentially reconnect without re-validation against the current trust bundle. This is a meaningful trust boundary violation. Upgrade to v1.14.3 now. No config change needed; the fix disables session tickets server-side automatically.

• securitySelector data no longer leaks into agent logs

  Selectors can encode workload identity details (e.g., Kubernetes pod labels, Unix UIDs, AWS metadata) that you may not want in logs. Previously, these were logged at agent level. After upgrading, audit your existing log pipelines and retention policies — any historical logs may still contain this data.

• breakingPQC users must migrate from Kyber draft to X25519MLKEM768

  If you've enabled RequirePQKEM TLS policy, the underlying algorithm changes from the draft x25519Kyber768Draft00 to the standardized X25519MLKEM768. Both peers must be running v1.14.3+ before this takes effect, otherwise TLS handshakes will fail. Plan a coordinated upgrade of agents and server if you're using this policy.

• enhancementNode cache rebuild fix is critical for long-running agents

  The periodic node cache rebuild was executing only once after startup instead of on its configured interval. Over time, agents in environments with frequent workload changes would serve stale cache data. This is silently fixed in v1.14.3 — no config changes needed, but you should upgrade agents promptly, especially in dynamic environments.