Releases

v7.0.0 fixes a Windows-specific security vulnerability in delegation path matching and tightens the ngclient API with one breaking constructor change.

• securityPatch Windows deployments immediately for GHSA-qp9x-wp8f-qgjj

  Delegation path matching was broken on Windows, meaning a malicious or misconfigured repository could match targets it shouldn't. If any of your TUF clients run on Windows, upgrade to v7.0.0 now. Linux/macOS deployments are unaffected, but upgrading is still the right move before paths diverge further.

• breakingUpdate all Updater() call sites to use the named bootstrap argument

  The Updater() constructor signature changed: 'bootstrap' is now a required keyword argument. Any code calling Updater() without explicitly passing 'bootstrap' will break. Audit your code for Updater instantiations — if you weren't passing a bootstrap value before, add bootstrap=None to restore the previous behavior. This is a one-line fix per call site, but it will cause an immediate TypeError if missed.

• enhancementWatch for securesystemslib.hash removal in upcoming releases

  This release starts phasing out the securesystemslib.hash dependency. If your codebase or any custom TUF extensions directly import or rely on securesystemslib.hash, start planning a migration now rather than scrambling when a future release drops it entirely.

pack v0.40.6 is a small patch fixing a trust detection bug in 'builder inspect' and adding Heroku's builder:26 to the trusted builders list.

• breakingAudit pipelines that worked around the trust detection bug

  If your CI scripts or automation added extra flags or workarounds because 'builder inspect' was misreporting trusted builders as untrusted, remove those workarounds now. Running with unnecessary trust overrides is a security smell worth cleaning up.

• enhancementUse heroku/builder:26 without manual trust configuration

  Teams targeting Heroku's stack 26 no longer need to manually mark the builder as trusted via '--trust-builder' or config file entries. Upgrade to v0.40.6 and clean up any explicit trust overrides you've added for this builder.

Dapr v1.17.7 is a dense bug-fix release targeting workflow reliability, messaging correctness, and control-plane resilience. Fourteen production-grade fixes land here — upgrade if you run workflows, Kafka, or RabbitMQ.

• securityUpgrade sentry immediately if you downgraded from 1.18 or use Ed25519/RSA issuer keys

  A type-switch bug in dapr/kit caused sentry to crash on startup with 'unsupported key type' for Ed25519 and RSA issuer keys. Sentry enters a crash-loop, stops issuing mTLS identities, and halts cert rotation. Sidecars with unexpired certs keep running, but any pod restart or cert expiry silently breaks identity. If your trust bundle was generated by 1.18 or you manually rotated to Ed25519/RSA keys, this is a crash-loop waiting to happen. Upgrading to 1.17.7 is the only fix — no trust bundle migration needed.

• breakingScheduler etcd compaction mode change requires PVC capacity review

  The embedded etcd compaction mode switches from periodic (10 min) to revision-based (1,000,000 revisions), and the default storage size jumps from 1Gi to 16Gi. Kubernetes StatefulSet volumeClaimTemplates are immutable, so existing 1Gi PVCs are NOT automatically resized. If you're running the scheduler at any real workflow throughput, check your current PVC utilization now. If you're close to capacity, expand the PVC on the cluster before upgrading. The helm chart uses a lookup helper to avoid overwriting existing PVC sizes, but it cannot expand them for you.

• enhancementAdd workflow payload size ratio dashboards before upgrading

  Two new histograms — dapr_runtime_workflow_payload_size_ratio and dapr_runtime_workflow_activity_payload_size_ratio — report payload size as a fraction of --max-body-size. Before upgrading, set up a Prometheus alert on histogram_quantile(0.99, ...) > 0.9 so you catch workflows trending toward the 0.95 stall threshold before they freeze. This is especially useful for workflows with large activity payloads or long histories. Note: metrics are only recorded when --max-body-size is explicitly configured.

Native sidecars promoted to GA and enabled by default, plus a security fix restricting Server resources from affecting workloads outside their namespace. Heavy dependency refresh across Rust and Go stacks.

• securityServer namespace isolation fix — review cross-namespace Server resources immediately

  A fix was applied so that Server resources can no longer affect workloads in namespaces other than their own. If you have intentionally or accidentally created Server policies that were influencing workloads cross-namespace, those policies will silently stop applying after this upgrade. Audit your Server resources across all namespaces and verify that authorization policies still behave as expected post-upgrade. The risk of misconfigured over-broad policies is reduced, but any reliance on the previous behavior will break.

• breakingNative sidecars are now on by default — audit your cluster before upgrading

  Native sidecar support (using Kubernetes init containers with restartPolicy: Always) is now GA and enabled by default. If your cluster runs Kubernetes < 1.29, native sidecars are unsupported and this will break injection. Even on supported versions, verify that any tooling, admission webhooks, or pod lifecycle assumptions in your workloads are compatible. Test in a staging environment before rolling out to production. If you need the old behavior, explicitly disable the feature flag during install/upgrade.

• enhancementConfigure honorTimestamps on the linkerd-proxy PodMonitor

  If you're using the Prometheus Operator and have timestamp alignment issues in your Linkerd proxy metrics (e.g., stale or out-of-order samples), you can now set honorTimestamps in the Helm chart for the linkerd-proxy PodMonitor. This is a quality-of-life win for teams with strict metric ingestion pipelines. Set it explicitly during your next Helm upgrade rather than leaving it at the default.

Helm v3.21.0 bumps Kubernetes client libs to v1.36, patches OpenTelemetry CVEs, fixes OCI index chart pulling, and corrects nil value preservation in chart merging. Helm v3 EOL is approaching.

• securityUpgrade immediately to patch OpenTelemetry CVEs

  OpenTelemetry packages were patched specifically to address CVEs. If you're running Helm in CI/CD pipelines or as part of automation tooling, upgrade to v3.21.0 now. Don't wait for the next patch release.

• breakingPlan your Helm v4 migration — v3 EOL is real

  The release explicitly warns that Helm v3 is approaching end-of-life. This is not a distant concern — v3.22.0 targets Kubernetes v1.37 and v3.21.1 is just a bug fix release. Start evaluating Helm v4 changes now, especially if you maintain custom plugins or automation built around Helm's CLI or Go SDK.

