リリース

日本語 準備中Rook v1.19.3 delivers targeted fixes and additions across CSI, pool management, OSD operations, and RGW — with a notable shift to ceph-csi-operator for CSI deployments.

• breakingCSI now deploys via ceph-csi-operator — verify your deployment model

  The shift to ceph-csi-operator for deploying Ceph-CSI/NVMe-oF changes how CSI components are managed. If you have customized CSI sidecar configurations or rely on specific deployment behavior, audit your setup before upgrading. The ceph-csi-operator introduces its own CRDs and reconciliation loop, so any direct overrides you've applied to CSI DaemonSets or Deployments may be overwritten or ignored post-upgrade.

• enhancementEncrypted OSD users: apply the lockbox key rotation fix now

  The lockbox key rotation bug for encrypted OSDs could leave your cluster in an inconsistent encryption state over time. If you're running encrypted OSDs, upgrade to v1.19.3 and verify key rotation is functioning correctly afterward. This is especially relevant if you've observed any anomalies during OSD replacement or key rotation workflows.

• enhancementRGW on IPv6? The secret formatting fix is a must

  The incorrect IPv6 formatting in object store user secrets would cause connection failures in IPv6-only or dual-stack environments. If your RGW deployment uses IPv6 addressing, this fix directly unblocks proper user secret generation. After upgrading, recreate or reconcile affected object store users to pick up correctly formatted secrets.

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

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

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

• breakingEncrypted OSD users should test key rotation after upgrading

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

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

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

日本語 準備中KubeVirt v1.8.0 is a large release (1242 changes, 77 contributors) adding a new VM backup API, VMPool auto-healing, containerpath volumes, and multiple network/storage improvements with several breaking removals.

• breakingRemove SLIRP and Macvtap network bindings before upgrading

  Both core SLIRP and Macvtap bindings are completely removed in v1.8.0. If any VMs in your cluster use these bindings, they will break post-upgrade. Audit your VM specs now with a label/annotation query, migrate affected VMs to passt or bridge bindings, and validate in a non-prod environment before rolling this to production.

• breakingUpdate migration metrics in dashboards before upgrading

  kubevirt_vmi_migration_data_total_bytes is deprecated and will eventually be removed. If you have Grafana dashboards, Prometheus alerts, or recording rules referencing this metric, update them to kubevirt_vmi_migration_data_bytes_total now. Also note the vCPU recording rule rename from kubevirt_vmi_vcpu_count to vmi:kubevirt_vmi_vcpu:count — both need updating together.

• enhancementAdopt explicit feature gate disabling for tighter cluster governance

  You can now explicitly block feature gates via disabledFeatureGates in the KubeVirt config rather than relying on gates simply being absent. For clusters where you want to enforce that certain alpha/beta features stay off (e.g., in regulated environments), add them to the disabled list. This is particularly useful if you're managing KubeVirt configs via GitOps and want auditable gate enforcement.

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

• securityUpgrade immediately — 11 CVEs patched across core subsystems

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

• breaking1MB JWT size limit is now enforced

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

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

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

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

• securityUpgrade now — 11 CVEs, multiple remote attack surfaces

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

• breakingMQTT client ID restrictions may break existing clients

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

• enhancementTrace logging and monitoring endpoints now redact secrets

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

日本語 準備中OpenFGA v1.13.1 was released, but the published notes are too brief to summarize. See the original release notes for details.

日本語 準備中Knative v1.21.2 is a small patch release with one TLS improvement and a heads-up that secure-pod-defaults will flip to AllowRootBounded in v1.22.

• breakingAudit root-dependent workloads before v1.22 ships

  The AllowRootBounded secure-pod-defaults setting is coming as the new default in v1.22. If any of your Knative Services run containers that require root (e.g., legacy apps, certain base images), they will break after that upgrade. Right now, while you're on v1.21, test those workloads with AllowRootBounded explicitly enabled. If they fail, set secure-pod-defaults to 'disabled' in your config-features ConfigMap before upgrading to v1.22 — don't wait until upgrade day.

• enhancementConfigurable TLS via knative.dev/pkg/network/tls

  The shift to the shared knative.dev/pkg/network/tls library gives operators more control over TLS settings in Serving. If you manage custom TLS configurations or have internal PKI requirements, review whether this change aligns your TLS behavior with expectations — particularly in environments where cipher suites or minimum TLS versions are enforced by policy.

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

• securityUpgrade to get the Envoy security fixes

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

• breakingCheck custom manifests for the removed hostPort: 8002

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

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

