リリース

26.5.7 is a critical security release patching 7 CVEs, including privilege escalation, redirect URI bypass, and unauthorized cross-user permission grants. Upgrade immediately.

• securityPatch now — multiple high-severity CVEs in this release

  Seven CVEs are fixed here, spanning privilege escalation (CVE-2026-4282), redirect URI bypass (CVE-2026-3872), cross-user permission injection (CVE-2026-4636), and an unauthenticated DoS via scope processing (CVE-2026-4634). These aren't theoretical — attackers with basic access or even anonymous access could exploit several of these. Upgrade to 26.5.7 as fast as your change process allows. If you use UMA policies or expose the Admin REST API, treat this as an emergency patch.

• securityAudit Admin REST API access and UMA policy configurations post-upgrade

  CVE-2025-14083 (Admin API info disclosure) and CVE-2026-4636 (UMA cross-user permission grants) suggest that access controls around admin and UMA endpoints were not properly enforced. After upgrading, review which clients and service accounts have Admin REST API access, and audit your UMA resource/policy definitions for unexpected grants. Don't assume the patch alone closes the exposure if misconfigured principals already exploited these paths.

• enhancementQuarkus upgraded to 3.27.3 — monitor for runtime behavior changes

  The Quarkus runtime bump also pulls in a fix for CVE-2026-1002 (vertx-core static handler cache manipulation causing DoS on static files). If you serve static content through Keycloak or have customized themes, verify those assets load correctly after upgrade. Quarkus minor upgrades occasionally shift default configurations, so a smoke test on your login flows is worth running.

etcd v3.5.29 is a maintenance release on the 3.5 branch with no detailed changelog published in the release notes themselves.

• securityVerify container image source after upgrade

  If you pull etcd images in CI/CD pipelines, confirm you're pointing to gcr.io/etcd-development/etcd as the primary registry. The quay.io mirror is secondary and may lag. Pin to the exact digest rather than the floating tag to avoid supply chain risk.

• breakingReview the official upgrade guide even for patch releases

  The release explicitly calls out that breaking changes may exist even in 3.5.x patch versions. Don't skip the upgrade guide. Test in a staging environment first, especially if you're running etcd as the backing store for Kubernetes — a botched etcd upgrade can take down your entire control plane.

• enhancementCheck CHANGELOG-3.5.md before upgrading

  The release notes here are skeletal — no specific fixes or changes are listed. Before upgrading any etcd cluster, pull up CHANGELOG-3.5.md on the etcd GitHub repo and filter for v3.5.29 entries. Patch releases on 3.5 typically carry bug fixes and CVE patches that aren't always obvious from the version bump alone.

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

• securityCertificate rotation was silently broken — rotate certificates after upgrading

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

• breakingEviction race condition could leave workloads stranded on failing clusters

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

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

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

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

• securityAudit agent certificates for expiry before upgrading

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

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

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

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

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

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

• securityUpdate UI immediately to fix XSS vulnerability

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

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

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

• enhancementSide panel span view reduces trace analysis friction

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

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

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

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

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

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

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

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

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

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

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

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

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

• enhancementGPU resource fix prevents ghost allocations on GPU nodes

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

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

• securitygRPC bump is cosmetic — but clear your scanner alerts

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

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

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

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

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

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

• securityApply this release for CVE fixes in dependencies and Python

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

• breakingAudit all five breaking changes before upgrading

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

• enhancementUse the new multiarch images for ARM64 clusters

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

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

• securityUpgrade immediately for two active CVEs

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

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

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

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

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

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

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

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

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

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

• enhancementAdopt Private Key Offload for secrets-safe TLS

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

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

• securityGo 1.25.8 security patches — rebuild or upgrade

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

• breakingUpgrade immediately if running Scheduler in HA mode

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

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

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

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

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

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

• breakingCheck for spurious sync operations before and after upgrade

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

• enhancementRollingSync UI fix improves progressive delivery visibility

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

Patch release fixing a gRPC CVE and a UI bug in RollingSync. Low operational risk, but the security fix warrants prompt upgrade.

• securityUpgrade now to mitigate CVE-2026-33186 in grpc-go

  CVE-2026-33186 affects the grpc-go library used by Argo CD's internal and external gRPC communication. The fix is a mitigation backport to the 3.1 branch. Any Argo CD 3.1.x instance prior to 3.1.13 is exposed. Upgrade to 3.1.13 promptly — this should be treated as a priority patch, not a routine update. After upgrading, verify image signatures with cosign against the published provenance if your supply chain policy requires it.