• enhancementTest OCI index-based chart pulls if you use multi-arch registries

  The fix for pulling charts from OCI indices means setups using image index manifests (common in multi-arch environments) should now work reliably. If you previously worked around this with direct digest references or manifest-specific tags, revisit those workarounds — they may no longer be necessary.

Helm v4.2.0 ships Kubernetes 1.36 client support, a new mustToToml template function, fixes for dry-run server mode with generateName, and several post-renderer YAML parsing correctness fixes.

• breakingRemove --hide-notes and --render-subchart-notes from your CI scripts

  Both flags are now deprecated and will likely be removed in a future release. Audit your helm install/upgrade/template invocations in CI pipelines and scripts. Dropping them now avoids a forced migration later when they're removed entirely.

• enhancementAdopt mustToToml for safer TOML templating

  The new mustToToml function behaves like mustToJson — it returns an error instead of silently failing when TOML serialization goes wrong. If you're using toToml anywhere in your chart templates, swap it for mustToToml so template rendering failures are surfaced as actual errors rather than empty or malformed output.

• enhancementValidate --dry-run=server against generateName resources

  Previously, --dry-run=server skipped resources that used generateName instead of name, which gave false confidence that those resources were being validated. That's fixed now. Re-run your server-side dry-run checks against any charts that use generateName — you may catch validation errors that were previously being silently ignored.

Cilium v1.19.4 is a stability-focused patch release with 20+ bug fixes covering crash prevention, IPsec reliability, and Cluster Mesh correctness — upgrade if you run any of those features.

• securityUpdate moby/spdystream dependency (security fix included)

  This release bumps github.com/moby/spdystream to v0.5.1 as a security fix. The dependency is used in Kubernetes API communication paths. No CVE number is listed in the release notes, but treat this as a prompt to upgrade — staying on v1.19.3 leaves the exposure open.

• breakingHand-managed EndpointSlices need service-proxy-name label added

  If you set --k8s-service-proxy-name and manage EndpointSlices manually, those slices will now be filtered OUT at the watch level unless they carry the matching service.kubernetes.io/service-proxy-name label. After upgrading, any untagged hand-managed slice becomes invisible to Cilium, causing traffic drops. Audit your EndpointSlices before upgrading and stamp the label on any that are missing it.

• enhancementPrioritize upgrade if you run IPsec, WireGuard, or Cluster Mesh

  Three distinct data-plane reliability fixes land here: IPsec packet drops during rolling key rotation, WireGuard silent packet loss under constrained MTU with IPv6, and Cluster Mesh missing backends for multi-port services. Any of these can cause hard-to-diagnose intermittent connectivity issues. If your environment uses any of these features, this patch should move to the front of your upgrade queue.

v1.17.16 patches a cross-namespace traffic hijacking vulnerability in CiliumLocalRedirectPolicy, fixes an IPsec panic on malformed input, and resolves a static pod identity resolution bug.

• securityAudit LRP addressMatcher configs before upgrading

  The LRP addressMatcher change fixes a real attack vector: a policy in one namespace could previously override a Service frontend and redirect traffic cross-namespace. After upgrading, any LRP that was relying on this override behavior will stop working silently — traffic won't redirect as expected. Before upgrading, audit your CiliumLocalRedirectPolicy objects for addressMatcher entries that overlap with existing Service frontends. If you legitimately need the old behavior, set --enable-lrp-address-matcher-override=true, but treat that as a temporary measure and redesign the policy.

• securityUpgrade if running IPsec — agent crash risk on malformed input

  The parseSPI panic means a malformed IPsec packet could crash the Cilium agent, taking down networking on that node. This is a low-complexity denial-of-service risk for any cluster using Cilium's IPsec transparent encryption. Upgrade to v1.17.16 promptly if IPsec is enabled in your environment.

• breakingLRP addressMatcher behavior change is not fully backward-compatible

  This is a behavior change, not just a bug fix. If you have CiliumLocalRedirectPolicies using addressMatcher that overlap with Service ClusterIPs or external IPs, those policies will now be rejected or ignored where they previously worked. Test your LRP configurations in a non-production environment before rolling this upgrade out. The opt-in flag --enable-lrp-address-matcher-override=true exists, but using it means you are accepting the previously-vulnerable behavior.

Cilium v1.18.10 is a stability-focused patch release fixing agent crashes, IPsec panics, Cluster Mesh backend gaps, and a data race in IPAM — all backported from upstream.

• securitymoby/spdystream and x/net security updates are included

  This release pulls in a security fix for github.com/moby/spdystream and bumps x/net to v0.53. Both are network-layer dependencies. If your policy or threat model tracks transitive dependency CVEs, this patch justifies the upgrade on its own.

• breakingUpgrade encrypted clusters to fix IPsec panic risk

  A panic in parseSPI on malformed IPsec input could crash the agent on nodes running encrypted traffic. If you use IPsec encryption, treat this as a priority upgrade — a malformed packet or misconfigured peer can take down the agent process entirely.

• enhancementCluster Mesh users with shared target ports should upgrade

  The missing global service backends bug silently dropped backends from services where multiple ports mapped to the same target port. Traffic would route correctly within a single cluster but fail cross-cluster. Upgrade and verify affected services post-rollout using hubble observe or service endpoint inspection.

Jaeger v2.18.0 brings two breaking changes (OTEL metrics overhaul and removed min-step API), useful header-forwarding for ES/OpenSearch, and a massive UI refactor migrating state management from Redux to Zustand.

• breakingAudit your metrics dashboards before upgrading

  The OTEL collector package upgrade changed metric names and shapes. Before upgrading, compare your current Jaeger metrics against the new ones by running both versions in parallel or checking the PR diff. Any Grafana dashboards, Prometheus alerts, or monitoring rules built on Jaeger's internal metrics need to be reviewed and updated. The min_step removal is a smaller blast radius — only affects custom tooling that calls the metricstore API directly — but still requires a code or config change before upgrading.

• enhancementUse header forwarding if you authenticate ES/OpenSearch with custom headers

  If your Elasticsearch or OpenSearch cluster requires auth headers beyond basic username/password (e.g., custom JWT, IAM proxy headers), configure the new header-forwarding feature. This also helps in multi-tenant setups where storage routing depends on request headers. Configure via the storage backend settings in jaeger-query or the gRPC storage plugin config.

