Releases

v1.37.3 is a security-focused patch fixing two HTTP/2 CVEs and oauth2 vulnerabilities — upgrade immediately if you use HTTP/2 or oauth2 filter.

• securityPatch HTTP/2 deployments now for CVE-2026-47774 and CVE-2026-27135

  Two HTTP/2 CVEs are fixed in this release. CVE-2026-47774 enables a cookie-bomb attack that causes excessive memory usage by sending large numbers of cookies that bypass header size limits before this fix. CVE-2026-27135 is an nghttp2-level vulnerability. If you terminate HTTP/2 traffic, upgrade to v1.37.3 immediately. The new cookie-counting behavior is enabled by default; if it causes regressions, you can temporarily disable it with the feature flag `envoy.reloadable_features.http2_include_cookies_in_limits`, but treat that as a short-term workaround only.

• securityRotate oauth2 HMAC secrets after upgrading

  The timing side-channel in HMAC verification means a patient attacker could have probed whether a given secret was valid. After upgrading, rotate your oauth2 HMAC secrets as a precaution — especially in internet-facing deployments. The AES-CBC crash fix is also relevant: the previous 1/256 spurious decryption success could cause unpredictable auth behavior, not just crashes.

• breakingCookie-heavy workloads may see HTTP/2 stream resets

  The CVE-2026-47774 fix changes how cookies are counted against `mutable_max_request_headers_kb` and `max_headers_count`. Clients sending many cookies that were previously accepted may now hit limits and receive stream resets. Test your high-cookie traffic patterns in staging before rolling this to production, and review your header size limits to ensure they are set appropriately for your workloads.

v1.36.7 is a security-focused patch addressing two CVEs in HTTP/2 and an HPACK cookie-bomb attack vector in the oauth2 filter, plus a crash fix. Upgrade immediately.

• securityPatch HTTP/2 CVEs now — two CVEs affect any HTTP/2-exposed Envoy

  CVE-2026-47774 enables a cookie-bomb attack where crafted HPACK-compressed cookies inflate to exhaust Envoy memory. After patching, cookies count toward `mutable_max_request_headers_kb` and `max_headers_count`. If you see legitimate requests being reset post-upgrade, the escape hatch is the `envoy.reloadable_features.http2_include_cookies_in_limits` flag — but audit your header size limits first rather than disabling the protection. CVE-2026-27135 is an nghttp2-layer fix with no workaround; you must upgrade.

• securityAudit oauth2 filter deployments for timing and decryption exposure

  Two oauth2 bugs fixed here are subtle but serious. The timing side-channel in HMAC verification could allow an attacker to probe secret validity over many requests. The AES-CBC crash (1/256 chance on bad tokens) is a reliability issue that could be triggered deliberately. If you use the oauth2 filter with token cookies, treat this as a high-priority upgrade — there's no configuration workaround for either issue.

• breakingReview header size limits before deploying — cookie counting is a behavior change

  Cookies previously excluded from header size accounting now count toward limits. In practice, applications with many or large cookies may hit `max_headers_count` or `mutable_max_request_headers_kb` and get HTTP/2 stream resets where they didn't before. Before rolling out, check your current limit configurations against real traffic cookie sizes. If you need time, the reloadable feature flag lets you defer the behavior change, but don't leave it disabled long-term.

v1.35.11 is a security-focused patch fixing two HTTP/2 CVEs and two oauth2 vulnerabilities — upgrade immediately if you're running HTTP/2 or oauth2 filter.

• securityPatch HTTP/2 HPACK cookie-bomb vulnerability now

  CVE-2026-47774 allows an attacker to craft requests with large numbers of HPACK-compressed cookies that decompress into massive header payloads, causing excessive memory usage. The fix resets offending streams and counts cookies toward existing header size limits. Roll out this patch to any Envoy instance terminating HTTP/2 traffic. If you hit legitimate regressions with cookie-heavy workloads, the flag `envoy.reloadable_features.http2_include_cookies_in_limits` can temporarily revert the behavior — but treat that as a short-term workaround, not a solution.

• securityUpgrade if you use the oauth2 filter — two separate fixes here

  There are two distinct oauth2 issues fixed: a timing side-channel in HMAC verification (exploitable via repeated probing to determine secret validity) and a crash from incorrect AES-CBC decryption behavior on secret mismatch. The crash was probabilistic (~1/256 per request) but real. If your deployment uses Envoy's built-in oauth2 filter for token validation, this patch directly reduces both crash risk and secret exposure surface.