• securitylodash bumped to 4.17.23 — check if your own apps pin this version

  The lodash bump in the UI bundle closes known issues in 4.17.21/4.17.22. If your team also pins lodash in application code or CI pipelines referencing Argo CD's frontend assets, audit those pinned versions independently. This change only covers the Argo CD UI bundle itself.

• enhancementRollingSync UI fix helps diagnose misconfigured sync waves

  If you use ApplicationSets with RollingSync and label-based step matching, the previous UI would silently hide steps that matched no labels — making it hard to spot misconfigured rollout waves. The fix surfaces these unmatched steps visibly. After upgrading, review any RollingSync-heavy ApplicationSets to confirm step labels are actually matching the intended clusters or apps.

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

• securityUpgrade now — this release exists specifically to fix CVEs

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

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

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

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

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

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

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

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

• breakingEncrypted OSD users should test key rotation after upgrading

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

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

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

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

• securityUpgrade immediately — 11 CVEs patched across core subsystems

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

• breaking1MB JWT size limit is now enforced

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

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

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

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

• securityUpgrade now — 11 CVEs, multiple remote attack surfaces

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

• breakingMQTT client ID restrictions may break existing clients

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

• enhancementTrace logging and monitoring endpoints now redact secrets

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

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

• securityUpgrade to get the Envoy security fixes

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

• breakingCheck custom manifests for the removed hostPort: 8002

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

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

• securityUpgrade for the Envoy security fixes

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

• breakingCheck custom manifests that reference Envoy hostPort 8002

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

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

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

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

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

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

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

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

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

• securityUpgrade to stop resolver panics from taking down the server

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

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

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

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

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

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

• securityPatch the world-accessible Envoy admin socket immediately

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

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

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

• breakingL7 LB ingress policy bypass — check your enforcement posture

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

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

• securityPatch the world-accessible Envoy admin socket immediately

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

• breakingGKE users: do not deploy v1.18.8

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

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

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

Cilium v1.17.14 patches a security issue with Envoy's admin socket permissions and two L7 load balancer policy bypass bugs — upgrade if you use L7 LB or Envoy.

• securityPatch the world-accessible Envoy admin socket immediately

  The Envoy admin socket was being created with world-accessible permissions, meaning any process on the node could potentially interact with it. This is a local privilege escalation risk in multi-tenant or shared node environments. Upgrade to v1.17.14 now — there's no workaround short of restricting filesystem access externally. Check if your nodes have been running older versions and audit whether the socket was exploitable in your threat model.

• securityL7 LB was allowing ingress policy bypass for local backends — fix before trusting policy enforcement

  Ingress policies were not being enforced for local backends when L7 load balancing was active. If you rely on network policy to restrict east-west traffic through L7 LB, your policies may not have been effective. After upgrading, verify your ingress policies are behaving as expected, particularly for services with local endpoint backends.

• enhancementBPF filesystem now included in bugtool — use it for faster incident diagnosis

  The bugtool now captures 'find /sys/fs/bpf' output, which is often the first thing you need when diagnosing BPF map or program issues. No action required, but update your runbooks to note that bugtool output from v1.17.14+ will include this data by default, saving manual SSH steps during incidents.

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

• securityPatch RUSTSEC-2026-0007 by upgrading immediately

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

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

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

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

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

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

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

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

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

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

• enhancementCap proxy cache upstream connections to protect upstream registries

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

A routine dependency-heavy edge release: two proxy bumps (v2.343.0, v2.344.0), Go 1.25.8 upgrade, rustls update, and proxy-init 2.4.6 — no feature additions or breaking changes.

• securityrustls patch update — pull this into your proxy builds

  rustls went from 0.23.35 to 0.23.37 in the proxy. Two patch versions in one release suggests active bug or security fixes in the TLS layer. If you're running older edge releases, this is a good reason to roll forward. No CVE was cited, but TLS library patches should never be delayed in a service mesh context.

• enhancementTwo proxy versions landed — check the proxy changelog separately

  This release ships proxy v2.343.0 and v2.344.0 in sequence, meaning two rounds of proxy changes are bundled in. The release notes don't detail what changed in each proxy version. If you're tracking proxy behavior closely (routing, observability, protocol detection), check the linkerd2-proxy repo's changelog for these two versions before deploying.

• enhancementGo 1.25.8 in the control plane — standard maintenance upgrade

  The control plane is now on Go 1.25.8. This is a patch release of Go and likely includes minor runtime fixes. No action required unless you're building custom tooling against Linkerd's Go modules — in that case, align your toolchain accordingly.

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

• securityUpgrade immediately to patch three Go stdlib CVEs

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

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

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

