Releases

v2.1.5 patches three behavioral bugs (ImageConfig upgrades, ResourceSelector matching, circuit breaker resets) and pulls in a broad sweep of security dependency updates including Go 1.25.9.

• securityUpgrade to v2.1.5 promptly — this release addresses multiple CVEs in core dependencies

  The dependency list here is long: grpc, go-git (patched twice), go-jose, cloudflare/circl, moby/spdystream, docker/cli, and the OTel OTLP trace exporter all received security updates, plus Go itself was bumped to 1.25.9. Any of these could carry CVEs relevant to your threat model. This isn't a routine chore bump — prioritize this upgrade over staying on v2.1.4.

• breakingCheck for silently stale packages if you use ImageConfig prefix rewrites

  If your environment uses ImageConfig to rewrite registry prefixes, dependent packages may have been silently pinned at outdated versions since the bug was introduced. After upgrading to v2.1.5, verify that your package dependency graph resolves to the expected versions — stale packages won't auto-upgrade retroactively, so you may need to trigger a reinstall or version bump manually.

• enhancementResourceSelector 'select all of a kind' unlocks cleaner composition function patterns

  If you've been working around the previous rejection of bare apiVersion/kind selectors — adding dummy matchLabels or splitting logic — you can now clean that up. A selector with no match fields is treated as 'give me all resources of this kind,' which is the intuitive behavior. Review your composition functions for any workarounds and simplify them after upgrading.

v2.0.8 fixes two user-reported bugs (ImageConfig prefix rewrite upgrades, ResourceSelector with no match field) and patches multiple security vulnerabilities in upstream dependencies.

• securityUpgrade to v2.0.8 immediately for dependency security patches

  Multiple upstream dependencies received security-tagged fixes in this release — go-git (two separate bumps to v5.17.1 then v5.18.0), go-jose, cloudflare/circl, and others. These aren't just routine bumps; they carry CVE-related fixes. If you're running any v2.0.x release prior to v2.0.8, upgrade now. There are no API changes, so the upgrade path is straightforward.

• breakingAudit packages installed via ImageConfig prefix rewrites for stale dependencies

  If your environment uses ImageConfig prefix rewrites to redirect package pulls (e.g., to a private registry), dependent packages may have been silently stuck on outdated versions since you adopted that configuration. After upgrading to v2.0.8, force a reconciliation and verify that all package dependencies are on their expected versions — don't assume the upgrade alone will catch everything already in a stuck state.

• enhancementUse bare ResourceSelector (apiVersion+kind only) for 'select all' semantics in composition functions

  Previously, omitting matchName and matchLabels from a ResourceSelector caused Crossplane to reject the request outright. That's now fixed — a bare selector correctly means 'all resources of this kind'. If you worked around this limitation by enumerating resources explicitly or adding dummy match conditions, clean up those workarounds after upgrading.

Critical security patch fixing ACL bypass via path traversal in service invocation — any deployment using access control policies must upgrade immediately.

• securityUpgrade immediately if you use service invocation ACLs

  This is a real ACL bypass, not a theoretical one. If your Dapr deployment uses access control policies for service invocation and the Dapr API is reachable by untrusted callers — even internal ones — you are vulnerable. The gRPC vector is especially dangerous since it passes method strings raw with no sanitization. Upgrade to v1.15.14 now. There is no workaround short of disabling service invocation or isolating the Dapr API entirely.

• securityAudit who can reach your Dapr API endpoints

  This vulnerability required API access, so the blast radius depends entirely on your network posture. After upgrading, take the opportunity to review which workloads and network paths can reach the Dapr HTTP and gRPC APIs. Sidecar-only access (localhost) is the safest posture — if you're exposing Dapr APIs more broadly, tighten that regardless of this fix.

• breakingVerify your service invocation method paths still route correctly after normalization

  The fix applies path.Clean normalization to all method paths and rejects any containing #, ?, null bytes, or control characters. If any of your services legitimately use encoded slashes (%2F) as path separators in method names — particularly over gRPC where these were previously passed through raw — those calls will now behave differently. Test your service-to-service invocation patterns before rolling this to production.

Argo CD v3.3.7 is a patch release fixing controller performance regressions, OIDC config handling, and several UI/security header issues.

• securitySwagger UI endpoints now have clickjacking protection — upgrade if exposed

  X-Frame-Options and Content-Security-Policy headers were missing from Swagger UI endpoints. If your Argo CD API server is reachable from browsers (even internally), those endpoints were frameable. Upgrade to 3.3.7 to close this. No config change needed post-upgrade.

• breakingOIDC auth may behave differently after upgrade if config was stale

  The fix ensures OIDC config reloads on server restart rather than using a cached/stale version. In practice this is a correctness fix, but if you've been working around stale OIDC behavior with manual pod restarts, verify SSO flows after upgrading to confirm expected behavior.