• enhancementEvaluate ClickHouse as a storage backend if you want SPM without Prometheus

  ClickHouse SPM support is experimental but now covers the full metrics trifecta: call rates, error rates, and latencies. TTL support is also added. If you're running ClickHouse already or want a single-store solution for both traces and metrics, this is the release to start testing against. Don't use it in production yet, but set up a staging environment to track maturity.

Argo CD v3.3.10 is a patch release fixing a nil-pointer panic in permission validation, a log line UI overflow bug, and bumping Go to 1.25.9 to address CVEs.

• securityUpgrade immediately — Go 1.25.9 fixes CVEs in the runtime

  The Go runtime was bumped from a prior version to 1.25.9 specifically to resolve CVEs. The release notes don't enumerate the CVE IDs, but any patch that upgrades the runtime for security reasons on a stable branch deserves prompt action. If you're running 3.3.x, upgrade to 3.3.10 now rather than waiting for your next maintenance window.

• breakingServer-side diff now correctly hides secrets — verify diff outputs if you rely on them

  The fix to apply HideSecretData to server-side diff results means that previously exposed secret values in diff views will now be redacted. If any automation, alerting, or audit tooling parses diff output expecting raw secret values, it will break. Review your diff-dependent workflows before upgrading.

• enhancementNil APIResource panic fix prevents unexpected controller crashes

  The permission validator could panic when an APIResource was nil — a condition that can occur with certain custom or non-standard API groups. If you've seen intermittent ArgoCD controller restarts without clear cause, this is a likely culprit. Upgrade to 3.3.10 to stabilize those environments.

Argo CD v3.4.2 is a patch release fixing a panic in the permission validator, reverting a problematic revision update optimization, and patching secret data exposure in server-side diffs.

• securitySecret values could appear in diff output — patch now

  Server-side diff results for Secret resources were not having HideSecretData applied, meaning secret values could be exposed in diff views through the UI or API. If you use server-side apply or server-side diff previews, upgrade to 3.4.2 immediately. Audit your ArgoCD API access logs if you suspect exposure.

• breakingUpdateRevisionForPaths revert may re-introduce previous behavior

  The optimization that avoided unnecessary UpdateRevisionForPaths calls (merged in 3.4.x) caused regressions and has been reverted. If you were relying on that behavior for performance or correctness, expect the pre-fix behavior to return. Monitor sync operations after upgrading, especially for path-filtered applications.

• enhancementPermission validator panic fix improves stability

  A nil APIResource in the permission validator could crash the ArgoCD server process. This is now guarded. If you've seen unexpected pod restarts on the ArgoCD server, especially in environments with non-standard CRDs or API aggregation, this patch likely addresses it.

Kubernetes v1.36.1 is a focused patch release fixing 8 bugs across networking, node, and cluster lifecycle — most impacting Windows environments, ZFS nodes, and kubeadm-managed clusters.

• breakingZFS nodes: upgrade immediately if running v1.36.0

  kubelet fails to start on ZFS-backed nodes in v1.36.0 due to a missing cadvisor plugin. If you deployed v1.36.0 on ZFS storage, those nodes are likely not running. Patch to v1.36.1 before any further ZFS node rollouts.

• breakingWindows L2Bridge users: DNS timeouts are fixed but require upgrade

  Stale HNS endpoints caused traffic to route to wrong nodes when pod IPs were reused, producing silent DNS failures. This is hard to diagnose and easy to misattribute to DNS config. If you run Windows nodes with L2Bridge networking, treat this as a high-priority patch.

• enhancementkubeadm bootstrap is more resilient against slow load balancers

  Previously, kubeadm init could fail or behave unexpectedly when the control plane load balancer wasn't ready yet. The fix makes bootstrap use the local API endpoint first, then defer to the LB endpoint — a meaningful improvement for cloud environments where the LB provisions asynchronously. Worth upgrading before your next cluster init or upgrade cycle.

Kubernetes v1.35.5 is a focused patch release fixing scheduler state corruption, Windows networking, kube-proxy large-cluster behavior, and several kubeadm initialization issues.

• breakingKubeadm users: review kubeconfig generation behavior after upgrade

  The kubeadm init change to use localAPIEndpoint for admin.conf and super-admin.conf is a behavioral fix, but clusters with custom controlPlaneEndpoint setups should validate that kubeconfigs are generated correctly after upgrading. If you rely on the controlPlaneEndpoint in generated configs for post-init tooling, test in staging first.

• enhancementLarge clusters: upgrade kube-proxy to stop unnecessary full-syncs

  If you're running 1000+ endpoints, kube-proxy was previously triggering full-sync operations it shouldn't. This patch stops that. The fix directly reduces CPU and network overhead on busy clusters — upgrade kube-proxy as part of your next maintenance window.

• enhancementScheduler memory leak fix — prioritize this patch if you see scheduling instability

  The scheduler bug with in-flight state tracking could cause unbounded growth in memory usage when pods with reused names fail scheduling repeatedly. If you've observed scheduling delays or growing scheduler memory consumption, this patch addresses the root cause directly.

v1.34.8 is a focused bug-fix patch addressing IPv6 CIDR allocation errors, a scheduler memory leak, Windows DNS routing failures, and several kubeadm cluster lifecycle issues.

• securitykubeadm now uses a dedicated ClusterRole for kube-apiserver kubelet access

  The kube-apiserver's kubelet client is now bound to 'system:kubelet-api-admin' instead of a shared role. For kubeadm-managed clusters, re-running 'kubeadm init phase bootstrap-token' or upgrading via kubeadm will apply this change. Existing clusters upgraded in-place will get this tighter RBAC scoping automatically — verify with 'kubectl get clusterrolebinding' post-upgrade.

• breakingIPv6 clusters: audit ServiceCIDR allocations before upgrading

  The 64-bit IPv6 ServiceCIDR bug means some clusters may have services with IPs that technically fall outside the configured subnet. After upgrading to v1.34.8, check whether any existing service IPs are out-of-range and consider recreating affected services. This primarily impacts clusters using /64 IPv6 service CIDRs.

• enhancementLarge clusters: kube-proxy full-sync elimination reduces control plane pressure

  If you're running clusters with 1000+ endpoints, kube-proxy was performing expensive full-sync operations unnecessarily in large-cluster mode. This patch stops that. The benefit is lower CPU and latency spikes during endpoint churn. No config changes needed — upgrade and monitor kube-proxy CPU usage to confirm the improvement.