• securityUpgrade for the Envoy security fixes

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

• breakingCheck custom manifests that reference Envoy hostPort 8002

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

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

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

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

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

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

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

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

日本語 準備中OpenFGA v1.13.0 ships AuthZen v1.0 support, separates Check v1/v2 caches, and hardens the resolver pipeline against panics.

• securityUpgrade to stop resolver panics from taking down the server

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

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

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

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

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

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

• securityPatch the world-accessible Envoy admin socket immediately

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

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

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

• breakingL7 LB ingress policy bypass — check your enforcement posture

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

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

• securityPatch the world-accessible Envoy admin socket immediately

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

• breakingGKE users: do not deploy v1.18.8

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

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

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

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

• securityPatch the world-accessible Envoy admin socket immediately

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

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

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

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

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

日本語 準備中v2.0.1 is a minor housekeeping release — migrates the runtime-operator Go module to v2, regenerates protos, and cleans up a temporary go.work workaround.

• breakingUpdate import paths if you import the runtime-operator Go module

  The runtime-operator Go module moved to a v2 module path. Any Go code importing it directly must update import paths to include the /v2 suffix. If you're only running wasmCloud as an operator and not importing the module in your own code, no action is needed.

• enhancementUpgrade from v2.0.0 if you hit proto or lint issues

  This patch fixes regenerated protos and removes a temporary go.work shim that may have caused inconsistencies in local development builds. If you were building the operator from source against v2.0.0, pull this patch to avoid stale proto or dependency resolution issues.

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

• securityPatch RUSTSEC-2026-0007 by upgrading immediately

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

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

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

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

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

日本語 準備中Backstage v1.49.2 was released, but the published notes are too brief to summarize. See the original release notes for details.

日本語 準備中Backstage v1.49.1 is a patch release cleaning up new frontend system rough edges, fixing UI issues in TechDocs/Scaffolder, and adding small DX improvements to the create-app template.

• enhancementUnprocessed entities DevTools tab is now on by default

  If you're debugging entity ingestion issues, you no longer need to configure the DevTools unprocessed entities tab manually. Upgrade and it's there. Useful for catching catalog processing failures faster in development and staging environments.

• enhancementNew frontend system adopters: pick up layout fixes now

  If your team is migrating to or testing the new Backstage frontend system, this patch fixes concrete layout problems in both the Scaffolder and Catalog entity pages. Skip 1.49.0 and go straight to 1.49.1 to avoid dealing with those visual regressions.

• enhancementPlugin headers can now carry navigation links

  The new titleLink prop on PageLayoutProps lets plugin header titles act as navigation anchors back to the plugin root. Worth adopting if you're building or maintaining custom plugins — it aligns with the expected UX pattern for Backstage's evolving plugin header system.

日本語 準備中etcd v3.6.9 is a maintenance release. The release notes are sparse — check the full CHANGELOG for the actual diff before upgrading.

• breakingRead the CHANGELOG before upgrading — release notes are incomplete

  The published release notes for v3.6.9 contain no change details. Before upgrading any etcd cluster, pull up CHANGELOG-3.6.md directly and diff the entries since your current version. The 3.6 series has known breaking changes, and skipping this step on a stateful system like etcd is a real risk.

• enhancementVerify container image source if you pull from quay.io

  etcd's primary registry is gcr.io/etcd-development/etcd. If your pipelines pull from quay.io/coreos/etcd, confirm that image is current and matches the gcr.io digest. Secondary registries can lag. Pin by digest, not just tag, to avoid silent version mismatches.

日本語 準備中etcd v3.5.28 is a patch release in the 3.5 series. Release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingRead the CHANGELOG before upgrading — release notes are incomplete

  The published release notes for v3.5.28 contain no actual change details. Before upgrading any etcd cluster, pull the full CHANGELOG-3.5.md from the etcd repo and review entries since your current version. Skipping this on a stateful system like etcd is a real risk.

• enhancementStick to the primary container registry for pulls

  gcr.io/etcd-development/etcd is the authoritative image source. quay.io/coreos/etcd is secondary and may lag. If your cluster pulls from quay.io, verify the image digest matches the primary before deploying in production.

日本語 準備中etcd v3.4.42 is a maintenance release on the 3.4 branch. The release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingCheck the upgrade guide even for patch releases

  The release explicitly calls out that breaking changes may exist. On a 3.4.x patch bump this is unlikely but not impossible — particularly around snapshot or WAL handling. Verify the upgrade guide is clean for your version before rolling out to production clusters.