• enhancementUpgrade if you're seeing excessive reconciliation or controller CPU spikes

  Two separate fixes address controller overhead: the parentUIDToChildren data structure change reduces memory churn on large clusters, and the informer resync fix stops unnecessary app refreshes that inflate API server load. If your controller is burning CPU or you're seeing constant reconcile loops, this patch is worth prioritizing.

v1.17.5 is a security-only patch fixing a path traversal vulnerability that allowed attackers to bypass service invocation ACL policies via encoded URL characters.

• securityUpgrade immediately if you use service invocation ACLs

  Any deployment with access control policies for service invocation is vulnerable. An attacker with Dapr API access (HTTP or gRPC) could reach denied endpoints by encoding the path. gRPC is especially risky since method strings were passed raw. Upgrade to v1.17.5 now — there is no workaround short of removing Dapr API exposure entirely. After upgrading, audit your ACL policies to confirm expected paths are actually being enforced.

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix adds strict validation: method paths containing #, ?, null bytes, or control characters are now rejected at the invocation edge. If any of your services use these characters in method paths (uncommon but possible with gRPC), those calls will fail after upgrade. Test your service invocation paths in a staging environment before rolling this to production.

Critical security fix: path traversal and encoded characters in service invocation method paths could bypass ACL policies entirely. Upgrade immediately if you use access control policies.