Flux v2.8.7 patches a CVE in go-git and fixes a destructive reconciliation bug where non-namespaced resources with ssa:IfNotPresent were being deleted and recreated every cycle.

• securityPatch CVE-2026-45022 by upgrading now

  go-git v5.19.0 fixes CVE-2026-45022, which affects source-controller and image-automation-controller — two components that actively clone and interact with Git repos. If your Flux installation pulls from any external or semi-trusted Git source, treat this as a priority upgrade. Run 'flux install' or update your Helm release to v2.8.7 immediately.

• breakingCheck non-namespaced resources using ssa:IfNotPresent for unintended churn

  If you're managing ClusterRoles, CRDs, or other cluster-scoped resources with the kustomize.toolkit.fluxcd.io/ssa: IfNotPresent annotation, those resources were being silently deleted and recreated on every reconciliation loop before this fix. Audit your Kustomization objects and verify resource state after upgrading to confirm the churn has stopped. Any dependent workloads may have experienced disruptions you weren't aware of.

• enhancementFollow the v2.7+ upgrade procedure if coming from v2.6

  The Flux team has a specific upgrade discussion thread for v2.7+ migrations. Skipping it when jumping from v2.6 to v2.8.7 can cause issues. Review the linked procedure before applying this update in environments running older Flux versions.

v0.152.0 fixes a silent Prometheus metric name regression when telemetry host is customized, changes AsString HTML-escaping behavior for map/slice values, and adds an in-flight exporter requests metric.

• breakingCheck Prometheus metric names if you customized telemetry host

  The Prometheus exporter boolean fields (WithoutScopeInfo, WithoutUnits, WithoutTypeSuffix) now default correctly when you explicitly set the telemetry host. Before this fix, those fields defaulted to false instead of true, so your metric names would silently change format. If you run a Collector with a custom telemetry host configured, verify your Prometheus metric names after upgrading — dashboards and alerts keyed on metric name format may need updating.

• breakingAsString output change for map/slice values — check downstream consumers

  pcommon.Value.AsString no longer HTML-escapes <, >, and & in map and slice values. If your pipeline or downstream consumers were relying on escaped output (e.g., &lt; or &gt;) from attribute maps or slices, the raw characters will now appear instead. Audit any log parsers, attribute processors, or exporters that inspect string representations of map/slice values.

• enhancementAdd otelcol_exporter_in_flight_requests to exporter dashboards

  A new UpDownCounter metric otelcol_exporter_in_flight_requests tracks concurrent export requests per exporter. Add it to your Collector dashboards to detect exporter worker pool saturation before it causes backpressure or dropped data. No config change needed — it emits automatically.

Harbor v2.14.4 is a patch release fixing session management bugs, scanner API issues, and DockerHub token auth, with Go 1.25.9 and dependency security bumps.

• securityUpgrade immediately for go-jose and OTel SDK dependency fixes

  The go-jose/go-jose and go.opentelemetry.io/otel/sdk packages were explicitly bumped in this release, which typically signals CVE remediation. If your Harbor instance handles sensitive registry credentials or is exposed to external traffic, this patch should be prioritized. Plan an upgrade from v2.14.3 to v2.14.4 — it's a patch release with no breaking changes, so the risk of upgrading is low.

• breakingSession behavior changes — test SSO and long-lived browser sessions before rollout

  Two session-related fixes land here: background polling no longer refreshes session TTL, and SessionRegenerate args/lifetime were corrected. If your users rely on the UI staying logged in while background tabs are open, their sessions will now expire as configured rather than being silently extended. Validate your session timeout settings in Harbor's config and communicate expected behavior changes to your users before upgrading in production.

• enhancementDockerHub replication broken? This patch fixes the token auth flow

  If you've been seeing replication failures from DockerHub registries (especially after DockerHub API changes), the fix to use the /v2/auth/token endpoint should resolve them. After upgrading, verify your DockerHub replication rules by triggering a manual sync and checking the replication job logs. Also retest any distribution instance edits that involve credentials — a separate fix addresses a bug where editing a distribution instance without credentials caused issues.

v1.12.4 is a security patch release fixing a DoS vulnerability in the webhook server plus two scheduler correctness bugs. Upgrade immediately if running v1.12.3 or earlier.

• securityPatch the webhook server OOM vulnerability now

  CVE-2026-44247 lets any pod with network access to the webhook endpoint kill the webhook server by sending an oversized HTTP body, taking down admission control for the entire cluster. The CVSS scope is 'Changed', meaning the blast radius extends beyond the attacking pod. Any workload that can reach the webhook service is a potential attacker. Upgrade to v1.12.4 immediately. If you cannot upgrade right now, restrict network access to the webhook endpoint using NetworkPolicy to limit which pods or namespaces can reach it.

• breakingMulti-queue preemption may have been silently producing wrong results

  The preemptorTasks overwrite bug means clusters using multi-queue preemption could have been making incorrect scheduling decisions — lower-priority jobs potentially not being preempted correctly, or QueueOrderFn being ignored entirely. After upgrading, review preemption behavior in your queues. If you have queue ordering policies configured, verify they're now being applied as expected and check whether any jobs were stuck or incorrectly scheduled before the upgrade.

• enhancementStartup race condition in the scheduler is resolved

  The event handler completion fix addresses a subtle race where the scheduler could begin making decisions before all event handlers were ready. This was most likely to surface during controller restarts or rolling upgrades. No action required beyond upgrading, but if you've seen intermittent scheduling failures shortly after Volcano restarts, this is likely the cause.

v1.13.3 patches a DoS vulnerability in the webhook server (CVE-2026-44247) plus four scheduler bug fixes. Upgrade immediately if running v1.13.2 or earlier.

• securityPatch CVE-2026-44247 immediately — all v1.13.x ≤ v1.13.2 are vulnerable

  Any pod with network access to the Volcano webhook endpoint can send an arbitrarily large HTTP body and OOM-kill the webhook server, blocking all admission for jobs and queues. CVSS 6.8 (Moderate) but the blast radius is high in multi-tenant clusters. Upgrade to v1.13.3 (or v1.12.4 / v1.14.2 depending on your branch). If you can't upgrade immediately, restrict network access to the webhook service via NetworkPolicy to limit who can reach port 443 on the webhook server.

