リリース

日本語 準備中Argo CD v3.2.9 is a patch release fixing excessive refresh triggers, a UI rendering bug for OCI revisions, and a CI lockfile issue, plus a dependency bump for fast-xml-parser.

• securityfast-xml-parser bump addresses potential XML parsing issues in the UI

  fast-xml-parser was bumped from 4.5.3 to 4.5.6. While no specific CVE is called out in the release notes, staying current on XML parsing libraries in web UIs is prudent given their attack surface. If your Argo CD UI is exposed to untrusted users or external traffic, this upgrade is worth prioritizing.

• enhancementUpgrade if informer resync noise is causing excessive reconciliation

  The fix for unintended automatic refreshes from informer resync and status updates (#25290) is the most operationally impactful change here. If you've seen high reconciliation rates or unexplained sync activity in busy clusters, this patch directly addresses that. Upgrade to 3.2.9 and monitor your refresh/sync rate metrics post-upgrade.

• enhancementOCI users: revision metadata now renders correctly

  If your team uses OCI-based Helm charts or manifests and noticed the revision metadata panel was always blank, that was a guard clause bug — not a config problem. This release fixes it. No action needed beyond upgrading; the UI should display OCI revision info correctly afterward.

日本語 準備中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'.

日本語 準備中edge-26.4.3 adds per-pod proxy env var injection via annotation, bumps proxy to v2.349.0, and validates Kubernetes 1.35 compatibility across policy tests.

• securityrustls-webpki patch — verify if you vendor Rust dependencies

  rustls-webpki was bumped to 0.103.11. This library is part of Linkerd's mTLS stack. No CVE is listed, but if your organization audits or vendors Rust dependencies, update your lockfiles and re-run your SBOM scans to stay current.

• enhancementUse proxy-additional-env to inject custom env vars without custom images

  The new `proxy-additional-env` annotation lets you set environment variables on injected proxies at the pod or namespace scope. This is useful for tuning proxy behavior (e.g., log levels, feature flags) in specific workloads without modifying global Helm values or building custom proxy images. Start using it on non-critical workloads first to validate behavior before rolling out broadly.

• enhancementPlan for Kubernetes 1.35 if you're on the upgrade path

  Linkerd's test suite now covers k8s 1.35, including policy tests. If your team is evaluating or scheduling a cluster upgrade to 1.35, this edge release gives you reasonable confidence that core Linkerd functionality and policy enforcement will hold. Run your own smoke tests against a 1.35 staging cluster before committing to a production upgrade.

日本語 準備中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.

日本語 準備中containerd 2.1.7 patches CVE-2026-35469 in spdystream and ships several hardening fixes including credential leak prevention via gRPC and a TOCTOU race in tar extraction.

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

  CVE-2026-35469 in moby/spdystream is fixed in this release. spdystream is used in the CRI streaming path, so any cluster running Kubernetes workloads with exec/attach/port-forward is potentially exposed. Upgrade containerd to 2.1.7 on all nodes. No config changes needed, just a binary swap and daemon restart.

• securityCredential leak via gRPC pod events is now closed

  Before this fix, raw errors containing registry credentials could surface in pod events visible to namespace-scoped users. If your clusters allow broad pod event access, assume credentials may have been exposed in logs or event streams. Rotate any registry pull secrets used on affected clusters, then upgrade to 2.1.7 to prevent recurrence.

• enhancementCNI DEL fix prevents IP/resource leaks after restarts

  A bug meant CNI DEL was never called for sandboxes cleaned up after a containerd restart, leaking network resources. If you've seen stale IPs or CNI state after node restarts, this is likely why. Upgrade to 2.1.7 and consider draining nodes before restarting containerd to clear any existing leaked state.

日本語 準備中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.

日本語 準備中v0.150.0 is a maintenance release with targeted bug fixes: corrects the print-config unredacted output, redacts internal telemetry OTLP headers in marshaled config, and fixes a bounds-check crash in the debug exporter.

• securityTelemetry exporter headers now redacted in marshaled config

  Internal telemetry OTLP exporter headers are now redacted when configuration is marshaled. If you log or store marshaled config output anywhere, headers (which may contain auth tokens) were previously exposed in plaintext. Upgrade and audit any stored config snapshots.

• enhancementFix print-config unredacted mode to show defaults

  The print-config command's unredacted mode previously dropped all default-valued options from output. Fixed by introducing confmap.WithUnredacted MarshalOption. If your team uses print-config for auditing or debugging configuration, re-run it after upgrading — the output is now complete and trustworthy.

日本語 準備中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.

日本語 準備中v1.14.1 patches a host-header poisoning vulnerability in AuthZEN discovery and removes a vulnerable Docker dependency, plus minor ListObjects performance gains.

• securityPatch the AuthZEN host-header poisoning vulnerability now

  The AuthZEN well-known discovery endpoint was returning URLs built from the request's Host header. An attacker could poison this to redirect clients to a malicious endpoint. If you expose the AuthZEN discovery metadata publicly, upgrade to v1.14.1 immediately. No config change needed — the fix is automatic once upgraded, as long as authzen.baseURL is correctly set in your server config.

• securityAudit your image builds if you ship the OpenFGA test binary

  The github.com/docker/docker package carries known CVEs and was only used in test code. Production builds are unaffected, but if your pipeline somehow includes test binaries or vendor directories in container images, verify they no longer include the vulnerable package after upgrading.

• enhancementSet an explicit server shutdown timeout for Kubernetes workloads

  The new shutdown timeout config option lets you control how long OpenFGA waits to drain in-flight requests before exiting. Without this, abrupt shutdowns can cause request errors during pod restarts. Set this to slightly less than your Kubernetes terminationGracePeriodSeconds to ensure clean handoff.

日本語 準備中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.