• enhancementEvaluate stats eviction for high-cardinality metric environments

  The new `stats_eviction_interval` config allows Envoy to periodically purge unused metrics from memory. If you're running workloads with dynamic or high-cardinality labels (e.g., per-request or per-user stats), this can meaningfully reduce memory footprint over time. Test in staging first — eviction behavior depends on whether extensions implement the evictable metrics interface, so not all metrics will be affected.

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.19.0 ships the new /api/v3/trace-summaries endpoint and migrates the UI search to use it, plus TLS for ClickHouse and a configurable gRPC max message size.

• breakingUI search migration to /api/v3/trace-summaries requires compatible backend

  The UI now exclusively uses /api/v3/trace-summaries for search results. If you run a custom or older storage backend via the gRPC storage plugin, it must implement the SummaryReader interface or the fallback full-trace aggregation path kicks in. Verify your storage plugin supports this before upgrading. If you pin the UI separately from the backend, do not upgrade the UI to this version without also upgrading the backend to v2.19.0.

• breakingRename query.num_traces to query.search_depth in any API v3 clients

  Any scripts, dashboards, or integrations that pass query.num_traces to the v3 API will still work via the deprecated alias, but you should migrate to query.search_depth now. The deprecated alias will eventually be removed. Also check for snake_case HTTP query params — camelCase is now the canonical form, with snake_case kept as deprecated aliases.

• enhancementSet max_recv_msg_size_mib if you see gRPC message size errors in remote storage

  Teams using the gRPC remote storage plugin with large traces often hit the default gRPC message size cap. The new max_recv_msg_size_mib config option on the gRPC storage client lets you raise this limit explicitly. If you've been seeing 'received message larger than max' errors from your storage backend, configure this value in your Jaeger deployment config to fix it without workarounds.

• enhancementEnable TLS for ClickHouse storage in production

  The ClickHouse storage plugin now supports TLS configuration. If you're running ClickHouse as a Jaeger backend in any environment where the connection crosses a network boundary, configure TLS now rather than relying on network-level controls alone.

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.

CRI-O v1.35.4 is a patch release with no code changes or dependency updates from v1.35.3 — essentially a rebuild or re-tag of the previous patch.

• enhancementSkip this upgrade unless you need a clean rebuild

  There are zero changelog entries and zero dependency changes. This release is likely a rebuild triggered by a CI/pipeline issue or a signing/artifact correction. If you're already on v1.35.3 and it's working, there's no functional reason to upgrade. Check the CRI-O GitHub issue tracker or release PR for context on why this tag was cut before deciding to roll it out.

• enhancementVerify artifact integrity with cosign and SBOM before deploying

  Even for a no-change release, practice your supply chain verification workflow: use cosign to verify the signature on the tarball and the bom tool to validate the SPDX SBOM. This is good hygiene to establish before you need it on a critical release.

CRI-O v1.36.1 is a small patch fixing a container status regression where ImageRef flipped to a raw image ID after restart, plus a debug log verbosity reduction.

• breakingUpgrade if you rely on ImageRef for image identity after restarts

  Before this fix, CRI-O restarts caused ImageRef in container status to switch from a repo@digest string to a raw image ID. Any tooling that parses ImageRef — admission controllers, audit pipelines, image policy enforcers — could silently receive the wrong format and fail validation or produce incorrect audit records. If you run workloads where CRI-O restarts are common (e.g., upgrades, node reboots), patch to v1.36.1 immediately and validate your tooling handles the repo@digest format consistently.

• enhancementExpect quieter debug logs under high-frequency List* RPC calls

  Clusters with aggressive monitoring or reconciliation loops generating frequent ListContainers/ListPodSandboxes calls were generating excessive debug log volume, which hurt CRI-O performance under high load. After this patch, debug logging is less chatty for these paths. If you previously reduced log levels specifically to work around this noise, you can now safely re-enable debug logging without the same overhead.

CRI-O v1.34.9 fixes two concurrency bugs: a panic from racing StopContainer calls and a spurious exit code 255 on fast-exiting containers. Pure bug-fix release, no dependency changes.

• breakingPanic risk on concurrent StopContainer — upgrade if you drain nodes or run rapid pod teardowns

  If your cluster drains nodes, runs batch workloads with rapid pod churn, or uses any automation that issues multiple StopContainer calls in parallel, the pre-fix versions could panic CRI-O, taking down the container runtime on that node. This is a hard crash, not a graceful error. Upgrade to v1.34.9 immediately on any node where concurrent stop operations are plausible.