• enhancementReview the full CHANGELOG before upgrading

  The release notes published here are essentially empty. Before applying this update to any environment, pull the CHANGELOG-3.4.md directly from the etcd repo to understand what bug fixes or patches are included. Blind upgrades on a critical consensus store are a bad idea.

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

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

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

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

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

• enhancementCap proxy cache upstream connections to protect upstream registries

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

日本語 準備中SPIRE v1.14.4 was released, but the published notes are too brief to summarize. See the original release notes for details.

日本語 準備中v1.12.1 is a focused maintenance release fixing OTLP endpoint URI parsing and improving ListObjects pipeline internals with Go native channels.

• breakingOTLP https:// scheme now forces TLS regardless of your config flag

  If you set OTEL_EXPORTER_OTLP_ENDPOINT with an https:// scheme, TLS will be enabled even if trace.otlp.tls.enabled is false. Audit your observability configs before upgrading — any environment using https:// endpoints with TLS explicitly disabled will now have TLS enabled. This is almost certainly the correct behavior, but verify your collector setup accepts TLS connections.

• enhancementOTLP endpoint URIs with schemes finally work — clean up your workarounds

  Previously, passing a full URI like http://host:4317 to OTEL_EXPORTER_OTLP_ENDPOINT would break because the scheme wasn't stripped before reaching the gRPC exporter. If you've been working around this by omitting the scheme, you can now use standard URI formats. Update your deployment configs and remove any manual scheme-stripping logic.

• enhancementListObjects performance improvement — no action needed, just upgrade

  Replacing the custom Pipe implementation with Go native channels reduces internal complexity and can improve throughput for ListObjects calls under concurrent load. No API changes, no config changes needed. The tuple validation refactor compounds this. If you're running OpenFGA at scale with heavy ListObjects usage, this patch is worth taking.

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

• securityrustls patch update — pull this into your proxy builds

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

• enhancementTwo proxy versions landed — check the proxy changelog separately

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

• enhancementGo 1.25.8 in the control plane — standard maintenance upgrade

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

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

• securityUpgrade immediately to patch three Go stdlib CVEs

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

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

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

• enhancementLarge actor deployments and streaming workloads should prioritize this patch

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

日本語 準備中Patch release bumping grpc from 1.78.0 to 1.79.3 and updating the Ansible operator plugin. Minimal surface area — safe to adopt quickly.

• securityUpgrade for gRPC dependency fix

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

• enhancementAnsible plugin users should rebuild operator images

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

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

• securityPatch all 8 CVEs — upgrade to 26.5.6 now

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

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

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

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

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

日本語 準備中v1.35.3 is a small patch with two kubeadm bug fixes and one DRA eviction status reporting cleanup. Low risk, safe to apply.

• enhancementUpgrade kubeadm-managed clusters to fix etcd learner endpoint bug

  The etcd learner member fix is the most operationally relevant change here. If you use kubeadm and have experienced etcd client connectivity issues during node join/promotion operations, this patch addresses the root cause. Schedule an upgrade during your next maintenance window — no config changes required, just a kubeadm binary update.

• enhancementkubeadm reset is more reliable on systems with peer mounts

  If your node reset automation was failing on environments where /var/lib/kubelet has peer mounts (common in certain container runtimes or nested mount configurations), this fix prevents those EINVAL errors from blocking the reset process. Worth upgrading if you've seen unexplained reset failures.

日本語 準備中v1.34.6 is a minimal patch fixing two kubeadm bugs: etcd learner endpoints and a kubelet unmount error during cluster reset.

• enhancementUpgrade if you run kubeadm-managed clusters with etcd membership changes

  The etcd learner fix matters any time you add etcd members — a learner node (not yet a voting member) being included in client endpoints could cause request failures during the promotion window. If you've seen intermittent etcd client errors during node additions, this patch resolves it. Otherwise, apply at your normal patch cadence.

• enhancementUpgrade if kubeadm reset fails on your nodes

  The EINVAL unmount fix addresses a real pain point: kubeadm reset aborting mid-way when certain bind mounts under /var/lib/kubelet can't be cleanly unmounted. This tends to show up on nodes with overlapping mount namespaces or specific filesystem setups. If you've had to manually clean up after a failed reset, this patch removes that friction.

日本語 準備中v1.33.10 is a small patch fixing a kube-controller-manager nil pointer crash in ValidatingAdmissionPolicy and two kubeadm operational bugs. No dependency changes.

