リリース

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

Flux v2.8.5 patches a cache race condition that could freeze Kustomizations, fixes Azure Blob prefix handling, and adds GCR Receiver verification fields.

• breakingStuck Kustomizations? This patch likely fixes you

  If you've seen Kustomizations get stuck after a reconciliation timeout or cancellation — often requiring a manual flux reconcile or pod restart to unblock — the race condition fix in kustomize-controller v1.8.3 directly addresses this. Upgrade to v2.8.5 and monitor your reconciliation loops post-upgrade. No config changes needed, but watch for Kustomizations that were previously stuck to automatically recover.

• breakingVerify Azure Blob prefix filtering actually works after upgrade

  If you're using Bucket sources backed by Azure Blob Storage with a prefix configured, that prefix was not being applied — meaning your source-controller was fetching more objects than intended. After upgrading to v2.8.5, the prefix filter will now take effect. Validate that your expected subset of blobs is still being synced correctly and that no previously-ignored paths break your deployments.

• enhancementTighten GCR webhook security with email and audience verification

  The GCR Receiver now accepts optional 'email' and 'audience' fields. If you're using GCR image push webhooks to trigger Flux reconciliation, add these fields to your Receiver spec to validate the service account identity and token audience — reducing the risk of forged webhook requests. This is opt-in, so existing setups won't break, but teams with strict security postures should configure it.

Prometheus v3.11.1 was released, but the published notes are too brief to summarize. See the original release notes for details.

Flux v2.8.4 is a CLI-only patch fixing two bugs: Windows compatibility for 'flux build/diff ks' and source flag validation in 'create kustomization'.

• breakingCheck your 'create kustomization' scripts for invalid --source values

  The '--source' flag now validates input properly. Scripts or pipelines passing malformed source references that previously slipped through will now fail explicitly. Test your automation before rolling out the updated CLI in CI/CD pipelines.

• enhancementWindows users: upgrade to unblock 'flux build/diff ks'

  If your team uses Windows workstations or CI runners for Flux kustomization diffs, these commands were silently broken. Upgrade the CLI to v2.8.4 — the fix is CLI-side only, so no cluster-side changes are needed.

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

Istio 1.27.9 was released, but the published notes are too brief to summarize. See the original release notes for details.

v1.14.0 fixes a potential deadlock in ListObjects, improves intersection algorithm performance, and adds BatchCheck caching — plus a SQL serialization bug fix that affects PostgreSQL users.

• securityPostgreSQL users: apply the SQL serialization fix

  The TupleOperation serialization and pgx.ErrNoRows fixes could cause silent data inconsistencies or incorrect error handling in PostgreSQL deployments. If you're running OpenFGA on Postgres, this fix alone justifies upgrading. Verify your tuple write/read behavior post-upgrade.

• breakingReview CVE-2026-33729 and upgrade immediately

  The changelog explicitly references CVE-2026-33729. The release notes don't detail the full scope, but a CVE update in a patch/minor release demands immediate attention. Upgrade to v1.14.0 now and audit your deployment's exposure before the CVE details become widely known.

• enhancementListObjects deadlock fix is critical for high-concurrency workloads

  A deadlock in the ListObjects pipeline is the kind of bug that only shows up under real production load. If you use ListObjects extensively — especially with concurrent callers — this fix is essential. After upgrading, stress-test ListObjects under your typical concurrency patterns to confirm stability.

• enhancementBatchCheck caching reduces authorization latency at scale

  If your application calls BatchCheck repeatedly with overlapping tuples or conditions, the new caching layer will cut latency and backend load. No configuration changes are mentioned, so the benefit should be automatic — but monitor cache behavior through the new tuple iterator query stats to validate the improvement in your environment.

Lima v2.1.1 is a focused patch release adding Windows binary artifacts and fixing a handful of edge-case bugs, with an important bundled nerdctl security update.

• securityUpdate nerdctl distribution for BuildKit and CNI security fixes

  The bundled nerdctl was bumped from v2.2.1 to v2.2.2, which updates BuildKit to 0.28.1 and CNI plugins to 1.9.1. Both upstream releases include security patches. If you use Lima's nerdctl template for container workloads, upgrade to v2.1.1 promptly and check the BuildKit and CNI plugin release notes to assess CVE impact for your environment.

• enhancementWindows users can now consume official Lima binaries

  Lima v2.1.1 ships pre-built Windows artifacts for the first time. If your team has Windows developers using Lima (e.g., via WSL2), point them at the official release binaries rather than maintaining custom builds. This simplifies onboarding and keeps everyone on a verified, reproducible build.