• enhancementLarge actor deployments and streaming workloads should prioritize this patch

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

Patch release bumping grpc from 1.78.0 to 1.79.3 and updating the Ansible operator plugin. Minimal surface area — safe to adopt quickly.

• securityUpgrade for gRPC dependency fix

  The grpc bump from 1.78.0 to 1.79.3 spans two minor versions and likely includes bug fixes that could affect stability or security of operator-to-registry communication. gRPC CVEs and transport-layer issues have historically been silent but impactful. Review the grpc changelog for your risk profile, then upgrade — this patch is low-risk and the dependency delta is well-contained.

• enhancementAnsible plugin users should rebuild operator images

  If you maintain Ansible-based operators, the plugin update in this release means your scaffolded or generated code may drift from the current baseline. After upgrading the SDK, re-run scaffolding checks or regenerate any plugin-managed files to stay aligned. Not urgent, but worth doing before your next operator release cycle.

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

• securityPatch all 8 CVEs — upgrade to 26.5.6 now

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

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

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

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

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

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

• securityUpgrade immediately to fix TLS session ticket bypass

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

• securitySelector data no longer leaks into agent logs

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

• breakingPQC users must migrate from Kyber draft to X25519MLKEM768

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

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

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

Kubescape v4.0.3 is a small patch release adding a --grype-db-url flag for offline/airgapped Grype database usage, plus a bug fix for missing host errors and dependency bumps.

• securitygo-git updated to v5.16.5 — pull this upgrade promptly

  go-git patch releases frequently address vulnerabilities in git protocol parsing. Review the go-git v5.16.5 changelog to confirm whether any CVEs are addressed, and prioritize this upgrade if your Kubescape usage involves scanning git repositories or if you embed Kubescape as a library.

• breakingMissing host now returns an error — check your error handling

  Previously, a missing host in scan targets silently returned nil instead of an error. If your pipelines or scripts were treating a zero-exit-code as success in these cases, they may now surface failures they were previously ignoring. Test your scan workflows after upgrading to make sure error handling behaves as expected.

• enhancementUse --grype-db-url for airgapped or private mirror setups

  If you run Kubescape in environments without direct internet access, the new --grype-db-url flag lets you point image scans at an internal Grype DB mirror. Set this in your CI pipelines or operator configs now rather than patching environment variables or workarounds you may have hacked together previously.

KubeVirt v1.6.4 is a patch release with 108 changes targeting stability: a CVE fix in crypto, several hotplug/migration bugs squashed, and new vCPU queue alerting.

• securityPatch CVE-2025-47913 — upgrade to v1.6.4 now

  CVE-2025-47913 affects the golang/x/crypto dependency. This release pins it to OpenShift's patched fork. If you're running any v1.6.x release before v1.6.4, you're exposed. Upgrade immediately — no workaround exists short of patching the binary yourself.

• breakingCross-vendor live migrations are now blocked

  KubeVirt will now explicitly prevent live migrations between nodes with different CPU vendors (e.g., Intel to AMD). If your cluster has mixed CPU vendors and you've been relying on cross-vendor migration — intentionally or not — audit your node topology before upgrading. Migrations that previously succeeded may now fail with an error.

• enhancementAdd vCPU queue alerts to your monitoring setup

  Two new alerts ship in this release: GuestPeakVCPUQueueHighWarning and GuestPeakVCPUQueueHighCritical. If you're running KubeVirt with Prometheus, check that these alerts are picked up by your alerting rules. They give you early warning on guest CPU starvation, which is otherwise invisible until VMs start misbehaving under load.

Argo CD 3.3.4 delivers critical bug fixes for token refresh handling and git-lfs support, plus enhanced security documentation - a maintenance release that improves operational stability.

• securityVerify signed release assets

  All container images now include cosign signatures and SLSA Level 3 provenance. Use the official verification documentation to validate your container images before deployment, particularly in security-sensitive environments.

• breakingReview token refresh configurations

  The token refresh fix resolves parsing errors that could affect component behavior. Check your existing token configurations and monitor for any authentication issues after upgrading, especially in multi-component setups.

• enhancementUpgrade for ppc64le architecture support

  If running on ppc64le systems, this release fixes git-lfs functionality that was previously broken due to missing checksums. Plan your upgrade to restore full git-lfs capabilities on these architectures.

v0.17.0 delivers substantial LLM-focused improvements with the new LLMInferenceService beta, enhanced storage parallelization, vLLM 0.15.1 upgrade, and important CVE fixes affecting production deployments.