• enhancementExit code 255 false positives are gone — review alerting and restart policies

  Exit code 255 is often treated as a runtime-level failure in monitoring stacks and can trigger unnecessary pod restarts or alerts. If you have OOMKill or fast-exit workloads (init containers, short-lived jobs) and have seen spurious 255 exit codes in your logs or metrics, those were false positives from this race. After upgrading, audit your alerting rules and CrashLoopBackOff history — you may find some pods were incorrectly flagged.

Single-fix patch release resolving a race condition that caused CRI-O to incorrectly report exit code 255 for fast-exiting containers.

• breakingFalse exit code 255 may have masked real container failures

  If your monitoring, alerting, or restart policies key off exit code 255, you may have been misclassifying fast-exiting containers as crashed. After upgrading, audit any runbooks or OOMKill/CrashLoopBackOff workflows that treat exit code 255 as a specific signal — the real exit codes from short-lived containers will now surface correctly.

• enhancementUpgrade straightforward for 1.33.x users — no config or dependency changes

  This is a clean drop-in replacement for v1.33.12. No dependency bumps, no config changes required. Plan a rolling node drain and replace the CRI-O binary. Prioritize nodes running batch jobs, init containers, or short-lived workloads where fast exits are common and exit code accuracy matters most.

Security patch release fixing CVE-2026-46680 plus runtime bugs in sandbox service, AppArmor compatibility, and OCI USER spec handling.

• securityPatch CVE-2026-46680 immediately

  CVE-2026-46680 is the primary driver for this release. Review the GHSA advisory to understand the attack surface and severity. If you run containerd 2.1.x in any environment, upgrading to 2.1.8 should be your next deployment task. There are no dependency changes, so the upgrade path is straightforward.

• breakingOCI USER out-of-range values now fail explicitly — check your container specs

  Previously, out-of-range USER values in OCI specs could silently fall through to username/group lookups, masking misconfigurations. Now containerd returns an explicit error. If any of your containers or image builds set numeric USER values outside valid UID/GID ranges, they will start failing visibly after this upgrade. Audit your specs before rolling out to production.

• enhancementUpgrade if you run AppArmor < 3.0 or use sandbox-based runtimes

  The conditional AppArmor abi fix is a real blocker for anyone on older AppArmor (e.g., Ubuntu 20.04 ships 2.x). The sandbox service bug also affects event-driven workflows and correct sandbox creation — silent misconfiguration is worse than a visible error. If you use Kata Containers or any sandbox-based runtime, this fix directly affects you.

Rook v1.20 hands CSI driver management to the Ceph CSI operator — a breaking change for anyone with custom CSI config — while adding encrypted OSD resize, Vault Agent SSE-S3, and stabilizing concurrent cluster reconciliation.

• breakingMigrate CSI config to Ceph-CSI operator before customizing anything

  Existing clusters will survive the upgrade with previously applied CSI settings, but any future CSI changes must go through the Ceph-CSI OperatorConfig and Driver CRs — not the Rook configmap. Helm users need the ceph-csi-drivers chart for operator settings (custom images stay in rook-ceph chart values). Audit your current CSI customizations now and plan the migration path before upgrading. Don't wait until you need to change a CSI setting post-upgrade to figure this out.

• enhancementAudit CRUSH rules before upgrading if you rely on custom ones

  Rook now deletes unused CRUSH rules by default on mgr startup. If your environment has CRUSH rules that appear unused but are intentionally retained for failover or manual placement, set ROOK_DELETE_UNUSED_CRUSH_RULES=false in the operator config before upgrading. Losing custom CRUSH rules silently is the kind of thing that only hurts when you need them most.

• enhancementEnable concurrent cluster reconciliation if running multiple Ceph clusters

  ROOK_RECONCILE_CONCURRENT_CLUSTERS is now marked stable after testing in prior releases. If you manage multiple CephCluster objects in one operator, enable this setting to reduce reconciliation bottlenecks. This is especially useful in multi-tenant or multi-cluster operator deployments where one slow cluster previously blocked others.

v1.17.0 hardens cache key generation against hash-flooding attacks and adds configurable OpenTelemetry trace sampling, including parent-based propagation.

• securityUpgrade to get hash-flooding protection in cache keys

  The old string-concatenation cache key approach was vulnerable to hash-flooding attacks and key collisions. The new TLV encoding with per-process hash seeding closes both issues. There are no config changes required — just upgrade. If you run OpenFGA in a multi-tenant or public-facing setup, this is a meaningful security improvement that warrants prioritizing the upgrade.