• breakingMulti-queue preemption behavior changes — validate workloads after upgrade

  Two preemption fixes alter scheduling decisions: preemptorTasks no longer get overwritten across queues, and QueueOrderFn is now enforced during preemption. If you rely on specific preemption outcomes in multi-queue setups, run a staging environment validation after upgrading. Jobs that were previously preempting others may no longer do so, or vice versa, depending on your queue priority configuration.

• enhancementScheduler startup race eliminated — relevant for frequent restarts

  The fix ensuring event handlers complete before scheduling starts matters most in environments where the scheduler pod restarts frequently (e.g., OOM restarts, rolling updates). Previously, a narrow race window could cause the scheduler to miss events. No config change needed — just upgrade and monitor scheduler logs at startup for any anomalies.

v1.14.2 patches a denial-of-service CVE in the webhook server plus a dense cluster of scheduler correctness bugs — upgrade immediately if you're on any 1.12/1.13/1.14 branch.

• securityPatch CVE-2026-44247 now — all prior 1.12/1.13/1.14 versions are affected

  Any pod with network access to the Volcano webhook endpoint can send an arbitrarily large request body and OOM-kill the webhook server, blocking all workload admission. CVSS 6.8 (Moderate) but the blast radius is high — a downed webhook halts job submission cluster-wide. Upgrade to v1.14.2, v1.13.3, or v1.12.4 depending on your branch. If you cannot upgrade immediately, consider restricting network access to the webhook service via NetworkPolicy to limit which pods can reach the endpoint.

• breakingCheck for scheduler panic-on-install if you recently deployed 1.14.x

  A race condition caused the scheduler to panic and restart during initial install. If you observed unexplained scheduler CrashLoopBackOffs after a fresh 1.14.x deployment, this is the fix. Upgrade and verify the scheduler pod stabilizes. No config changes needed, but review your monitoring alerts — silent restarts in production may have caused missed scheduling cycles.

• enhancementMulti-queue preemption and queue ordering are now reliable — re-validate your preemption policies

  Two distinct bugs in multi-queue preemption (preemptorTasks overwrite and QueueOrderFn not being honored) are fixed. If you rely on preemption across queues with custom ordering functions, the scheduler was likely not behaving as configured. After upgrading, run a validation cycle against your preemption scenarios to confirm jobs are being preempted in the priority order you expect. No configuration changes are required, but the behavioral change is real.

Kubescape v4.0.8 is a focused patch release that fixes several VAP (Validating Admission Policy) bugs and adds a --timeout flag to the deploy-library command.

• breakingVAP label selector parsing was silently wrong — verify your policies

  The old code split label selectors on '=' directly instead of using Kubernetes' label parser. DoubleEquals (==) selectors were also incorrectly accepted. If you've generated VAP policies with Kubescape and used complex label selectors, re-generate and re-validate those policies with v4.0.8. Don't assume previously generated output was correct.

• enhancementUse --timeout with VAP deploy-library in slow clusters

  The new --timeout flag on the deploy-library command lets you tune how long Kubescape waits during VAP library deployment. If your cluster has slow API server response times or you're running in CI with strict time limits, set this explicitly rather than relying on the default. Test in staging first to find a safe value before enforcing it in pipelines.

• enhancementConnector URL back-propagation fix matters for cloud API setups

  A bug where connector URLs weren't back-propagated to the config object during cloud API initialization is now fixed. If you use Kubescape's cloud integration and noticed inconsistent scan result submissions, this patch addresses the root cause. Upgrade and re-run a scan to confirm results are reaching your backend correctly.

Kubescape v4.0.7 is a broad bug-fix and usability release: better input validation, safer concurrency in the HTTP handler, a new ControlInput CRD, and service discovery without a sidecar.

• breakingThreshold flags now fail fast — check your CI pipelines

  Severity-threshold, compliance-threshold, and fail-threshold flags are now validated before the scan starts. Scripts or CI jobs that pass invalid threshold values will now exit immediately with an error rather than completing the scan and ignoring the flag. Review your scan invocations to confirm all threshold flags are valid before upgrading.

• enhancementDrop the sidecar for service discovery

  Service discovery now queries the Kubernetes API directly. If you've been running a sidecar specifically to support Kubescape's service discovery, you can remove it. Audit your deployments before upgrading to avoid unexpected behavior from redundant sidecars.

• enhancementDeploy the ControlInput CRD for in-cluster tuning

  The new ControlInput CRD lets you configure control inputs directly in the cluster rather than through external files. This only activates during live cluster scans, so file-scan workflows are unaffected. Apply the CRD after upgrading if you want to centralize scan policy configuration in-cluster.

metal3-io v0.13.0 drops the iRMC driver, deprecates BMH firmware spec, and ships HostClaim CRDs plus multi-arch PXE boot — a release with real breaking changes that demand pre-upgrade review.

• breakingAudit iRMC usage and BMH.Spec.Firmware fields before upgrading

  The iRMC driver is gone — any BareMetalHost resources targeting iRMC BMC endpoints will stop reconciling after upgrade. Separately, BMH.Spec.Firmware is now deprecated; while it won't immediately break, you should plan migration to the replacement API. Scan your BMH manifests and Helm values for both before touching production.

• breakingVerify CAPI and controller-runtime compatibility in your management cluster

  The jump to CAPI v1.13.1 and controller-runtime v0.23.3 is not trivial. If you run other CAPI providers alongside metal3, check their compatibility matrices now. A version mismatch between providers sharing the same management cluster can cause subtle CRD conflicts or webhook failures at runtime.

• enhancementAdopt HostClaim CRDs for declarative bare-metal host allocation

  HostClaim and HostClaimSet resources give you a Kubernetes-native way to request and reserve bare-metal capacity without writing custom controllers. If you're currently managing host allocation through scripts or external tooling, evaluate whether HostClaim covers your use case — it's now feature-complete enough to replace simple reservation workflows.

wasmCloud v2.1.0 delivers operator reliability fixes, plugin support in services, and a wave of CI security hardening — a solid incremental release with a few operator-side changes worth watching.