• securityApply critical CVE patches immediately

  This release addresses several high-impact CVEs including path traversal (storage-initializer), HTTP parser vulnerabilities (h11, starlette), and cryptography subgroup attacks. Update to v0.17.0 promptly, especially if you're using storage-initializer or external model downloads. Review your current CVE scanning results against the patched versions.

• breakingPlan LLMInferenceService migration path

  The new LLMInferenceService CRD introduces a dedicated API for LLM workloads with different semantics than standard InferenceService. If you're running LLM models, evaluate migrating to this new resource type for better autoscaling, routing, and operational features. The CRD includes breaking changes in API structure.

• enhancementLeverage parallel storage downloads for faster deployments

  Storage-initializer now downloads blobs in parallel from S3 and Azure, dramatically reducing model loading times for large models. This is particularly beneficial for LLM workloads. No configuration changes needed - the improvement is automatic upon upgrade.

OpenFGA v1.12.0 improves operational reliability with automatic TLS certificate rotation, enhanced input validation, and critical race condition fixes.

• securityUpgrade for Go stdlib vulnerability fixes

  This release addresses two Go standard library vulnerabilities (GO-2026-4603 and GO-2026-4601). Plan your upgrade to eliminate these security risks in production deployments.

• enhancementConfigure gRPC message size limits

  Review your current message sizes and set appropriate limits using the new configuration option to prevent resource exhaustion attacks and improve system stability.

• enhancementBenefit from automatic certificate rotation

  If you're using cert-manager or similar certificate rotation tools, this release eliminates connection failures during certificate updates. Test your certificate rotation process after upgrading to verify the improvement.

Longhorn v1.11.1 delivers critical bug fixes including a major memory leak in instance manager pods and backup failures with S3-compatible storage, making it an urgent upgrade for v1.11.0 users.

• securityBackup restore functionality compromised

  S3-compatible backup targets (Storj, GCS) were failing due to AWS SDK v2 authorization issues. Test your backup and restore workflows after upgrading, especially if using non-AWS S3 endpoints. Verify large backup transfers complete successfully.

• breakingUrgent upgrade required for v1.11.0 users

  Users running v1.11.0 experiencing high memory usage in instance manager pods must upgrade immediately. The memory leak can cause cluster instability and pod evictions. Plan upgrade maintenance window and monitor memory usage during rollout.

• enhancementImproved scheduling with topology awareness

  New CSI topology-aware nodeAffinity controls provide better volume placement. Review your storage class configurations to leverage allowedTopologies and strictTopology settings for multi-zone deployments and specific node scheduling requirements.

Strimzi 0.45.2 is the final patch release for the 0.45.x branch, focusing on critical CVE fixes and Kafka 3.9.2 support while serving as the last version supporting ZooKeeper-based clusters.

• securityApply patch immediately for CVE fixes

  This release addresses multiple high-priority CVEs in ZooKeeper, JWT libraries, and networking components. Upgrade to 0.45.2 immediately to patch these vulnerabilities, especially if you handle sensitive data or run internet-facing services.

• breakingMigrate to KRaft before upgrading beyond 0.45.x

  This is your last chance to run ZooKeeper-based Kafka clusters in Strimzi. Plan your KRaft migration now since Strimzi 0.46+ will only support KRaft mode. Follow the official KRaft migration guide and test thoroughly in non-production first.

• breakingHandle Kafka 3.9.2 annotation issue for future upgrades

  If you're using Kafka 3.9.2, upgrading to Strimzi 0.46-0.51 will require manually updating pod annotations. Save the provided kubectl command for when you upgrade: it updates the Kafka version annotation on pods to prevent operator failures.

Flux v2.8.2 delivers critical fixes for reconciliation loops, Azure Container Registry authentication, and includes a security patch for CVE-2026-27138. The release focuses on operational stability improvements.

• securityApply CVE-2026-27138 patch immediately

  This release fixes a potential Denial of Service vulnerability during TLS handshakes. Schedule your upgrade to v2.8.2 as soon as possible, especially if your Flux installation handles external TLS connections or operates in environments with security compliance requirements.

• enhancementEnable DefaultToRetryOnFailure for better HelmRelease reliability

  If you use CancelHealthCheckOnNewRevision and have experienced stuck HelmReleases, enable the new DefaultToRetryOnFailure feature gate. This prevents canceled releases without retry strategies from hanging indefinitely, improving deployment reliability.

• enhancementVerify Azure Container Registry authentication after upgrade

  The ACR authentication scope fix may resolve intermittent authentication failures you've experienced with Azure registries. After upgrading, monitor your image pulls and source operations to confirm improved reliability with ACR repositories.