• enhancementConfigure parent-based trace sampling if OpenFGA runs behind an API gateway or service mesh

  Previously, OpenFGA couldn't honor upstream sampling decisions, meaning traces could be captured inconsistently across your stack. Set `OPENFGA_TRACE_SAMPLER=parentbased_always_on` (or `parentbased_traceidratio`) so OpenFGA respects the sampling decision made by the calling service. This is especially useful when OpenFGA is a downstream dependency in a larger traced system — it reduces trace noise and aligns sampling with your existing observability strategy.

NATS v2.14.2 is a focused stability release fixing multiple JetStream data integrity issues, lock release bugs, and protocol corruption risks — upgrade if you run JetStream at any meaningful scale.

• securityProtocol corruption vectors closed — critical for WebSocket and JetStream users

  Two protocol corruption bugs were fixed: one in $JS.ACK subject rewriting and one in compressed WebSocket client buffer handling. Either could produce malformed frames that corrupt stream state or client sessions. If you expose NATS WebSocket endpoints or rely heavily on JetStream ACKs, treat this as a security-adjacent stability issue and prioritize the upgrade.

• breakingTwo separate lock-release bugs can cause silent hangs — patch now

  Both the filestore and consumer code paths had cases where locks were never released after specific error conditions (write errors and start sequence errors). In production this means stuck consumers or hung filestore operations that don't recover without a restart. If you've seen unexplained JetStream stalls, this is likely why. Upgrade to v2.14.2 immediately.

• enhancementHigh subject-count streams no longer risk CPU spikes — no config change needed

  The filestore block skip check was triggering runaway CPU on streams with very high subject counts. The fix is automatic after upgrade — no configuration changes required. If you've been working around this with stream design compromises (e.g., artificially limiting subjects per stream), you can revisit those decisions after upgrading.

v2.12.10 is a focused bug-fix release addressing protocol corruption risks, JetStream Raft/quorum issues, and a CPU runaway bug in high-cardinality streams.

• securityUpdate x/crypto and nkeys immediately

  This release bumps golang.org/x/crypto to v0.52.0 and nkeys to v0.4.16. These libraries handle cryptographic operations in NATS auth flows. Don't wait for scheduled maintenance — patch now, especially if your clusters are internet-exposed or use decentralized auth.

• breakingProtocol corruption fixes require prompt upgrade for WebSocket and JetStream users

  Two separate protocol-level corruption bugs are fixed here: one in compressed WebSocket clients, one in $JS.ACK subject rewriting. Either can silently corrupt message framing. If you run WebSocket clients or any JetStream workload with acknowledgements, staying on 2.12.9 or earlier is a real risk. Upgrade servers first, then clients.

• enhancementHigh-cardinality JetStream streams get a CPU safety fix — verify your config

  The block skip check on streams with very high subject counts could cause runaway CPU. That check is now disabled for those cases. If you've been seeing unexpected CPU spikes on JetStream nodes with streams containing millions of subjects, this is likely the culprit. After upgrading, also review Counter stream and message schedule configs — new constraints are enforced that may reject previously accepted but incorrect configurations.

Longhorn v1.12.0 promotes the V2 Data Engine to GA, ships dual-stack/IPv6 support, and fixes critical instance-manager panics and replica scheduling bugs that caused cascading volume failures.

• breakingMigrate V2 backing image volumes before upgrading

  Any V2 volume created from a backing image cannot be upgraded in-place. Before upgrading to v1.12.0, back up each affected volume, delete it, and restore from backup — the restored volume has no backing image dependency. Skipping this step will cause attach failures post-upgrade. Use CDI for future VM disk image imports.

• breakingDetach V2 volumes before patch-level upgrades

  V2 volumes do not support live upgrades between v1.12.x patch releases. Plan maintenance windows to detach all V2 volumes before applying patch upgrades. Live upgrade across minor versions (v1.12 to v1.13) is planned but not yet available.

• breakingEncrypted migratable volumes need engine image upgrade before live migration

  The LUKS2 header pre-allocation fix for encrypted volumes introduces a constraint: live migration of encrypted volumes requires engine image CLI API version 12 or later. Upgrade the engine image to v1.12.0+ before attempting live migration; otherwise migration will fail.