• breakingPatch immediately if you use ValidatingAdmissionPolicy with open schemas

  Any ValidatingAdmissionPolicy referencing an object schema with `additionalProperties: true` will crash kube-controller-manager outright — not degrade gracefully. If you're running v1.33.x and using VAP, check your policies now. Upgrade to v1.33.10 before deploying any new policies with open schemas, or you risk taking down the controller manager.

• enhancementkubeadm etcd learner fix matters for HA cluster joins

  When adding control plane nodes, etcd temporarily registers new members as learners. The previous behavior incorrectly included learner endpoints in the etcd client pool, which could cause client errors during promotion. If you run kubeadm-managed HA clusters and have experienced intermittent etcd client failures during control plane joins, this patch resolves it. Upgrade before your next control plane scaling operation.

• enhancementkubeadm reset now handles stubborn bind mounts cleanly

  On nodes with bind-mounted /var/lib/kubelet directories, `kubeadm reset` previously failed with EINVAL during unmount, leaving cleanup incomplete. The fix silently ignores EINVAL — which is expected for peer mounts — so resets complete cleanly. Useful if you automate node decommissioning with kubeadm reset in scripts.

日本語 準備中A broad feature release adding 12+ new AWS resources, new upgrade-available filters for EKS/Elasticsearch, Azure Entra ID resources, and GCP Vertex AI support. Several bug fixes address S3 cache staleness, GuardDuty validation, and IAM user errors.

• enhancementAudit EKS and Elasticsearch upgrade readiness now

  The new upgrade-available filter for both EKS and Elasticsearch means you can write policies that flag clusters where a newer version exists. If you've been tracking version compliance manually, replace that with a c7n policy using the upgrade-available filter and route matches to notify or tag. Good timing before any end-of-support deadlines.

• enhancementAdd whitelist_patterns to cross-account filters using deleted principals

  If your cross-account policies flag deleted IAM principals as violations, you've likely been dealing with false positives. The new whitelist_patterns parameter on the cross-account filter lets you skip ARN patterns for known-deleted or transient principals. Review your existing cross-account policies and add patterns for any deleted accounts or service-linked roles you see repeated in output.

• enhancementAudit Azure Entra ID security posture with new resource types

  Four new Entra ID resource types — conditional-access-policy, authorization-policy, named-location, security-defaults — are now queryable. If you manage Azure security baselines, write policies to check that security defaults are enabled and conditional access policies match your org's requirements. This fills a gap that previously required separate tooling.

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

• securityUpgrade immediately to fix TLS session ticket bypass

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

• securitySelector data no longer leaks into agent logs

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

• breakingPQC users must migrate from Kyber draft to X25519MLKEM768

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

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

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

日本語 準備中Litmus 3.27.0 ships Job targeting for chaos experiments and fixes a cluster of stability bugs: nil pointer crashes, GitOps deadlocks, race conditions, and probe detection failures.

• breakingGitOps two-way sync was silently broken — verify your sync state after upgrading

  The GitOps sync handler goroutine was disabled, meaning changes in Git were not propagating back to Litmus in two-way mode. After upgrading to 3.27.0, manually trigger a sync and confirm experiment state matches your Git source of truth. Any drift that accumulated should be reconciled.

• enhancementTarget Kubernetes Jobs in chaos experiments

  If your team runs batch workloads or CI pipelines as Kubernetes Jobs, you can now inject chaos directly into them. Update your experiment manifests to reference Job resources and validate resilience of batch processing paths — something previously impossible without workarounds.

• enhancementMultiple nil pointer and race condition fixes reduce silent failures

  At least three separate nil pointer dereferences are fixed in this release (subscriber, QueryServerVersion, YAML parser), plus experiment run race conditions. If you've seen intermittent crashes or experiments stuck in inconsistent states, upgrading is the straightforward fix — no config changes needed.

日本語 準備中v1.49.0 is a landmark release: the New Frontend System hits 1.0 RC, the CLI becomes extensible via modules, and there are multiple breaking changes in UI components, integrations, and entity cards requiring migration work.

• breakingMigrate entity cards and BUI components before upgrading `@backstage/plugin-catalog`

  The major version bump on `@backstage/plugin-catalog` means direct action is required. Remove all `variant` prop usage from EntityAboutCard, EntityLinksCard, EntityLabelsCard, GroupProfileCard, and UserProfileCard. Wrap your app in a `BUIProvider` inside a React Router context — without it, Link, ButtonLink, Tabs, Menu, and Table lose client-side navigation. Also rename any CSS selectors using old `bui-HeaderPage` class patterns and camelCase data attributes. Audit custom components that implement the old `Checkbox` `selected`/`indeterminate` props and switch to `isSelected`/`isIndeterminate`.