• enhancementFix UID range issues for enterprise/LDAP-managed macOS users

  macOS guests now accept UIDs outside the conventional range. If any users in your org run Lima on corporate-managed Macs with directory-assigned UIDs (common with LDAP or Active Directory integration), this fixes silent failures that were hard to diagnose. No config change needed — just upgrade.

Mostly a dependency maintenance release with two proxy bumps (v2.346.0, v2.347.0), a multicluster RBAC fix, and a Prometheus config correction for viz admin port names.

• securityCrypto dependency updates — low urgency but keep your upgrade cadence

  openssl, rustls-webpki, aws-lc-rs, and aws-lc-sys all received patch bumps this cycle. None carry disclosed CVEs, but these are core cryptographic libraries in the proxy. Stay on a regular edge upgrade cadence rather than skipping multiple releases, so these patches don't accumulate.

• breakingCheck Prometheus metrics after upgrading if you use Linkerd Viz

  The Prometheus config was corrected to match new admin port names. If you're running Linkerd Viz and upgraded from an earlier edge build, verify your dashboards still show expected metrics after the upgrade. Gaps in scraping could have silently existed before this fix — cross-check your Prometheus targets to confirm scrape health.

• enhancementMulticluster users: review Server/AuthorizationPolicy coverage

  Missing Server and AuthorizationPolicy resources were added for the multicluster extension. If you use Linkerd multicluster, upgrade and audit your cross-cluster authorization posture. The previous gap meant some traffic paths lacked proper policy objects, which could have caused unexpected allow/deny behavior depending on your default policy.

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.

Prometheus v3.11.0 ships significant new discovery capabilities, TSDB experimental features, and a critical retention bug fix that could cause data to be kept 1,000,000x longer than configured.

• breakingFix TSDB retention unit bug before your disk fills up

  A unit mismatch in the config file parser caused `storage.tsdb.retention.time` to be interpreted as 1,000,000x the intended value. If you set retention via the config file (not CLI flags), your TSDB may be holding far more data than expected. Upgrade to 3.11.0 immediately and verify disk usage post-upgrade. Also note: CLI flag values are now the fallback when retention is removed from config, so review your configuration carefully.

• breakingMigrate Hetzner hcloud SD label references before July 2026

  `__meta_hetzner_datacenter` and `__meta_hetzner_hcloud_datacenter_location*` labels are deprecated for hcloud roles and will stop working after July 1, 2026. Audit all relabeling configs and recording rules that reference these labels. Replace with `__meta_hetzner_hcloud_location` and `__meta_hetzner_hcloud_location_network_zone`. The robot role keeps the old label for backward compatibility.

• enhancementCap TSDB disk usage with retention.percentage

  The new `storage.tsdb.retention.percentage` setting lets you define a maximum percentage of available disk that TSDB can use. This is a cleaner safety net than estimating byte-based retention limits, especially in environments with variable data volumes. Consider pairing it with the existing time-based retention rather than replacing it — both constraints apply.

v1.33.11 is a maintenance patch with no code changes or dependency updates — purely a rebuild/re-release against the v1.33.10 baseline.

• enhancementSkip this upgrade if you're already on v1.33.10

  There are zero functional or security changes here. If your nodes are running v1.33.10 without issues, there's no practical reason to roll this out. Watch for v1.33.12 or a patch with actual fixes before scheduling maintenance windows.

• enhancementUse SBOM and cosign artifacts for supply chain verification

  Every build ships SPDX SBOMs and cosign bundle files. If your org has supply chain security requirements, integrate cosign verification into your upgrade pipeline now — this is a low-risk release to test that workflow against before a more impactful update arrives.

CRI-O v1.35.2 is a focused bug-fix patch addressing image pull credential verification, metrics reporting gaps, and OCI artifact store contamination issues.

• breakingVerify credential provider workflows after upgrading

  The PullImage fix changes what gets returned during image pulls. If you use Kubernetes credential provider plugins or have automation that validates image pull behavior, test those flows before rolling this to production. The old behavior could silently bypass credential checks in edge cases.

• enhancementAudit your metrics pipelines — you may have been missing data

  The metrics bug means any cluster running v1.35.x before this patch was likely returning incomplete metrics when 'all' was set. After upgrading, expect metric cardinality to increase. Check dashboards and alerting thresholds — a spike in metrics volume is expected and correct, not a problem.

• enhancementUse additional_artifact_stores for air-gapped or mirrored artifact setups

  If you run air-gapped clusters or internal artifact mirrors, the new 'additional_artifact_stores' option lets you configure multiple read-only sources without hacking around existing config. Pair this with the pinned_images fix to ensure pinned artifacts are pulled from the right store consistently.