• enhancementReview SPDK CPU allocation on existing V2 deployments

  The default CPU mask now uses 2 cores instead of 1. For clusters already running V2 volumes with a manually set single-core mask, consider increasing it — single-core configs under heavy I/O cause RPC starvation and operational instability. On ARM64 with NVMe-backed node disks, avoid multi-core SPDK configs for now and use AIO-backed disks until the stuck I/O bug is resolved.

• enhancementEnable dual-stack networking — but verify node IP family ordering first

  Dual-stack Kubernetes clusters are now supported, but only when all nodes have IP families configured in the same order (all IPv4-first or all IPv6-first). Audit your node network configs before enabling. Mixed ordering causes replica-to-engine connectivity failures with no obvious error surface.

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.

etcd v3.6.12 is a patch release in the 3.6 series. The release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingRead the CHANGELOG before upgrading

  The release notes for v3.6.12 are essentially empty — no changes are listed inline. Before upgrading any etcd cluster, pull the full CHANGELOG-3.6.md from the repo and review all entries since your current version. The official upgrade guide explicitly warns of potential breaking changes in the 3.6 series.

• enhancementVerify container registry targets in your pipelines

  etcd maintains two registries: gcr.io is primary, quay.io is secondary. If your CI/CD or deployment manifests pin to quay.io, confirm it stays in sync with the primary. For production clusters, prefer gcr.io/etcd-development/etcd to avoid lag.

etcd v3.5.31 is a patch release on the 3.5 branch. Release notes are minimal — check the full CHANGELOG for specifics before upgrading.

• breakingCheck the upgrade guide even for patch versions

  The etcd team explicitly calls out that breaking changes can appear in patch releases. Don't skip the upgrade guide assuming this is safe to apply blindly. Verify any API or storage format changes against your current deployment before scheduling maintenance.

• enhancementReview CHANGELOG before upgrading

  The release notes published here are sparse. Before rolling this out, pull the full CHANGELOG-3.5.md directly from the etcd repo to identify any bug fixes or behavioral changes that affect your cluster. Patch releases on 3.5 have historically included compaction fixes and lease handling improvements — worth verifying what specifically landed here.

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

• breakingCheck the official upgrade guide even for patch releases

  The release explicitly flags that breaking changes may exist. Etcd 3.4.x is a mature but still-active branch used heavily in Kubernetes clusters. Verify the upgrade guide at etcd.io before rolling this out, especially in production environments where quorum and data integrity are non-negotiable.

• enhancementReview CHANGELOG before upgrading — release notes are intentionally minimal

  This release page contains almost no detail. Before upgrading, pull up CHANGELOG-3.4.md directly in the etcd GitHub repo to understand what actually changed. Blind upgrades on etcd — your cluster's source of truth — are a bad idea regardless of how minor a patch looks.

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

• breakingUpgrade immediately if using Cosmos DB for workflow state

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

• enhancementCheck metrics now to assess blast radius before upgrading

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

flagd core v0.16.0 changes disabled flag evaluation from an error response to a successful resolution with reason=DISABLED, affecting gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit any code that checks errorCode or reason on flag evaluations

  If your code branches on FLAG_DISABLED error codes or checks the reason field from direct gRPC/OFREP responses, it will no longer receive that error path for disabled flags — it'll get a success with reason=DISABLED instead. Search your codebase for FLAG_DISABLED string matches, error-code switch statements, and reason-field conditionals before upgrading. SDK users who only consume the resolved value are unaffected and can upgrade without changes.

• enhancementUse reason=DISABLED for observability and audit logging

  The new behavior is actually cleaner for telemetry. Since disabled flags now resolve successfully, you can distinguish 'flag disabled' from 'evaluation error' in your metrics and logs without special-casing error codes. Update your dashboards and alerting rules to treat reason=DISABLED as an expected, non-error signal rather than filtering it out as noise.

flagd v0.16.0 changes disabled flag evaluation from an error to a successful resolution with reason=DISABLED, affecting direct gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit error-handling code that checks FLAG_DISABLED or errorCode

  If your application checks the evaluation reason or error code after a flag resolution — whether through direct gRPC calls, OFREP HTTP calls, or Go imports of core/pkg/model — you need to update that logic. FLAG_DISABLED errors will no longer appear; instead expect a successful response with reason=DISABLED. SDK users who only read the resolved value are unaffected, but any monitoring, alerting, or branching logic that keys off FLAG_DISABLED will silently stop triggering. Grep your codebase for FLAG_DISABLED and errorCode checks before upgrading.

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.

Lima v2.1.2 is a broad maintenance release fixing hostagent resource leaks, zombie processes, and gRPC connection leaks — plus template updates for Kubernetes 1.36, Ubuntu 26.04, and Fedora 44.