• securityBump wasmtime and run cargo audit in your own builds

  wasmtime was bumped alongside the removal of rustls-pemfile and the addition of cargo audit to the build pipeline. If you build wasmCloud components from source or maintain forks, add cargo audit to your own CI now. The dependency surface for WASM runtimes shifts fast, and catching advisories early matters.

• breakingOperator readiness behavior changed — review your health checks

  The operator now only marks WorkloadDeployment as Ready when replicas are actually available. If your CI/CD pipelines or monitoring poll readiness status, they'll behave more correctly — but any tooling that relied on the previous optimistic Ready state may see deployments appear 'stuck' longer. Validate your rollout timeout thresholds after upgrading.

• enhancementPlugin support in services opens new extension patterns

  Services now support plugins, which means you can attach custom behavior at the service layer without forking core components. If you've been waiting to extend service behavior in a maintainable way, this is the release to experiment with. Start by reviewing the updated service plugin API in the docs before designing new integrations.

Vitess v24.0.1 is a focused patch release fixing a VTGate query planner bug with DML subqueries, reverting a problematic VTOrc flag, and resolving flaky VTTablet unit tests.

• breakingRemove VTOrc --cells-to-watch flag if you added it

  The 'cells to watch' flag introduced in #19354 has been reverted. If you added this flag to your VTOrc configuration or startup scripts after upgrading to v24.0.0, remove it before upgrading to v24.0.1 — VTOrc will fail to start with an unrecognized flag error.

• enhancementUpgrade if you use DML subqueries through VTGate

  A query planner bug affected IN/NOT IN subqueries inside DML statements (INSERT/UPDATE/DELETE). Merged subqueries weren't being substituted correctly via ListArg placeholders, which could produce wrong query behavior. If your application runs DML with subqueries routed through VTGate, this patch directly addresses that correctness issue — upgrade promptly.

v23.0.4 is a stability-focused patch release fixing multiple panics in VTOrc, VTGate, and ERS, plus critical VReplication and routing rule bugs that could silently misdirect traffic.

• securityGo upgraded to 1.25.9 — check your custom builds

  The Go runtime was bumped from 1.25.8 to 1.25.9 within this release cycle. If you build Vitess from source or maintain custom images, rebuild against go1.25.9 to pick up any runtime-level fixes included in that Go patch release.

• breakingUpgrade immediately if you use ERS or semi-sync replication

  Three separate ERS bugs were fixed: nil pointer panics during errant GTID detection, broken cancellation logic, and IO threads not restarting on replicas after ERS failure. Any of these can leave your cluster in a degraded state after a failover. If you run semi-sync with VTOrc, the ReplicationStopped + PrimarySemiSyncBlocked deadlock fix is equally critical — it could stall recovery entirely. Upgrade before your next planned maintenance window at the latest.

• enhancementRouting rule and schema-tracker fix affects multi-keyspace setups

  VTGate was not rebuilding routing rules after schema-tracker updates, and was dropping the target keyspace during routing rule AST rewrites. Both are silent bugs — queries appear to work but may land on the wrong keyspace. If you use routing rules with multiple keyspaces, validate query routing behavior after upgrading to confirm traffic is going where you expect.

v1.15.1 is a stability patch fixing two serious runtime bugs — a potential deadlock in Check and a semaphore leak under context cancellation — plus a cache collision in the experimental weighted graph check.

• securityCache key collision in `weighted_graph_check` could return incorrect authorization results

  If you're running the experimental `weighted_graph_check` feature, the cache collision bug means Check could return stale or wrong results for relationships in unions with direct types, wildcards, TTU paths, or intersections. This is an authorization correctness issue — wrong answers on permission checks. Upgrade before relying on this feature in any environment where correctness matters. If you can't upgrade immediately, disable the experimental feature flag.

• breakingUpgrade immediately — deadlock and semaphore leak bugs affect production stability

  Two bugs here can quietly degrade running services. The deadlock in Check (message streams held open on error) can starve request processing over time. The semaphore leak in the bounded tuple reader under context cancellation means goroutine/resource exhaustion under load or timeout-heavy workloads. Neither requires config changes — just upgrade. If you've seen unexplained Check hangs or increasing resource pressure after cancellations, these are the culprits.

• enhancementListObjects now handles short-circuit errors correctly

  A subtle bug was causing expected errors (non-fatal path short-circuits) to bubble up incorrectly in ListObjects responses. If you've seen unexpected errors returned from ListObjects queries that should have silently short-circuited, this fix resolves that. No action needed beyond upgrading — but worth re-validating ListObjects behavior in your test suite after the upgrade.

Argo CD 3.4.1 is the first 3.4 release (skipping 3.4.0), bringing a breaking cluster version format change for ApplicationSets, plus a large wave of bug fixes, performance improvements, and UI enhancements.

• securityAdd X-Frame-Options/CSP headers and JWT logout invalidation

  Two security fixes landed: Swagger UI endpoints now return X-Frame-Options and Content-Security-Policy headers (mitigates clickjacking), and JWT tokens are invalidated server-side on logout (prevents session reuse after logout). Both are passive — no config changes needed — but if you run Argo CD behind a reverse proxy that strips security headers, verify the headers reach clients after upgrading.

• breakingUpdate ApplicationSet cluster version labels before upgrading

  The kubernetes-version label format changed from Major.Minor (e.g., '1.29') to vMajor.Minor.Patch (e.g., 'v1.29.3') to match Helm 3.19.0. If you use ApplicationSet Cluster Generators with argocd.argoproj.io/auto-label-cluster-info, your existing cluster secrets carry the old format. After upgrading, update those secrets to use argocd.argoproj.io/kubernetes-version with the new format, or your cluster-version-based filters will stop matching. Check the 3.3-3.4 upgrade guide before rolling out.

• enhancementAppSet controller and repo-server performance improvements worth monitoring

  Several perf fixes shipped: optimized parentUIDToChildren data structure, reduced secret deep-copies in the controller, parallel batching in CLI server-side diff, and optimized repoLock on checkout. If you've been seeing slow reconciliation or high CPU in the appset controller on large clusters, this upgrade should show measurable improvement. Monitor controller CPU and reconciliation latency metrics after rollout.