CRI-O v1.34.7 is a patch release with no code changes or dependency updates from v1.34.6 — essentially a rebuild or release process artifact.

• enhancementSafe to skip unless you need the rebuild

  This release carries zero functional or security changes. If you're already on v1.34.6, there's no operational reason to upgrade immediately. That said, if your pipeline requires the latest patch tag for compliance or artifact provenance reasons, the SPDX SBOM and cosign bundles are all present and accounted for.

v2.0.2 is a focused patch: wasmtime runtime bumped to v43, a new Kubernetes Host pod reconciler added, and install scripts smoothed out.

• enhancementUpdate to pick up wasmtime 43 runtime improvements

  Wasmtime 43 includes upstream bug fixes and performance work. If you're running v2.0.1 in production, this is a low-risk upgrade worth taking. No API changes expected on the wasmCloud side — just redeploy your hosts.

• enhancementKubernetes operators: test the new Host pod reconciler

  The Host pod reconciler adds smarter lifecycle handling for wasmCloud hosts running as Kubernetes pods. If you're using the wasmCloud operator, deploy this in a staging cluster first and validate that host pod restarts and scheduling behave as expected before rolling to production.

• enhancementWindows users can now install wash via winget

  wash is now in the winget package registry. Windows-based teams can standardize installs with 'winget install wash' instead of manual binary downloads — useful for onboarding and CI pipelines on Windows runners.

etcd v3.6.10 is a patch release in the 3.6 series. Release notes are minimal — check the full CHANGELOG for specifics before upgrading.

• breakingRead the upgrade guide before rolling this out

  The release explicitly warns of potential breaking changes in v3.6. Before upgrading any cluster, check the official upgrade guide for v3.6 and review the full CHANGELOG-3.6.md. Don't treat this as a routine drop-in patch without that review.

• enhancementPrefer gcr.io images over quay.io for production pulls

  etcd now designates gcr.io/etcd-development/etcd as the primary registry and quay.io/coreos/etcd as secondary. If your image pull policy or air-gapped mirror config still points primarily to quay.io, update it to reduce dependency on a secondary source.

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.

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

• breakingAlways consult the upgrade guide on 3.4 patch bumps

  Even on patch releases, the etcd team occasionally introduces subtle behavioral changes or deprecations. The official upgrade guide for v3.4 should be checked — don't assume a patch bump is always safe to apply without review, especially in etcd's case given its role as a control plane data store.

• enhancementReview CHANGELOG before upgrading

  The release notes themselves contain no inline change details. Before upgrading, pull up CHANGELOG-3.4.md directly and diff against your current version. 3.4.x patches typically carry bug fixes and CVE backports, so skipping the review risks missing a relevant fix or behavioral change.

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

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

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

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

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

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

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

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

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

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

• securityCertificate rotation was silently broken — rotate certificates after upgrading

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

• breakingEviction race condition could leave workloads stranded on failing clusters

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

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

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

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

• securityAudit agent certificates for expiry before upgrading

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

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

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

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

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

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

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

• securityUpdate UI immediately to fix XSS vulnerability

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

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

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

• enhancementSide panel span view reduces trace analysis friction

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

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

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

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

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

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

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

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

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

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

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

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

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

• enhancementGPU resource fix prevents ghost allocations on GPU nodes

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

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

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

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

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

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

Open Policy Agent (OPA) v1.15.1 was released, but the published notes are too brief to summarize. See the original release notes for details.

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

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

• securitygRPC bump is cosmetic — but clear your scanner alerts

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

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

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

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

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

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

• breakingCheck for ghost sync loops before upgrading

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

• enhancementRoutine patch — safe to apply quickly

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

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

• securityApply this release for CVE fixes in dependencies and Python

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

• breakingAudit all five breaking changes before upgrading

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

• enhancementUse the new multiarch images for ARM64 clusters

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

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

• breakingAudit and fix custom HTTPAuthPlugin implementations before upgrading

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

• enhancementAdopt the file logger plugin to consolidate OPA log management

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

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

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

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

• securityUpgrade immediately for two active CVEs

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

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

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

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

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

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

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

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

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

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

• enhancementAdopt Private Key Offload for secrets-safe TLS

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

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

• securityGo 1.25.8 security patches — rebuild or upgrade

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

• breakingUpgrade immediately if running Scheduler in HA mode

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

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

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

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

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

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

• breakingCheck for spurious sync operations before and after upgrade

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

• enhancementRollingSync UI fix improves progressive delivery visibility

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

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.

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

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

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

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

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

• enhancementgrpc dependency bumped to 1.79.3

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