• breakingAlpine template split — update your instance configs

  The generic `template:alpine` has been split into `template:alpine-3.21`, `template:alpine-3.22`, and `template:alpine-3.23`. If you reference `template:alpine` in scripts, CI, or configs, those references will break. Audit and update them to a specific versioned template before upgrading.

• breaking_LIMA_QEMU_UEFI_IN_BIOS is deprecated — stop using it

  If you have the `_LIMA_QEMU_UEFI_IN_BIOS` environment variable set in any scripts or dotfiles, remove it now. The flag is deprecated in this release and will likely be removed in a future version. Check wrapper scripts and CI pipelines that invoke limactl with QEMU.

• enhancementHostagent resource leak fixes — worth upgrading if you run long-lived instances

  Four separate hostagent fixes address GuestAgentClient leaks, inotify watcher accumulation, and gRPC stream mishandling on reconnect. If you've seen memory creep or stale connections in long-running Lima instances, this release directly addresses those issues. Upgrade proactively rather than waiting.

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

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

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

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

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

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

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

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

• breakingUnblock chart upgrades: ConfigMap size issue resolved

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

• breakingScheduler now respects cluster resource limits

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

• enhancementSearch now reflects recovered cluster resources correctly

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

• enhancementCluster readiness now waits for failure threshold

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

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

• breakingFix scheduler resource exhaustion vulnerability

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

• breakingCluster readiness now respects failure threshold

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

• enhancementWatch discovery now reflects recovered cluster resources

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

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

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

• securityAlpine base image updated to 3.23.4

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

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

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

• breakingDeprecated gRPC fields in scheduler-estimator require plugin updates

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

• breakingRemoved flags and metric labels will break existing configs

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

• enhancementCritical scheduler and eviction bug fixes

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

• enhancementEnable SchedulingOvercommitProtection in high-throughput clusters

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

• enhancementOverflow Cluster Affinities for hybrid cloud burst scheduling

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

Linkerd edge-26.5.5 was released, but the published notes are too brief to summarize. See the original release notes for details.

OpenFeature core/v0.15.8 was released, but the published notes are too brief to summarize. See the original release notes for details.

OpenFeature flagd/v0.15.7 was released, but the published notes are too brief to summarize. See the original release notes for details.

v1.120.3 patches two Go CVEs and ships a wide range of bug fixes across AWS, Azure, Oracle, and DigitalOcean providers, plus OVH support and cosign image signing.

• securityPatch vulnerable Go dependencies — upgrade immediately

  A Go dependency update patches GHSA-xmrv-pmrh-hhx2 and CVE-2026-34986. If you're running any v1.120.x release prior to v1.120.3, upgrade now — these are dependency-level vulnerabilities, not just code changes.

• breakingMCP server is now opt-in — check your config before upgrading

  The MCP server now defaults to disabled (MCP_SERVER_ENABLED=false). If you were relying on it being on by default, set the env var explicitly after upgrading. Check your deployment manifests before rolling out.

• enhancementEnable cosign image verification in your admission pipeline

  Container images are now signed with cosign keyless signing and include SLSA provenance attestations. If your admission policy requires image signature verification, you can now enforce it against OpenCost images. Update your policy tooling (e.g., Kyverno, Cosign verify) to validate these attestations in CI or at deploy time.

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

Linkerd edge-26.5.4 was released, but the published notes are too brief to summarize. See the original release notes for details.

gRPC v1.81.0 drops Python 3.9 and Ruby 3.1 support, fixes crash-level races on Windows and ARM, and adds AsyncIO observability for Python.

• breakingPython 3.9 support dropped — check your runtime

  gRPC Python 1.81.0 drops Python 3.9 support. If your services still run on Python 3.9, stay on an older gRPC release until you can upgrade your runtime. Plan the Python version bump before pulling this release.

• breakingRuby 3.1 support dropped — upgrade your Ruby runtime

  Ruby 3.1 has reached EOL and gRPC 1.81.0 drops support for it. If you're running Ruby 3.1 in production with gRPC, you'll need to upgrade to Ruby 3.2+ before adopting this release.

• enhancementWindows and ARM stability fixes worth taking

  Two EventEngine fixes address a use-after-free and a race condition causing assertion errors on Windows, plus a completion queue shutdown race on ARM (weak memory model). If you run gRPC on Windows or ARM-based infrastructure, this release directly fixes stability issues that could cause crashes. Upgrade when stable.