OpenYurt v1.7.0 ships OTA image preheating for near-zero-downtime edge upgrades, label-driven YurtHub deployment, K8s-on-K8s support, and Kubernetes v1.34 compatibility — alongside removal of several deprecated components.

• breakingAudit usage of removed components before upgrading

  YurtAppOverrider, YurtAppDaemon (controller + webhook), yurt-coordinator, and the delegate lease controller are gone. If your workloads or Helm charts reference any of these, they will break silently or fail to deploy post-upgrade. Audit your manifests, Helm values, and any automation scripts before cutting over. The NodePool CRD also moves to v1beta2 — verify your tooling handles the new API version and the renamed field (enableLeaderElections replaces enablePoolScopeMetadata).

• enhancementAdopt OTA image preheating for edge DaemonSet upgrades

  If you manage DaemonSets on edge nodes with constrained or intermittent connectivity, the new ImagePreHeat controller is a practical fix for upgrade-induced downtime. Trigger preheating via the new OTA API endpoint before scheduling the rollout. Watch the PodImageReady condition to confirm images are cached before initiating the actual upgrade. This is especially valuable for large images or nodes behind slow WAN links.

• enhancementSwitch to label-driven YurtHub onboarding

  The new YurtNodeConversionController lets you onboard and offboard edge nodes by applying a label — no more running yurtadm join manually per node. This is a meaningful operational improvement if you manage fleets of edge nodes. Start testing this workflow in a non-production node pool first, since it interacts with systemd directly and the feature is new in this release.

CRI-O v1.36.0 ships CNI health monitoring, configurable GOMAXPROCS injection, TLS hardening options, and a CVE fix — alongside a batch of race condition and cgroupv2 bug fixes.

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

  The spdystream dependency carried CVE-2026-35469. If you're running v1.35.x, this is a direct reason to upgrade. After upgrading, verify the release bundle with cosign against the signed bundle artifacts — the SLSA provenance and OpenVEX report are both available for this release.

• breakingValidate CNI plugin behavior under new continuous health monitoring

  CRI-O now polls CNI plugins with STATUS after initial readiness. A plugin that was silently degraded will now actively set NetworkReady=false on the node, blocking pod scheduling. Before upgrading, confirm your CNI plugin properly implements the STATUS verb (Cilium, Calico, and Flannel do; older or custom plugins may not). Test in a non-production cluster first — this is a behavioral change that could surface latent CNI issues.

• enhancementSet TLS minimums for the CRI-O API — don't leave defaults in production

  New `tls_min_version` and `tls_cipher_suites` options under `[crio.api]` let you enforce TLS 1.2+ and restrict weak cipher suites on the streaming and metrics endpoints. The default is TLS 1.2, but you should explicitly set `tls_min_version = TLS13` in security-sensitive environments and review your cipher suite policy. Update your configuration management (Ansible, SaltStack, etc.) to codify this before the next node rollout.

A maintenance release focused on operator reliability, security hardening, and CI improvements. Key fixes address NATS workload readiness and Kubernetes operator deployment status accuracy.

• securityWasmtime bump + cargo audit added — review your own Wasm supply chain

  This release bumps wasmtime and drops rustls-pemfile, while adding cargo audit to CI. If you're building custom wasmCloud components or providers in Rust, add cargo audit to your own pipelines now. The removal of rustls-pemfile suggests a dependency consolidation — check if any of your code directly imports it and update accordingly.

• breakingOperator WorkloadDeployment readiness semantics changed

  The Ready condition on WorkloadDeployment now reflects actual replica availability rather than just the existence of the deployment. Any automation or health checks that relied on Ready=True firing quickly after deployment creation will now correctly wait for replicas to be up. Review any CD pipelines or readiness probes that poll WorkloadDeployment status — they should now behave more accurately, but may appear 'slower' to reach Ready.

• enhancementNATS subscription readiness fix reduces false-positive healthy states

  Previously, hosts could report as ready before NATS subscriptions were actually established. After this fix, readiness is tied to actual subscription availability. If you're running wasmCloud in Kubernetes and using readiness gates or traffic routing based on host health, upgrade to get accurate readiness signals and avoid routing traffic to hosts that aren't yet fully connected.

Longhorn v1.11.2 is a stability-focused patch fixing CSI scheduling breakage in compute/storage split architectures, infinite replica scheduling loops, and memory bloat in longhorn-manager.

• breakingFix CSI scheduling in compute/storage split clusters — action required

  If you run a dedicated compute/storage node architecture and use WaitForFirstConsumer PVCs, your pods may have been stuck pending due to compute nodes reporting 0 CSI capacity. Upgrade to v1.11.2 and configure the new CSIStorageCapacity setting to prevent capacity reporting on non-storage nodes. Check your Longhorn settings after upgrade and validate that pending PVCs now schedule correctly.

• breakingReplica Auto-Balance infinite loop — upgrade if you use Auto-Balance

  A bug caused Replica Auto-Balance to enter an infinite scheduling loop, which wastes CPU and can destabilize volume operations. If Auto-Balance is enabled in your cluster, this is a strong reason to prioritize this patch. No config change needed after upgrade — the fix is in the reconciliation logic.

• enhancementMemory savings in longhorn-manager — relevant for large clusters

  Informer caching for longhorn-manager has been optimized to reduce cluster-wide memory consumption. In large clusters with many nodes and volumes, this can meaningfully reduce the manager pod's footprint. No action required beyond upgrading, but worth monitoring memory usage before and after to quantify the improvement in your environment.

v1.35.3 patches CVE-2026-35469, fixes a container stop panic and exit-code race, adds CNI health monitoring (then reverts it), and introduces GOMAXPROCS floor injection for containers.

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

  The spdystream dependency had a vulnerability (CVE-2026-35469) fixed by bumping to moby/spdystream v0.5.1. If you're running v1.35.x, upgrade to v1.35.3 now. There's no workaround — the fix is only in the updated binary.

• breakingCNI health monitoring was added and then reverted in the same release

  CRI-O briefly added continuous CNI plugin health checks using the STATUS verb, which would have marked nodes NetworkReady=false on plugin failures. It was reverted before this release shipped because it caused bootstrapping regressions. Net result: no behavior change for CNI in v1.35.3. But if you saw this feature in changelogs and planned for it, don't — it's gone and will likely return in a future release with fixes.