• securityUpgrade immediately if you use Dapr ACL policies

  Any deployment with service invocation access control policies is vulnerable. An attacker with access to the Dapr HTTP or gRPC API can craft method paths that the ACL permits but route to denied endpoints. The gRPC vector is especially dangerous since no client-side sanitization occurs. Upgrade to v1.16.14 now — there is no viable workaround short of removing Dapr API access entirely. After upgrading, audit your ACL policy rules to confirm they match the normalized path forms (resolved ../ and no encoded separators).

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix actively rejects method paths containing fragment (#), query (?), null bytes, or control characters rather than silently normalizing them. If any of your services invoke methods with these characters (unlikely but possible via programmatic gRPC calls), those calls will fail after upgrading. Review your service invocation call sites — especially any that construct method paths dynamically — before rolling this out to production.

v1.33.11 is a targeted patch fixing two networking bugs — apiserver startup failures with MultiCIDRServiceAllocator and kube-proxy nftables breakage on nft 1.1.3 — plus a Go 1.25.9 compiler bump.

• breakingUpgrade now if using MultiCIDRServiceAllocator with large clusters

  If you have MultiCIDRServiceAllocator enabled and a large namespace count, apiserver can fail to start during an upgrade — it was hitting Forbidden errors from admission plugins that weren't ready yet and not retrying. This patch makes that retry happen. If you've been deferring upgrades to 1.33 because of this, you're now unblocked. Check your apiserver logs for 'Forbidden' errors from the IP repair controller as a diagnostic signal.

• breakingkube-proxy nftables mode is broken on nft 1.1.3 — patch immediately

  Systems running nft 1.1.3 (which ships in some recent distro releases) will have silently broken kube-proxy nftables mode. Traffic may appear to work at first but rule updates won't apply correctly. If your nodes run nft 1.1.3, either pin to an older nft version as a workaround or — better — upgrade to this patch release. Run 'nft --version' on your nodes to check.

• enhancementOTel dependency jump to v1.41.0 — validate your observability pipeline

  The OpenTelemetry Go SDK went from v1.33.0 to v1.41.0 in this patch, which is a substantial version range. If you're consuming Kubernetes telemetry data or running sidecars that interact with the OTel SDK, verify compatibility with your collectors and backends after upgrading. No functional changes are documented for Kubernetes itself, but the jump is large enough to warrant a smoke test of your tracing and metrics pipelines in a non-prod environment first.

v1.34.7 is a focused patch release fixing two regressions — audit log latency annotations and nftables kube-proxy compatibility — plus a Go 1.25.9 rebuild.

• breakingAudit log latency data was silently missing — patch if you rely on it

  Any 1.34.x cluster prior to this patch has been dropping the request latency annotation from audit logs whenever a request exceeded 500ms. If your security or compliance tooling parses these annotations for SLO tracking or anomaly detection, your data has gaps. Upgrade to v1.34.7 and consider whether historical audit logs need to be flagged as incomplete for that window.

• breakingnftables kube-proxy is broken on nft 1.1.3 — don't skip this patch

  Clusters running kube-proxy in nftables mode on nodes with nft 1.1.3 (common in newer distros like Fedora 42 or Ubuntu 25.04) have non-functional networking. This isn't a performance issue — it's a hard failure. Either pin nft to an older version as a workaround or upgrade to v1.34.7 immediately. The fix is in the knftables library bump (v0.0.17 → v0.0.21).

• enhancementOTel dependency jump to v1.41.0 — verify your tracing integrations

  The OpenTelemetry Go packages moved from v1.35.0 to v1.41.0, which is a substantial jump. If you have custom instrumentation or sidecars that interact with Kubernetes' OTel spans, test in staging first. The change is backward-compatible in the API but internal behavior around span propagation and metric collection has evolved.

v1.35.4 is a focused patch fixing five real-world bugs: sidecar container restart failure, StatefulSet parallel scaling regression, kube-proxy nftables breakage, and audit log latency annotation errors.

• breakingCheck StatefulSet workloads if you rely on MaxUnavailable rolling behavior

  The MaxUnavailableStatefulSet feature gate is now disabled by default in 1.35.4, reversing behavior introduced earlier in 1.35. If you upgraded to 1.35.x expecting parallel pod management with maxUnavailable, that behavior is gone until the feature stabilizes. Audit your StatefulSet specs: if you set maxUnavailable, it will be silently ignored. Plan accordingly before upgrading, and watch for the gate to re-enable in a future minor.

• breakingSidecar + startupProbe combination was silently broken — upgrade promptly

  Any pod using an initContainer with restartPolicy: Always alongside a startupProbe would silently fail to restart crashed containers after a kubelet restart, showing RestartCount: 0 forever. This affects production workloads relying on sidecars (e.g., service mesh proxies, log shippers). If you've seen pods stuck in this state, upgrading to 1.35.4 and then manually deleting/recreating affected pods is the remediation path.

• enhancementUpgrade kube-proxy if running nft 1.1.3 on nodes

  Systems with nft (nftables) version 1.1.3 were broken in kube-proxy's nftables mode. This is a quiet but hard failure — networking simply doesn't work. If you're on newer distros shipping nft 1.1.3 (some recent Debian/Ubuntu variants), prioritize this patch upgrade for your node components.

Cilium v1.19.3 is a dense bugfix release targeting memory leaks, panics, and networking correctness issues — particularly in DSR mode, WireGuard dual-stack, and IPAM edge cases.

• securityUpdate go-jose dependency (CVE exposure)

  go-jose/go-jose was bumped to v4.1.4 as a security update. While Cilium's direct exposure depends on usage paths, this library is involved in JWT/token handling. If you're running automated audits or supply chain checks, note this dependency version change in your SBOM.

• breakingIPAM corruption risk on dual-stack clusters — upgrade urgently

  A bug in dual-stack cluster-pool IPAM could cause IPv4 PodCIDRs to be freed and reassigned after an operator restart if duplicate IPv6 PodCIDRs existed. This is a data-plane correctness issue that causes silent IP conflicts between nodes. If you run dual-stack with cluster-pool IPAM, upgrade to v1.19.3 before your next operator restart. After upgrading, inspect node CIDRs for any anomalies.

• enhancementMemory leak fixes matter more than they look — plan your upgrade

  Two distinct memory leaks are patched here. One is triggered by incremental policy updates (common in dynamic environments), the other by policy create/delete cycles. In clusters with frequent NetworkPolicy churn — CI namespaces, multi-tenant platforms, or GitOps-driven policy — these leaks can accumulate over hours or days. If your Cilium agents show gradual memory growth, this release likely explains it. Rolling restart after upgrade is sufficient; no config changes needed.

Cilium v1.18.9 is a patch release focused on memory leak fixes, panic prevention, and load balancer correctness — several bugs here could cause real production incidents.

• securitygo-jose dependency patched — update if using Cilium's auth features

  go-jose/go-jose/v4 was updated to v4.1.4 as a security fix. If your Cilium deployment uses mutual auth or any JWT/JOSE-based features, this patch addresses a known vulnerability in that library. Treat this upgrade as a priority if those code paths are active.

• breakingIPAM reassignment risk: upgrade dual-stack clusters promptly

  If you run dual-stack with cluster-pool IPAM, a bug could reassign a node's IPv4 PodCIDR to another node after an operator restart — with an existing duplicate IPv6 PodCIDR in play. This causes IP conflicts and broken pod networking. Upgrade to 1.18.9 before your next operator restart or planned maintenance window.

• enhancementMemory leaks under policy churn are fixed — relevant for dynamic environments

  Two separate memory leak paths were closed: one from incremental policy updates, one from policies being frequently created and deleted. Clusters with high policy churn (CI environments, multi-tenant setups, frequent namespace deployments) were slowly leaking memory. After upgrading, monitor Cilium agent memory baselines — you should see stabilization over hours to days.

v1.17.15 is a bug-fix patch tackling memory leaks, endpoint regeneration hangs, IPAM data corruption, and policy update deadlocks — all of which can cause silent production degradation.

• breakingIPAM corruption risk: upgrade before operator restarts in dual-stack clusters

  If you run dual-stack with cluster-pool IPAM and have any duplicate IPv6 PodCIDR conditions, an operator restart can cause IPv4 PodCIDR reassignment across nodes — effectively giving two nodes the same subnet. This is silent data-plane corruption. Upgrade to v1.17.15 before performing any operator restarts or node scaling operations in affected clusters.

• enhancementAddress memory leak accumulation in policy-heavy environments

  Two separate memory leaks were patched: one from incremental policy updates (slow, hard to detect) and another from policy churn (create/delete cycles). If you use GitOps-driven policy workflows or frequently rotate NetworkPolicies, your agents may be leaking memory right now. After upgrading, watch agent memory trends over 24-48 hours — you should see stabilization compared to a pre-upgrade baseline.

• enhancementEndpoints stuck in waiting-to-regenerate? This release fixes it

  A race condition caused endpoints to get permanently stuck in the 'waiting-to-regenerate' state, meaning policy changes stopped being applied to affected pods without obvious errors. If you've seen endpoints failing to pick up policy updates without a pod restart, upgrade and validate that endpoint regeneration completes cleanly after policy changes using 'cilium endpoint list'.

26.6.1 is a security patch release fixing two CVEs — blind SSRF and user enumeration — plus a critical migration bug that broke authentication flows when upgrading from older versions.

• securityPatch immediately for SSRF and user enumeration CVEs

  Two CVEs in 26.6.0 (and earlier) need your attention. CVE-2026-4366 allows blind SSRF through HTTP redirect handling — a real risk if Keycloak can reach internal services. CVE-2026-4633 leaks user existence through identity-first login, which aids credential stuffing. Upgrade to 26.6.1 now. If you can't upgrade immediately, consider disabling identity-first login as a short-term mitigation for CVE-2026-4633.

• breakingIf you upgraded to 26.6.0, check your custom authentication flows immediately

  The MigrateTo26_6_0 migration script had a bug that modified custom browser flows, potentially breaking realm authentication silently. If you upgraded to 26.6.0 and noticed login failures or unexpected flow behavior, this is why. Upgrading to 26.6.1 fixes the migration, but you may need to manually review and repair any already-affected custom flows in your realms. Audit them before upgrading in production.

• breaking26.6.0 JS/Java admin clients were broken — use 26.6.1 packages

  Both @keycloak/keycloak-admin-client (JS) and the Java admin client had packaging issues in 26.6.0 that prevented installation or sync. If your pipelines or applications depend on these libraries and you pinned to 26.6.0, they are likely broken. Update your dependency references to 26.6.1 immediately.

Dapr v1.16.13 fixes a critical scheduler reliability bug affecting multi-replica deployments, patches a silent Pulsar misconfiguration that could cause OOM crashes, and rebuilds with Go 1.25.9 for security fixes.

• securityUpgrade immediately for Go 1.25.9 security patches

  This build patches vulnerabilities in Go's crypto/x509, crypto/tls, archive/tar, and html/template packages. Any Dapr deployment still on 1.16.12 or earlier is exposed. Upgrade to 1.16.13 now — there's no workaround short of rebuilding from source with Go 1.25.9 yourself.

• breakingPulsar users: processMode will now actually take effect — verify your config

  If you have processMode set in your Pulsar component YAML, it was silently ignored before this release. After upgrading, that config will be enforced. If you set processMode: sync expecting ordered processing but were actually running async, behavior changes on upgrade. Review your Pulsar component metadata and subscription behavior before rolling this out to production. Also check maxConcurrentHandlers: if it was set to 0, it previously caused a deadlock; now it falls back to 100.

• breakingMulti-replica scheduler deployments: patch this immediately

  The scheduler bug is severe in practice. A routine pod restart — due to a rolling update, OOM kill, or node eviction — would silently stop all job triggers across your deployment until some unrelated cluster event re-established connections. There's no alerting or visible failure; jobs just stop firing. If you run multiple scheduler replicas (standard HA setup), this fix is critical. Upgrade and verify your scheduled jobs are firing after any scheduler pod restart.

Litmus 3.28.0 is a focused maintenance release fixing a probe config leak, a subscriber crash on workflow events, and a Python vulnerability in the frontend base image.

• securityUpgrade frontend to resolve Python CVE in base image

  The frontend container was running on a ubi8 base image with a Python vulnerability. The fix upgrades it to ubi9. If you run Litmus in environments with strict image scanning policies (e.g., Trivy in CI, ACS, or Prisma), this upgrade will clear those alerts. Pull the 3.28.0 frontend image and redeploy — no config changes needed.

• breakingProbe config leak fix may change behavior for shared-type probe setups

  If you run multiple probes of the same type in a single experiment, previous releases silently shared stale config between them. The fix now isolates config per probe. Audit any experiments where multiple probes of the same type are defined — if you were unknowingly relying on config bleed-over, results may differ after upgrading.

• enhancementSubscriber crash fix improves reliability for GitOps and event-driven workflows

  Teams using Litmus in GitOps mode or triggering experiments via Argo Workflow ADD events with ChaosEngine nodes were hitting silent subscriber crashes. After upgrading to 3.28.0, those workflows should resume without manual subscriber restarts. No action required beyond the upgrade, but verify subscriber pod stability post-deploy if you've been seeing unexplained restarts.

Rook v1.19.4 is a focused patch release fixing CephObjectStoreUser capabilities, adding multi-cluster RBAC fixes, and improving OSD disk handling with forceful zap support.

• breakingMulti-cluster deployments: apply the RBAC fix immediately

  The missing ceph-mgr RBAC role in secondary clusters could cause silent permission failures that are hard to diagnose. If you're running Rook in a multi-cluster setup, upgrade to v1.19.4 and verify ceph-mgr is operating correctly post-upgrade. Don't wait on this one.

• enhancementForceful OSD replacement is now cleaner with disk zap

  The new disk zap behavior during forceful OSD installation removes the manual cleanup step that previously caused headaches when replacing failed OSDs. If you've been scripting around this limitation, review your runbooks — the operator now handles it directly.

• enhancementAdd labels to RGW services for better traffic routing

  CephObjectStore RGW services now accept custom labels, which opens up more precise service mesh, load balancer, and network policy targeting. Worth adopting if you're running multiple object stores or need finer-grained traffic control.

v1.50.0 is a wide-ranging release with several breaking changes across auth, frontend APIs, and catalog. Key practical upgrades: AWS RDS IAM auth, Auth0 federated logout, catalog deadlock fixes, and security patches for rollup/glob.

• securityUpdate CLI and build tooling to pick up rollup path traversal fix

  rollup < v4.59 has a high severity path traversal vulnerability (GHSA-mw96-cpmx-2vgc). The @backstage/cli, repo-tools, and several CLI modules have been updated. Run the upgrade helper and update your lockfile. If you pin rollup versions anywhere in your workspace, update those pins to v4.59+. The glob dependency was also bumped to v13 to address vulnerabilities in v7/v8/v11.

• breakingVerify token decoding code before upgrading — ent claim removed by default

  auth.omitIdentityTokenOwnershipClaim now defaults to true, so Backstage user tokens no longer include the ent ownership claim. Any code that manually decodes tokens and reads ent will silently get nothing. Audit your codebase for raw token decoding and replace it with the userInfo core service. If you need time, set auth.omitIdentityTokenOwnershipClaim: false in your config temporarily, but plan to remove it — the setting will be dropped in a future release.

• breakingMigrate createSchemaFromZod to configSchema before upgrading frontend-plugin-api

  The deprecated createSchemaFromZod helper is gone in @backstage/[email protected]. Any extension or blueprint using it will fail at runtime. Check the 1.50 migration docs at backstage.io/docs/frontend-system/architecture/migrations#150 and switch to the configSchema option. Note that plain zod v3 schemas are not supported — use import { z } from 'zod/v4' from the zod v3 package or upgrade to zod v4.

containerd v2.2.3 patches CVE-2026-35469 in spdystream and fixes several bugs including whiteout handling in parallel unpacks, TOCTOU race in tar extraction, and Go 1.24 symlink regressions.

• securityPatch CVE-2026-35469: upgrade to v2.2.3 now

  CVE-2026-35469 affects moby/spdystream, which containerd uses for streaming connections. The fix is in spdystream v0.5.1, bundled in this release. If you're running any 2.2.x version, treat this as a mandatory upgrade — don't wait for your next maintenance window.

• breakingParallel unpack whiteout bug could mean corrupted layer state — verify images

  A bug caused whiteout files (which signal file deletions between layers) to be ignored when parallel unpack was enabled. If you've been using parallel unpack with overlayfs, layer deletion semantics may not have applied correctly. After upgrading, re-pull any images that were unpacked in parallel to ensure their layer state is consistent.

• enhancementGo 1.24 users on NixOS or symlink-heavy rootfs: this fixes your container startup failures

  Absolute symlink handling in rootfs user/group lookups regressed with Go 1.24. This affected systems where /etc/passwd or /etc/group are symlinks (common on NixOS-style setups). If you've seen user lookup failures or container start errors after moving to Go 1.24-built binaries, upgrading to v2.2.3 resolves this.

containerd 2.0.8 patches CVE-2026-35469 in spdystream, fixes a credential leak in CRI error messages, and resolves a CNI DEL lifecycle bug after containerd restarts.

• securityPatch CVE-2026-35469 by upgrading to 2.0.8 now

  CVE-2026-35469 lives in the moby/spdystream dependency. Details are in a GitHub security advisory. If you're running containerd 2.0.x in any cluster, upgrade to 2.0.8 — this is the primary reason for the release. Don't wait for your next maintenance window if the advisory turns out to be high severity.

• securityCheck your pod event logs for past credential exposure

  Before this fix, registry credentials or other secrets embedded in URLs could appear in plaintext inside CRI gRPC error messages and pod events. If you're shipping pod events to a logging backend (Datadog, Splunk, ELK, etc.), audit recent logs for query parameters that shouldn't be there. Going forward, 2.0.8 redacts these before they leave containerd.

• breakingValidate CNI network cleanup works correctly after upgrading

  The CNI DEL bug meant network namespaces and CNI plugin state weren't cleaned up when a pod was deleted after a containerd restart. This could leave stale network state on nodes. After upgrading to 2.0.8, verify that pod deletion properly invokes CNI DEL — especially on nodes that have experienced containerd restarts. If you've noticed orphaned network interfaces or IP allocation issues, this fix is the likely culprit.

v1.7.31 patches CVE-2026-35469 in spdystream, fixes a CNI DEL regression after restarts, and closes a credential leak in pod events via gRPC error sanitization.

• securityPatch CVE-2026-35469 by upgrading to v1.7.31 now

  CVE-2026-35469 affects the moby/spdystream library used for SPDY multiplexing. The fix is in spdystream v0.5.1, bundled here. If you're running any 1.7.x release prior to this, upgrade immediately — especially on clusters where the CRI streaming server is exposed or where kubectl exec/attach/port-forward traffic flows through containerd.

• securityAudit pod event logs for previously leaked credentials

  A bug caused raw error messages — potentially containing registry credentials — to be returned over gRPC and surface in pod events. After upgrading, review historical pod event logs (kubectl get events, or your log aggregation system) for any entries containing auth tokens, passwords, or image pull secrets from before this fix was applied. Rotate any credentials you find.

• breakingVerify CNI network teardown is working correctly after upgrade

  The CNI DEL fix means containers that previously left behind stale network state after a containerd restart will now properly clean up. This is the right behavior, but if you have automation or scripts that assumed CNI DEL was idempotent-by-absence (i.e., expected cleanup to be skipped), test those workflows. Nodes with a history of unclean restarts may see cleanup activity on first pod deletion post-upgrade.

v2.12.7 is a targeted bug-fix release addressing ACL bypass vulnerabilities, multiple leafnode panics, a JetStream consumer stuck state, and an MQTT JWT regression from 2.12.6.

• securityPatch ACL bypass bugs immediately if you use deny rules or queue groups

  Two ACL enforcement bugs are fixed here. Overlapping wildcard patterns in deny ACLs were not enforced correctly, and queue subscriptions could bypass non-queue deny rules entirely. If your security model relies on deny-based ACLs — especially with wildcards or mixed queue/non-queue subscribers — treat this as a must-upgrade. Audit your ACL configurations after upgrading to confirm expected deny behavior is active.

• breakingMQTT users on 2.12.6 must upgrade — auth callout JWT was broken

  If you deployed 2.12.6 with MQTT clients using auth callout, JWTs were not being forwarded to the callout service, meaning your auth logic was silently bypassed or failing. This regression is fixed in 2.12.7. Upgrade immediately and verify MQTT client authentication is functioning end-to-end.

• enhancementmax_mem_store and max_file_store can now be increased via config reload

  You can now raise JetStream storage limits without restarting the server — just update the config and reload. Decreasing is still not supported via reload. Useful for capacity adjustments during peak periods without downtime. Plan your storage sizing with headroom so you can expand reactively if needed.

v2.11.16 is a security-focused patch fixing multiple ACL bypass vulnerabilities in queue subscriptions, leafnode inbound messages, and wildcard deny patterns — update immediately if you rely on NATS authorization.

• securityACL bypass via queue subscriptions — patch now

  Queue subscribers could silently bypass deny rules intended for non-queue subscriptions. If your authorization model uses deny patterns to restrict subjects, those controls were not reliably applied. Audit your ACL configurations and update to v2.11.16 before anything else. This affects any multi-tenant or permission-isolated NATS deployment.

• securityLeafnode ACL enforcement was incomplete — verify your leaf configs

  Inbound messages on leafnode connections were not always checked against ACL permissions. If you run leafnode-connected clusters with per-account or per-user authorization, treat this as a potential unauthorized data access vector. After upgrading, review leafnode user credentials and their associated permission sets.

• breakingno_auth_user scope change may affect existing setups

  The no_auth_user option is now restricted to client connections only. If you had any tooling or configuration relying on no_auth_user applying to leafnode or other non-client connection types, those connections will now require explicit credentials. Test in staging before rolling this update to production leafnode infrastructure.

TiKV v8.5.6 brings column-level privileges, multi-dimensional slow query rules, shared locks for FK checks, and ~13 bug fixes including a memory leak in crossbeam skiplist and a rare pessimistic transaction data inconsistency.

• securityColumn-level privileges close a data isolation gap — audit your schemas

  TiDB now supports MySQL-compatible column-level GRANT/REVOKE. If you've been relying on view-based workarounds to restrict access to sensitive columns (PII, financial data), you can now enforce this at the privilege layer instead. Audit tables that contain sensitive columns and apply least-privilege grants. This also means existing privilege audits may be incomplete — review user grants against newly exposed column-level controls.

• breakingMigrate off Statistics Version 1 now — it's deprecated and removal is coming

  tidb_analyze_version=1 is deprecated in this release and will be removed in a future version. Run SHOW VARIABLES LIKE 'tidb_analyze_version' on all instances. If any are on v1, switch to v2 and re-run ANALYZE on affected tables. Version 2 produces more accurate histograms and is the only supported path going forward. Don't wait until the removal forces a rushed migration.

• enhancementEnable shared locks for FK checks to cut contention in write-heavy workloads

  If you run high-concurrency INSERT/UPDATE on child tables with foreign key constraints pointing to a small set of parent rows, you're likely hitting exclusive lock contention today. Set tidb_foreign_key_check_in_shared_lock=ON and benchmark — shared locks on the parent table allow concurrent FK checks without blocking each other. Test in staging first, as this changes locking semantics. Also pick up the fix for the pessimistic transaction prewrite retry inconsistency (issue #11187) — worth verifying your TiKV nodes are on this patch if you run pessimistic workloads.

v2.0.3 patches a NATS race condition, adds Kubernetes EndpointSlice support, hardens container security with non-root ownership, and expands Helm chart configurability.

• securityUpgrade now: containers finally run as non-root by default

  Previous releases ran with root ownership, which is a container security red flag. This release sets non-root ownership by default. If you have volume mounts or init containers with root-dependent file permissions, test before rolling to production — you may need to adjust fsGroup or runAsUser settings in your pod specs.

• breakingHelm chart image tag behavior changed — audit your values files

  The default image tag no longer falls back to a hardcoded value; it now uses the chart's appVersion. If you rely on overriding the tag in your values files, this likely works as-is. But if you were depending on the old default tag behavior for pinning, verify your deployed image versions after upgrading the chart.

• enhancementEnable EndpointSlice support if running Kubernetes 1.21+

  EndpointSlice is the modern replacement for Endpoints and scales better with large service backends. If your cluster runs Kubernetes 1.21 or later, enable this feature — it reduces load on kube-apiserver and avoids the scaling limits of the classic Endpoints API. Check your Helm values for the new endpointslice configuration option.

OpenCost v1.120.0 adds OVH cloud provider support, AWS CUR 2.0 compatibility, and fixes several resource leaks and bugs across AWS, DigitalOcean, and S3 integrations.

• breakingCheck PV cost accuracy after upgrading — unit parsing was broken

  PV capacity was previously mishandled for Ki/Mi/Gi/Ti units, which means PV cost allocations may have been wrong in earlier versions. After upgrading, verify your PV cost data looks correct, especially if you were seeing anomalous persistent volume costs.

• enhancementMigrate to AWS CUR 2.0 if you haven't already

  AWS is deprecating CUR 1.0 — this release adds CUR 2.0 support. If you're still on CUR 1.0 exports, now is the time to update your AWS billing export configuration and point OpenCost at the new format. Don't wait for AWS to force the migration.

• enhancementSuppress noisy Spot feed warnings with the new toggle

  Teams not using AWS Spot instances were getting misleading log warnings about spot data feeds. You can now explicitly disable the Spot Data Feed via config. Set the toggle if you're not using Spot — it cleans up your logs and removes the misleading provider log noise fixed in this release.

Prometheus v3.11.2 patches a stored XSS vulnerability (CVE-2026-40179) in the web UI, plus two Consul SD fixes. Upgrade immediately if your UI is exposed.

• securityPatch CVE-2026-40179 immediately if your Prometheus UI is reachable

  A stored XSS can be triggered by crafted metric names or label values — meaning any scrape target you ingest data from could potentially inject malicious scripts into your UI. If your Prometheus endpoint is accessible to users beyond the ops team (internal dashboards, federated setups), treat this as urgent. Upgrade to v3.11.2 now. If you can't upgrade immediately, restrict UI access via network policy or auth proxy until you can.

• breakingVerify Consul SD behavior after the Health API filter fix

  The filter parameter was previously applied incorrectly to the Consul Health API. After upgrading, your Consul service discovery results may change if you were relying on that filter — intentionally or not. Review your Consul SD configs and validate that the services being scraped post-upgrade match your expectations before rolling out to production.

• enhancementUse `health_filter` in Consul SD to reduce noise from unhealthy services

  The new `health_filter` field lets you filter Consul Health API responses directly at the SD layer. If you've been working around this with relabeling rules to drop unhealthy instances, you can now clean that up. Set `health_filter` to `healthy` in your Consul SD config to only scrape passing services and reduce unnecessary target churn.

Patch release fixing a Helm chart YAML generation bug when webhook.config and webhook.volumes are both set, plus Go 1.26.2 upgrade to address dependency vulnerabilities.

• securityDependency vulnerabilities patched — upgrade to get the fixes

  The Go runtime and dependencies were bumped specifically to address reported CVEs. The release notes don't call out specific CVE IDs, but don't let that slow you down — cert-manager sits in a privileged position in your cluster handling certificate issuance, so keeping it current on security patches is non-negotiable. Schedule an upgrade in your next maintenance window.

• breakingUpgrade immediately if you use both webhook.config and webhook.volumes

  If your Helm values set both webhook.config and webhook.volumes, the chart has been generating invalid YAML — meaning your webhook may have silently deployed with incorrect configuration. Upgrade to v1.20.2 and redeploy, then verify the webhook pod is running with the expected volume mounts and config.

Envoy v1.37.2 is a patch release fixing three runtime bugs: a crash on listener removal, incomplete body forwarding in dynamic module filters, and a request hang on buffer overflow during internal redirects.

• breakingUpgrade immediately if using process-level access log rate limiting

  If your Envoy config uses a process-level access log rate limiter and you perform any listener hot-reload or removal, you are hitting a crash path. This is not a low-probability edge case — listener removal happens during routine config updates via xDS. Upgrade to v1.37.2 before your next config push.

• breakingCheck dynamic module filter pipelines for body truncation

  If you run dynamic module filters alongside other filters that buffer request or response bodies (e.g., ext_proc, gRPC transcoding, JWT body inspection), you may have been forwarding truncated payloads upstream or to clients without any error. Audit logs for unexpected body size mismatches and validate behavior in staging after upgrading.

• breakingInternal redirect with large request bodies could hang — patch this now

  Any route config using internal redirects combined with upstream services that can trigger redirects on large POST/PUT bodies is a hang risk. The request stalls rather than returning an error, which means your upstream timeout is the only safety net. This is a silent reliability failure. Upgrade and consider temporarily tightening request buffer limits on affected routes as a short-term guard.

Envoy v1.36.6 is a patch release fixing two bugs: incomplete body delivery in dynamic module filters and a request hang when internal redirect triggers buffer overflow.

• breakingUpgrade if you use dynamic module filters with buffering neighbors

  If your filter chain mixes dynamic module filters with any filter that buffers the body (e.g., ext_proc, grpc-web, or custom buffering filters), you were silently receiving incomplete bodies. This is a data-correctness bug, not just a performance issue. Upgrade to v1.36.6 immediately and validate that your dynamic modules are processing full payloads post-upgrade.

• breakingInternal redirect + buffer overflow caused indefinite request hang

  Any deployment using internal redirects where the request body can exceed the configured buffer limit was exposed to hung requests — requests that never complete and hold connections open. This is particularly dangerous under load. Upgrade now; in the interim, consider raising buffer limits or disabling internal redirects if you're seeing stuck requests.

Dapr 1.17.4 patches seven bugs spanning workflow correctness, Pulsar OOM risk, actor freeze under placement pressure, and a Go stdlib security update. Deploy promptly if you use any of these features.

• securityUpgrade immediately for Go stdlib CVE fixes

  Go 1.25.9 patches vulnerabilities in archive/tar, crypto/tls, crypto/x509, html/template, and the compiler. All Dapr binaries and Docker images are rebuilt with the patched toolchain. Update your Dapr runtime to 1.17.4 now — no config changes needed, just the version bump.

• breakingPulsar processMode behavior has changed — validate your component config

  If you set processMode in Pulsar component YAML before this fix, it was silently ignored and you were running in default mode. After upgrading, the setting takes effect. If you had processMode: sync expecting ordered processing but were unknowingly running async, behavior will change. Also, async mode now caps concurrency at maxConcurrentHandlers (default 100). Review your Pulsar component metadata and test throughput behavior before rolling to production.

• enhancementEliminate actor/workflow freeze risk from placement slowness

  The placement dissemination freeze bug could cause cascading health check failures during rolling updates — Kubernetes would declare pods unhealthy and restart them, worsening the cycle. With 1.17.4, a slow peer triggers reconnect rather than a fatal teardown. If you've seen unexplained actor hangs or zombie daprd processes during rollouts, this is likely the cause. No configuration change needed; upgrading is sufficient.

Keycloak 26.6.0 graduates several preview features to fully supported — JWT Authorization Grant, Federated Client Auth, Workflows, and zero-downtime patch releases — while fixing a notable set of security bugs across UMA, SCIM, and Organizations.

• securityPatch SCIM and UMA vulnerabilities immediately

  Two separate SCIM bugs allowed IDOR-style resource modification and authorization bypass in group management. UMA permission grant accepted expired ID tokens and tokens issued to other clients. These are fixed in 26.6.0. If you use SCIM or UMA, upgrade now — no config change needed, but verify your SCIM plugin/extension is compatible with the new validation.

• breakingSwitch to KCRAW_ prefix if secrets contain $ characters

  If you inject passwords or secrets via environment variables and they contain $ characters (e.g., from a secrets manager), the KC_ prefix silently mangles them via SmallRye expression evaluation. Use KCRAW_<KEY> instead of KC_<KEY> to preserve literal values. Audit your current env var injection before upgrading — any secrets with ${ or $$ patterns may have been silently broken in prior versions.

• enhancementEnable zero-downtime rolling updates in your Operator deployments

  Zero-downtime patch releases are now on by default. If you run Keycloak via the Operator, explicitly set the update strategy to Auto to benefit. Also review the new graceful HTTP shutdown defaults (1s delay, 1s timeout) — adjust these upward if your reverse proxy takes longer to drain connections, especially in non-Kubernetes setups with longer-lived connections.

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.

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.

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.

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.

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.

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.

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.