• breakingRemove all deprecated Bitbucket and legacy integration config immediately

  The old `bitbucket` config key and Azure DevOps `token`/`credential` fields are gone — not deprecated, gone. If your `app-config.yaml` still references these, your backend will fail to start after upgrading. Replace `bitbucket` with `bitbucketCloud` or `bitbucketServer`, migrate Azure DevOps to the `credentials` array, and update any Gerrit URL utility calls. Check scaffolder templates too, as `parseRepoUrl` no longer handles `bitbucket`.

• enhancementAdd `@backstage/cli-defaults` as a devDependency now, not later

  The CLI module system is live, and the fallback to built-in commands already emits a deprecation warning. Add `@backstage/cli-defaults` to your root `devDependencies` today to silence the warning and future-proof your setup before the fallback is removed entirely. If you maintain custom CLI tooling, look at `createCliModule` in `@backstage/cli-node` to package it properly as a first-class CLI extension.

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

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

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

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

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

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

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

日本語 準備中Lima v2.1.0 adds experimental macOS and FreeBSD guest support, renames the guest home directory path, and consolidates disk files — a release with real migration considerations alongside useful new features.

• breakingDisk file consolidation means no downgrade path

  Once an instance runs under Lima v2.1, its disk format is incompatible with v2.0 and v1.x. Snapshot or back up critical VM instances before upgrading. If you manage shared Lima environments or CI pipelines that pin Lima versions, ensure all consumers upgrade together — you can't roll back individual instances.

• breakingHardcoded paths to `/home/${USER}.linux` will break

  The guest home directory is now `/home/${USER}.guest`. A symlink covers the old path, so most things will keep working. However, any scripts, dotfiles, or tooling that hardcodes the `.linux` suffix — particularly in non-symlink-aware contexts like bind mounts or container volume paths — should be audited and updated.

• enhancementUse `limactl shell --sync` for AI agent workflows

  If you're running AI coding agents (e.g., Claude Code, Aider) inside Lima shells, `--sync` prevents the agent from accidentally modifying host files by syncing the working directory into the guest context. Adopt this flag in any automation or agent harness that launches `limactl shell` — it's a low-friction safety net.

• enhancementk3s template now supports multi-node clusters

  The built-in `k3s` template can now spin up multi-node clusters, which makes local Kubernetes testing significantly more realistic. If you've been working around this limitation with custom configs or alternative tools like Rancher Desktop, it's worth re-evaluating the native template.

日本語 準備中KubeVirt v1.7.2 is a patch release fixing 7 bugs across networking, storage, monitoring, and backup — no new features, but several fixes that could unblock production issues.

• breakingCheck VMI specs if you're running mixed NIC configurations

  The infinite status loop fix targets VMIs where the primary network interface appears after a secondary one in the spec. If you have VMs stuck in update churn or virt-controller/virt-handler showing abnormal CPU/log volume, this is likely the cause. Upgrade to v1.7.2 and verify your VMI specs list the primary interface first to avoid re-triggering the issue on older clusters.

• enhancementWindows VM backup users should update for reliable Velero integration

  The QuiesceFailed-to-QuiesceTimeout change plus a 60s pre-backup hook timeout directly addresses flaky Windows VSS snapshot behavior during Velero backups. If you're backing up Windows VMs and seeing intermittent quiesce failures, this patch resolves it. Review your Velero backup policies to ensure the hook timeout aligns with your SLAs.

• enhancementGoogle Cloud NetApp Volumes storage migration is unblocked

  If you're running VMs on GCP with NetApp Volumes and tried live storage migration, it was silently failing. This patch fixes that. Test your migration workflows after upgrading — especially if you deferred any storage moves because of this bug.

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

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

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

• breakingCross-vendor live migrations are now blocked

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

• enhancementAdd vCPU queue alerts to your monitoring setup

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

日本語 準備中Flux v2.8.3 fixes a critical helm-controller regression that broke templating for charts containing YAML separators or embedded content.

• breakingUpgrade immediately if using Helm charts with YAML separators

  The regression in v2.8.2 breaks templating for common chart patterns like multi-document YAML files and embedded scripts. Review your Helm deployments for failures and upgrade to v2.8.3 now. Follow the official upgrade procedure for Flux v2.7+ to avoid migration issues.

• enhancementValidate Helm chart deployments after upgrade

  After upgrading, check that previously failing Helm releases now deploy successfully. Pay special attention to charts that embed certificates, scripts, or use multiple YAML documents. This fix restores functionality that may have silently failed in recent versions.