• enhancementUse 'min_injected_gomaxprocs' to prevent CPU underutilization in containers with low CPU requests

  Containers with very low cpu.request values can end up with GOMAXPROCS=1, throttling Go-based workloads. The new 'min_injected_gomaxprocs' config field sets a floor so CRI-O injects max(floor, cpu.request) as GOMAXPROCS. This is particularly useful for Go-based sidecars or agents that are request-constrained but need threading headroom. Set this in your CRI-O config if you run Go workloads with conservative CPU requests.

in-toto v3.1.0 migrates away from sslib's hash functions, switches to ruff for code style, and refreshes Debian packaging — mostly maintenance, but the sslib change has dependency implications.

• breakingAudit your sslib dependency if you use it alongside in-toto

  in-toto has internalized sslib's hash functions because sslib is being deprecated. If your project independently depends on sslib for other functionality, start planning a migration now — don't assume sslib will remain maintained. Check your dependency tree for anything that transitively pulls in sslib and evaluate whether those paths need updating.

• enhancementUse the new `in-toto-run` return code passthrough in CI pipelines

  Previously, `in-toto-run` would swallow the wrapped command's exit code, which could mask failures in CI. With passthrough now enabled, the return code of the wrapped command propagates correctly. If you have shell scripts or CI steps that check exit codes after `in-toto-run`, verify your error handling still works as intended — behavior has changed and some pipelines may now surface previously hidden failures.

• enhancementIf you contribute to or package in-toto, update your dev tooling to ruff

  The codebase now enforces ruff-based style rules. If you maintain a fork, downstream package, or contribute PRs, your existing flake8/pylint setup will likely flag false conflicts. Align your local dev environment with ruff before opening PRs against this version or later.

v4.0.6 tackles a wave of false negatives, silent errors, and correctness bugs in scanning — namespace filters, exception matching, and OPA eval failures all get fixes that change scan results.

• securityAudit vulnerability exception lists for case inconsistencies

  Exception matching for image scan CVE IDs was case-sensitive before this fix, meaning 'ghsa-xxxx' and 'GHSA-xxxx' were treated as different identifiers. Any exceptions defined with lowercase CVE/GHSA IDs were silently not applied. After upgrading, check that your exception lists use consistent casing and re-verify which vulnerabilities are actually being excepted.

• securityRaw request bodies are no longer logged — review your log retention

  Kubescape's HTTP handler was logging full scan request bodies, which could include sensitive resource manifests or configuration data. That logging is now removed. If you've been collecting these logs, review and rotate any stored log data that may contain manifest content.

• breakingExpect scan result changes after upgrading — false negatives are now real failures

  Two distinct bugs caused resources to silently disappear from scan results: OPA eval errors were swallowed, and partial GVR collection failures were suppressed. Both are fixed. If your baseline compliance scores looked suspiciously clean, re-run scans after upgrading and treat new failures as real findings that were always there, not regressions introduced by the upgrade.

A maintenance release focused on operator reliability, NATS subscription readiness, and security dependency bumps — no API changes, but a few fixes matter in production.

• securityUpgrade to pick up wasmtime security bump and new audit pipeline

  wasmtime was bumped and rustls-pemfile was removed as a dependency in this release. cargo audit has also been wired into CI, meaning future vulnerabilities in the dependency tree will be caught earlier. If you're running 2.0.5 or earlier, upgrade now — there's no reason to stay on an older wasmtime in a Wasm runtime.

• breakingOperator readiness behavior changed — review your health checks and rollout strategies

  WorkloadDeployment Ready status is now gated on replica availability, not just the existence of a deployment object. If your CI/CD pipelines or monitoring systems check for the Ready condition to gate traffic or proceed with rollouts, they'll now see a more accurate (and potentially longer) 'not ready' window. Verify your rollout wait conditions and alerting thresholds won't false-alarm during normal startup.

• enhancementNATS subscription readiness fix — relevant if you've seen premature ready signals

  The fix for NATS subscription workload readiness means the host now correctly waits before reporting ready. If you've dealt with race conditions at startup where components tried to subscribe before NATS connections were fully established, this should resolve those. No config changes needed — just upgrade and validate your startup sequence behaves as expected.

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

• breakingRead the upgrade guide before patching

  The release explicitly warns of potential breaking changes in the 3.6 upgrade path. Don't treat this as a routine patch drop — pull the CHANGELOG-3.6.md and the upgrade guide, diff against your current version, and validate in a non-prod cluster first.

• enhancementVerify container registry source in your pipelines

  etcd's primary registry is gcr.io, not Docker Hub or quay.io. If your CI/CD or Kubernetes manifests still pin quay.io/coreos/etcd, you're on the secondary mirror which may lag. Update image references to gcr.io/etcd-development/etcd to stay on the canonical source.

etcd v3.5.30 is a maintenance release in the 3.5 series. No release notes were published beyond pointers to the full changelog — check the CHANGELOG-3.5.md directly for specifics.

• breakingRead the full CHANGELOG before upgrading

  The release announcement is intentionally sparse — it just points to CHANGELOG-3.5.md. Before upgrading any etcd cluster, pull up that changelog directly and review every entry since your current version. etcd upgrades in production clusters carry real risk; skipping the changelog review is how you get surprised by behavior changes or data format shifts.

• enhancementStick to gcr.io as your primary image source

  The release explicitly lists gcr.io/etcd-development/etcd as primary and quay.io/coreos/etcd as secondary. If your deployment pipelines or air-gapped mirrors are still defaulting to quay.io, consider updating them to match the project's own priority — gcr.io tends to get images published first.

etcd v3.4.44 is a maintenance release on the 3.4 branch. Release notes are sparse — check the full CHANGELOG for the actual fix list before upgrading.

• breakingReview CHANGELOG before upgrading — release notes are empty

  The published release notes contain no change summary. Before upgrading any production cluster, pull up CHANGELOG-3.4.md directly and diff against your current version. Skipping this step on a Kubernetes control plane means you could hit an undocumented behavioral change mid-upgrade.

• enhancementStill on 3.4? Evaluate migration to 3.5

  3.4.x receives only critical fixes at this point. If you're running etcd as a Kubernetes backing store, now is a good time to plan a move to 3.5, which has a longer active support runway. Check Kubernetes version compatibility before scheduling the upgrade.