リリース

etcd v3.5.31 is a patch release on the 3.5 branch. Release notes are minimal — check the full CHANGELOG for specifics before upgrading.

• breakingCheck the upgrade guide even for patch versions

  The etcd team explicitly calls out that breaking changes can appear in patch releases. Don't skip the upgrade guide assuming this is safe to apply blindly. Verify any API or storage format changes against your current deployment before scheduling maintenance.

• enhancementReview CHANGELOG before upgrading

  The release notes published here are sparse. Before rolling this out, pull the full CHANGELOG-3.5.md directly from the etcd repo to identify any bug fixes or behavioral changes that affect your cluster. Patch releases on 3.5 have historically included compaction fixes and lease handling improvements — worth verifying what specifically landed here.

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

• breakingCheck the official upgrade guide even for patch releases

  The release explicitly flags that breaking changes may exist. Etcd 3.4.x is a mature but still-active branch used heavily in Kubernetes clusters. Verify the upgrade guide at etcd.io before rolling this out, especially in production environments where quorum and data integrity are non-negotiable.

• enhancementReview CHANGELOG before upgrading — release notes are intentionally minimal

  This release page contains almost no detail. Before upgrading, pull up CHANGELOG-3.4.md directly in the etcd GitHub repo to understand what actually changed. Blind upgrades on etcd — your cluster's source of truth — are a bad idea regardless of how minor a patch looks.

v1.17.9 fixes a targeted bug where workflows using Azure Cosmos DB as their actor state store get permanently stuck in a purge loop when the customStatus row is absent.

• breakingUpgrade immediately if using Cosmos DB for workflow state

  Any deployment using state.azure.cosmosdb as the workflow actor state store is at risk. Affected workflows never get purged past their TTL, and the scheduler fires a purge attempt every second forever — burning CPU, generating log noise, and inflating your dapr_runtime_workflow_operation_count{status=failed} metrics. Upgrade to 1.17.9 and restart sidecars; stuck workflows recover on the next retention reminder fire automatically. No manual cleanup needed after upgrade.

• enhancementCheck metrics now to assess blast radius before upgrading

  Before upgrading, query dapr_runtime_workflow_operation_count with labels operation=purge_workflow and status=failed. A non-zero and growing count on a Cosmos DB deployment confirms you have stuck workflows. This tells you how many workflows will self-heal post-upgrade and gives you a clear before/after signal to verify the fix took effect.

flagd core v0.16.0 changes disabled flag evaluation from an error response to a successful resolution with reason=DISABLED, affecting gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit any code that checks errorCode or reason on flag evaluations

  If your code branches on FLAG_DISABLED error codes or checks the reason field from direct gRPC/OFREP responses, it will no longer receive that error path for disabled flags — it'll get a success with reason=DISABLED instead. Search your codebase for FLAG_DISABLED string matches, error-code switch statements, and reason-field conditionals before upgrading. SDK users who only consume the resolved value are unaffected and can upgrade without changes.

• enhancementUse reason=DISABLED for observability and audit logging

  The new behavior is actually cleaner for telemetry. Since disabled flags now resolve successfully, you can distinguish 'flag disabled' from 'evaluation error' in your metrics and logs without special-casing error codes. Update your dashboards and alerting rules to treat reason=DISABLED as an expected, non-error signal rather than filtering it out as noise.

flagd v0.16.0 changes disabled flag evaluation from an error to a successful resolution with reason=DISABLED, affecting direct gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit error-handling code that checks FLAG_DISABLED or errorCode

  If your application checks the evaluation reason or error code after a flag resolution — whether through direct gRPC calls, OFREP HTTP calls, or Go imports of core/pkg/model — you need to update that logic. FLAG_DISABLED errors will no longer appear; instead expect a successful response with reason=DISABLED. SDK users who only read the resolved value are unaffected, but any monitoring, alerting, or branching logic that keys off FLAG_DISABLED will silently stop triggering. Grep your codebase for FLAG_DISABLED and errorCode checks before upgrading.

KEDA v2.20 ships four breaking removals, an RBAC migration for Kubernetes events, two new scalers, and a wave of bug fixes including credential-leak and connection-leak patches across several scalers.

• securityPatch credential-leak and connection-leak issues in Pulsar, RabbitMQ, and AWS scalers

  The Pulsar scaler was leaking bearer/basic auth credentials on cross-host redirects or HTTPS-to-HTTP downgrades. RabbitMQ had an AMQP connection leak. AWS scalers (SQS, Kinesis, DynamoDB, CloudWatch) leaked TCP connections on scaler close. If you run any of these scalers, upgrading to v2.20 closes real attack surface and resource exhaustion vectors. No config changes needed, but consider rotating credentials used by Pulsar scalers as a precaution.

• breakingUpdate RBAC before upgrading — events.k8s.io migration is not optional

  If you use custom or restricted RBAC for KEDA, add create/patch on events.k8s.io/events to the operator role before you upgrade. The official Helm chart and manifests already handle this, but any out-of-tree RBAC will silently break event recording. Also audit your ScaledObjects for the four removed settings (GCP PubSub subscriptionSize, Huawei minMetricValue, IBM MQ tls, InfluxDB authToken in triggerMetadata) — resources using these will fail validation after upgrade.

• enhancementAWS cross-account scaling now works natively via External ID support

  The new External ID field in TriggerAuthentication podIdentity covers all AWS scalers. If you've been using workarounds for cross-account IAM assume-role scenarios, you can now use the native field. Update your TriggerAuthentication manifests to set the externalId field — no more custom IAM boundary hacks required.

Lima v2.1.2 is a broad maintenance release fixing hostagent resource leaks, zombie processes, and gRPC connection leaks — plus template updates for Kubernetes 1.36, Ubuntu 26.04, and Fedora 44.

• breakingAlpine template split — update your instance configs

  The generic `template:alpine` has been split into `template:alpine-3.21`, `template:alpine-3.22`, and `template:alpine-3.23`. If you reference `template:alpine` in scripts, CI, or configs, those references will break. Audit and update them to a specific versioned template before upgrading.

• breaking_LIMA_QEMU_UEFI_IN_BIOS is deprecated — stop using it

  If you have the `_LIMA_QEMU_UEFI_IN_BIOS` environment variable set in any scripts or dotfiles, remove it now. The flag is deprecated in this release and will likely be removed in a future version. Check wrapper scripts and CI pipelines that invoke limactl with QEMU.

• enhancementHostagent resource leak fixes — worth upgrading if you run long-lived instances

  Four separate hostagent fixes address GuestAgentClient leaks, inotify watcher accumulation, and gRPC stream mishandling on reconnect. If you've seen memory creep or stale connections in long-running Lima instances, this release directly addresses those issues. Upgrade proactively rather than waiting.

Volcano v1.15.0 ships gang-aware preemption/reclamation, DRA queue quota, autoscaler-friendly scheduling gates, and a batch of critical scheduler stability fixes addressing double-counting, race conditions, and rollback correctness.

• securityApply CVE-2026-44247 webhook DoS fix and Prometheus XSS patch

  v1.15.0 includes a mitigation for CVE-2026-44247, which allowed oversized webhook request bodies to exhaust webhook server memory. The Prometheus dependency is also updated for a stored XSS advisory (GHSA-vffh-x6r8-xx99). Upgrade to v1.15.0 if you expose Volcano admission webhooks — there's no workaround short of upgrading.

• breakingDon't mix gangPreempt/gangReclaim with legacy preempt/reclaim

  The new gangPreempt and gangReclaim actions are mutually exclusive with the legacy preempt and reclaim actions in a scheduler action list. If you upgrade and add gang-aware actions without removing the old ones, you'll get undefined behavior. Audit your scheduler ConfigMap before upgrading — pick one set or the other. Also note that DRA scheduling is now on by default; if your cluster doesn't have DRA-capable drivers, explicitly set predicate.DynamicResourceAllocationEnable: false.

• enhancementEnable Scheduling Gates to stop autoscaler over-scaling on queue limits

  If you run Cluster Autoscaler or Karpenter alongside Volcano, queue-blocked pods previously triggered unnecessary node scale-ups. The new scheduling gate feature fixes this cleanly. It's opt-in per pod via the scheduling.volcano.sh/queue-allocation-gate: 'true' annotation. Enable the feature gate on both the scheduler and webhook-manager, then annotate workloads that should respect queue admission before autoscaler signals fire. Good candidate workloads: batch jobs with strict queue quotas where you want to avoid wasted node provisioning.

v1.17.3 fixes a chart upgrade blocker, corrects multi-cluster search visibility, prevents over-scheduling, and stabilizes cluster readiness detection during credential rotation.

• breakingUnblock chart upgrades: ConfigMap size issue resolved

  The karmada-operator-chart had a ConfigMap size overflow when embedding the Karmada CRD, blocking chart upgrades. This is fixed in v1.17.3. If you are stuck on an older chart version due to this error, upgrade immediately to restore your ability to update Karmada deployments.

• breakingScheduler now respects cluster resource limits

  The scheduler previously allowed multiple workload replicas to land on a single cluster even when it had insufficient resources. v1.17.3 fixes over-scheduling. Audit your current deployments after upgrade to verify actual placement against your expectations, and adjust replica counts if needed.

• enhancementSearch now reflects recovered cluster resources correctly

  karmada-search now correctly watches recovered clusters and reflects their resources without delay. If you rely on search functionality across cluster recovery scenarios (failover or restoration), upgrade to v1.17.3 to ensure visibility into newly recovered member clusters.

• enhancementCluster readiness now waits for failure threshold

  A temporary credential rotation failure (missing SecretRef) now waits for the ClusterFailureThreshold before marking a cluster NotReady, instead of failing instantly. This prevents hair-trigger failovers during routine rotation. No action required if you already have a stable credential rotation process; this reduces false positives for teams that do.

Karmada v1.16.6 fixes three reliability issues: watch-based resource discovery on cluster rejoin, scheduler over-committing resources under concurrent scheduling, and hair-trigger cluster failover on temporary credential errors.

• breakingFix scheduler resource exhaustion vulnerability

  The scheduler previously allowed workloads to land on clusters with insufficient resources if multiple template resources were being placed simultaneously. Upgrade to v1.16.6 to enforce proper resource availability checks. Review your cluster resource limits and current deployments to confirm they respect intended capacity constraints post-upgrade.

• breakingCluster readiness now respects failure threshold

  Transient credential issues during secret rotation no longer immediately mark clusters as unready and trigger failover. Karmada now respects the ClusterFailureThreshold before degrading cluster status. If you tune ClusterFailureThreshold or rely on rapid failover behavior, test cluster credential rotation in a staging environment to confirm failover timing matches your expectations.

• enhancementWatch discovery now reflects recovered cluster resources

  Karmada-search now properly mirrors resources from clusters that rejoin after network issues or restarts. If you run multi-cluster deployments with watch-based resource discovery, verify after upgrading that recovered clusters' resources reappear in search results without manual intervention. Monitor search logs for any delays in resource reconciliation on rejoined clusters.

v1.18.0 adds overflow cluster affinities for hybrid cloud burst scheduling and a scheduling overcommit protection mechanism. Mandatory step: upgrade to v1.17.3+ before applying this release.

• securityAlpine base image updated to 3.23.4

  The base Alpine image moved from 3.23.3 to 3.23.4. No action needed beyond the normal upgrade, but if you pin image digests in your deployment, update them accordingly.

• breakingUpgrade to v1.17.3+ before moving to v1.18.x

  Before upgrading to v1.18.x, you must first be on v1.17.3+. Skipping this step will break the operator upgrade. Check your current version with `karmadactl version` and upgrade to v1.17.3+ first if you are behind.

• breakingDeprecated gRPC fields in scheduler-estimator require plugin updates

  Several deprecated gRPC fields in karmada-scheduler-estimator are now replaced: `resourceRequest` → `resourceRequestBytes`, `nodeAffinity` → `nodeAffinityBytes`, `tolerations` → `tolerationsBytes`. If you have custom estimator plugins or tooling that reads these fields directly, update them before upgrading. The old fields still exist in v1.18 but are deprecated and will be removed in a future release.

• breakingRemoved flags and metric labels will break existing configs

  Two flags removed from karmada-controller-manager: `--cluster-lease-duration` and `--cluster-lease-renew-interval-fraction`. Also, `Etcd.Local.InitImage` is gone from Karmada Init Configuration. If your deployment scripts or Helm values reference these, remove them before upgrading or the components will fail to start. Also check your Prometheus dashboards: the `cluster` and `cluster_name` metric labels are gone, replaced by `member_cluster`.

• enhancementCritical scheduler and eviction bug fixes

  Two significant scheduler bugs are fixed in this release. First, bindings with insufficient cluster replicas were retrying via exponential backoff (1–10s) instead of the correct 5-minute timer queue — workloads may have appeared stuck. Second, a race condition could silently drop graceful eviction tasks when multiple controllers modified the same ResourceBinding concurrently, meaning workloads might not have been evacuated from failing clusters. If you have observed unexplained scheduling delays or failed evictions, upgrade to v1.18.0 and re-examine affected workloads.

• enhancementEnable SchedulingOvercommitProtection in high-throughput clusters

  SchedulingOvercommitProtection (disabled by default via feature gate) closes the window where back-to-back scheduling decisions could over-commit a cluster's capacity before Pods are actually bound to nodes. Enable it in high-throughput environments where you see workloads going Pending due to resource exhaustion shortly after scheduling. Set `--feature-gates=SchedulingOvercommitProtection=true` on karmada-scheduler and karmada-scheduler-estimator once you've validated in staging.

• enhancementOverflow Cluster Affinities for hybrid cloud burst scheduling

  The new `overflowAffinities` field in PropagationPolicy/ClusterPropagationPolicy lets you define fallback cluster groups. The scheduler fills the primary group first, then spills to supplementary groups in order. On scale-down, replicas are reclaimed from supplementary groups first. Useful for IDC-primary / public-cloud-overflow patterns. This is a new API field — existing policies are unaffected unless you add it.

v1.120.3 patches two Go CVEs and ships a wide range of bug fixes across AWS, Azure, Oracle, and DigitalOcean providers, plus OVH support and cosign image signing.

• securityPatch vulnerable Go dependencies — upgrade immediately

  A Go dependency update patches GHSA-xmrv-pmrh-hhx2 and CVE-2026-34986. If you're running any v1.120.x release prior to v1.120.3, upgrade now — these are dependency-level vulnerabilities, not just code changes.

• breakingMCP server is now opt-in — check your config before upgrading

  The MCP server now defaults to disabled (MCP_SERVER_ENABLED=false). If you were relying on it being on by default, set the env var explicitly after upgrading. Check your deployment manifests before rolling out.

• enhancementEnable cosign image verification in your admission pipeline

  Container images are now signed with cosign keyless signing and include SLSA provenance attestations. If your admission policy requires image signature verification, you can now enforce it against OpenCost images. Update your policy tooling (e.g., Kyverno, Cosign verify) to validate these attestations in CI or at deploy time.

gRPC v1.81.0 drops Python 3.9 and Ruby 3.1 support, fixes crash-level races on Windows and ARM, and adds AsyncIO observability for Python.

• breakingPython 3.9 support dropped — check your runtime

  gRPC Python 1.81.0 drops Python 3.9 support. If your services still run on Python 3.9, stay on an older gRPC release until you can upgrade your runtime. Plan the Python version bump before pulling this release.

• breakingRuby 3.1 support dropped — upgrade your Ruby runtime

  Ruby 3.1 has reached EOL and gRPC 1.81.0 drops support for it. If you're running Ruby 3.1 in production with gRPC, you'll need to upgrade to Ruby 3.2+ before adopting this release.

• enhancementWindows and ARM stability fixes worth taking

  Two EventEngine fixes address a use-after-free and a race condition causing assertion errors on Windows, plus a completion queue shutdown race on ARM (weak memory model). If you run gRPC on Windows or ARM-based infrastructure, this release directly fixes stability issues that could cause crashes. Upgrade when stable.

Kubescape v4.0.9 is a large maintenance release fixing scan accuracy bugs (partial resource collection, coverage reporting, Prometheus output), hardening data exposure in scan reports, and changing the patch command's default push behavior.

• securityReview secret exposure fixes and new anonymization flag

  Multiple fixes landed for secret/data leakage in scan output: EnvFrom and Env[].ValueFrom are now cleared in removeContainersData (commits acc3280, 0c68cca), an IDOR in /v1/results was hardened (commit 0fe6a0f), and a new --hide/anonymization pipeline was added to scrub resource names, namespaces, labels, annotations, and container metadata from scan reports. If you share or export Kubescape reports outside your team, review the new --hide flag and confirm your CI artifacts aren't exposing secret references from container env vars.

• breakingPatch command no longer pushes images by default

  Kubescape's `kubescape fix` command now defaults to not pushing patched images (commit b10cbb1). If your CI pipelines relied on the old default push behavior, add an explicit `--push` flag or equivalent opt-in, or your patch pipeline will silently stop pushing images after upgrading.

• enhancementAdopt new coverage-gate and diff commands in CI

  New flags let you gate CI pipelines on scan coverage and control results: --fail-coverage-below sets a minimum coverage threshold (commit 4ae7b87), and scan coverage gaps/not-evaluated controls are now reported explicitly (commit 5876d2b). A new `kubescape diff` command compares two scan reports (commit 00682ee). Add --fail-coverage-below to CI gates where partial resource collection could previously pass silently, and use `kubescape diff` to track posture drift between scans.

v1.17.8 fixes two issues: workflows getting permanently stuck when reusing completed instance IDs, and a Sentry OIDC security flaw (CWE-346) that allows discovery document poisoning via X-Forwarded-Host.

• securityFix OIDC discovery document poisoning via X-Forwarded-Host

  Sentry OIDC deployments running without `--jwt-issuer` or `--oidc-allowed-hosts` are vulnerable to CWE-346: an attacker who can send requests with a forged `X-Forwarded-Host` header can poison the discovery document, and HTTP caches may serve the poisoned response for up to an hour. If you can't upgrade immediately, set `--jwt-issuer` (pins the issuer statically, simplest fix) or `--oidc-allowed-hosts`. If you use a reverse proxy that needs to advertise its public hostname via `X-Forwarded-Host`, set `--oidc-allowed-hosts` to your expected hostname — this is now required for that header to take effect.

• breakingUpgrade to fix stuck workflows with reused instance IDs

  Any workflow using deterministic/stable instance IDs is affected. After upgrading sidecars to 1.17.8, stuck workflows recover automatically on the next retention reminder fire — no manual scheduler cleanup needed. Check your `dapr_runtime_workflow_operation_count{operation=purge_workflow,status=failed}` metric; if it's incrementing at ~1/sec per workflow, you're hitting this bug.

0.9.51.0 is a broad feature release adding new AWS AI/ML and agent resources, fixing a breaking iam-access-key schema change, and significantly expanding GCP label management coverage across ~15 resource types.

• breakingRemove json-diff filter from iam-access-key policies before upgrading

  The `json-diff` filter has been removed from `aws.iam-access-key`. Any policies using this filter will fail at runtime. Audit your policy files for `iam-access-key` resources before upgrading and remove or replace any `json-diff` filter references.

• enhancementAdopt new cross-account org path support for IAM policy checks

  AWS cross-account policy evaluation now supports `aws:PrincipalOrgPaths` and whitelisted accounts. If you run cross-account governance policies, review this new support — it may let you replace custom workarounds you've built for org-path-based principal checks.

• enhancementExtend GCP label compliance policies to cover newly supported resource types

  GCP label coverage has expanded significantly: Cloud Run services/jobs, Pub/Sub topics/subscriptions, Redis, Secrets Manager secrets, snapshots, DNS managed zones, interconnects, load balancer addresses and forwarding rules, and Cloud Functions all now support `set-labels` and `mark-for-op`. If you run GCP tagging compliance policies, this release lets you extend label enforcement to most of these resource types without workarounds. Update your GCP policies to cover the newly supported resources.

Prometheus 3.12.0 ships two security patches (Remote Write DoS, STACKIT SD secret leak), fixes a WAL race in Agent mode, and cuts TSDB range query CPU with a quadratic-to-constant head chunk lookup fix.

• securityPatch two security fixes now — especially if using STACKIT SD

  Two CVEs patched in this release. First: Remote Write now rejects snappy-compressed payloads where the declared decoded size exceeds 32 MB — this closes a DoS vector against your remote-write receiver endpoint. Second: STACKIT SD was leaking secrets in plaintext via the `/-/config` endpoint (GHSA-39j6-789q-qxvh). If you use STACKIT SD, rotate any credentials that may have been exposed before upgrading.

• breakingAgent mode WAL race and remote_write panic bug fixed — upgrade Agent deployments

  A race condition in the agent appender could produce duplicate in-memory series and duplicate WAL records when concurrent appends target the same label set. If you run Prometheus in Agent mode under high write concurrency, this bug could silently corrupt your WAL. Upgrade to 3.12.0 to fix it. Also, `remote_write` queue_config fields are now validated at load time — misconfigurations that previously caused silent runtime panics will now fail at startup, which is the right behavior but means you should test configs before rolling out.

• enhancementTSDB range query CPU cut and auto-reload-config is now stable

  TSDB head chunk lookup in range queries drops from quadratic to constant time, and mmap operations now skip series that don't need work. At production scale with large head chunks, this can meaningfully cut CPU. No config changes needed — just upgrade. Separately, `auto-reload-config` is now stable (no longer experimental), so you can drop any caveats around it in runbooks.

OPA v1.17.0 fixes a semantic bug in negation handling and improves decision log label reporting. Most changes are enhancements; one dependency removal requires manual GOMAXPROCS configuration in some environments.

• breakingRemoved automaxprocs and x/net dependencies; configure GOMAXPROCS manually if needed

  OPA v1.17.0 removes the automaxprocs and x/net dependencies, reducing the runtime footprint and eliminating potential conflicts with applications that also manage those libraries. No action is required unless your deployment explicitly depends on automaxprocs behavior (automatic CPU detection and GOMAXPROCS tuning). If you rely on that behavior, you may need to configure GOMAXPROCS explicitly in your environment or deployment. Most users will see no impact.

• enhancementImport future.keywords.not to fix negation semantics in composite expressions

  OPA v1.17.0 introduces a new `future.keywords.not` import that fixes a long-standing semantic bug where negation of composite expressions (`not f(g(input.x))`) would fail silently if any intermediate value was undefined, instead of correctly succeeding. With the import enabled, undefined intermediates no longer cause rule failure. If your policies rely on negation of complex expressions where inputs or function results might be undefined, import `future.keywords.not` to fix unintuitive failures. This is a behavioral change that may affect policy evaluation, but in the direction of correctness.

• enhancementUpdate decision log parsing for new rule_labels array format

  Decision logs now include a new top-level `rule_labels` array that collects labels from all successfully evaluated rules in a single entry, with inner-scope-wins precedence (rule > document > package > subpackages). This replaces the previous behavior of one log entry per label-contributing scope. If you parse or query decision logs by rule labels, update your log parsing logic to read from `rule_labels` as an array of merged label maps rather than individual scope-level entries. This change simplifies label aggregation and is now processed by default in both runtime and Go SDK.

Rook v1.18.11 patches liveness probe stability, OSD disk handling, and CSI priority class assignment. No major breaking changes, but one CSI component fix may shift pod scheduling.

• breakingCSI priority class name correction

  CSI provisioner and plugin priority class names were swapped in earlier v1.18.x releases (PR #17361). If you've set custom CSI priority classes, check your PVCs and plugin pods after upgrade — the correct priority class will now apply to the right component, potentially changing scheduling behavior for storage workloads.

• enhancementFix liveness probe script formatting

  Rook v1.18.11 removes newlines from liveness probe scripts (PR #17420). If your Ceph cluster's liveness probes are flaky or generating spurious restarts, upgrade immediately — the whitespace issue could be interfering with probe output parsing. No breaking changes, but the fix eliminates a source of operational noise.

• enhancementDisk zapping for forced OSD installation

  The disk zapping feature for forced OSD installation (PR #17533) gives you explicit control over device reuse. If you're adding storage to existing nodes or recovering failed OSD slots, update to v1.18.11 and review your OSD discovery workflow — you can now force installation on previously used disks without manual intervention.

Falco 0.44.0 drops three long-deprecated features (gRPC output, gVisor engine, legacy BPF probe) and adds expressive rule engine improvements. Deployments using any of these must migrate before upgrading.

• securityfalco-webui restricted to local access — check external tooling

  The falco-webui Docker service now restricts access to localhost only. If you had it exposed on a broader interface, that changes on upgrade. This is a net positive for most deployments, but verify any tooling or dashboards that reached the webui over the network still work after the upgrade.

• breakingThree features dropped — check your config before upgrading

  Three major removals land in this release: gRPC output/server, gVisor engine, and the legacy BPF probe. If you rely on gRPC-based output consumers, you need an alternative output path (e.g., JSON over HTTP, or a sidecar) before upgrading. gVisor users must switch to a supported engine. Legacy BPF users should move to the modern eBPF probe. Audit your current config for any of these before touching 0.44.0 in production.

• enhancementRicher rule syntax — review custom rules for validation errors

  The rule engine now supports oneof/allof/anyof string comparator modifiers, and rules can use list transformer exceptions. These let you write tighter, more expressive detection rules without duplicating conditions. If you maintain custom rules, review whether these can replace existing workarounds. Also, Falco now validates unknown keys in rules — so rule files with typos or unsupported fields will produce warnings or errors instead of silently being ignored.

v0.153.0 stabilizes seven feature gates (breaking), fixes a critical memory corruption bug in gRPC Snappy compression, and ships several mdatagen enhancements for component authors.

• securityUpgrade immediately if you use gRPC with Snappy compression

  The Snappy fix in configgrpc addresses memory corruption that can cause fatal errors — this is a process-crash-level issue, not just a performance concern. If your exporters or receivers use gRPC with Snappy compression enabled, treat this as a priority upgrade. Check your exporter configs for compression: snappy settings.

• breakingAudit your feature gate overrides before upgrading

  All seven stabilized gates are now permanent behavior — you can no longer toggle them. If your collector config or startup flags reference configoptional.AddEnabledField, confmap.newExpandedValueSanitizer, exporter.PersistRequestContext, otelcol.printInitialConfig, pdata.useCustomProtoEncoding, telemetry.UseLocalHostAsDefaultMetricsAddress, or pdata.enableRefCounting, remove those references or the collector will fail to start. The metrics address change (UseLocalHostAsDefaultMetricsAddress) is the one most likely to surprise teams — your metrics endpoint is now localhost-bound by default.

• breakingmdatagen reaggregation config is now on by default

  If you maintain custom collector components using mdatagen, the reaggregation config fields are now generated by default. To preserve the old behavior (metrics config with only the enabled field), explicitly set reaggregation_enabled: false in your metadata.yaml. Run mdatagen on your components after upgrading and review the generated output before committing.

Crossplane v2.3.0 ships a high-fidelity local render engine, per-resource reconciliation control, alpha Provider deletion protection, and multiple security dependency bumps including Go stdlib CVE fixes.

• securityGo stdlib CVEs fixed — pull the new image

  Go was bumped to 1.25.10 specifically to address stdlib CVEs, on top of several other dependency security patches (grpc, go-git, go-jose, cloudflare/circl, golang.org/x/net). Update your Crossplane deployment to v2.3.0 promptly; if you mirror images internally, make sure the new digest is pulled before rolling out.

• breakingUpdate API import paths and bookmark the new CLI repo

  If you import Crossplane APIs in Go code, change `github.com/crossplane/crossplane/v2/apis` to `github.com/crossplane/crossplane/apis/v2` and note that `v1.Resource*` types are now `v2.ClusterManagedResource*`. Pin your CLI tooling to the new `github.com/crossplane/cli` repo — version numbers will diverge from core after this release, so update any scripts or CI pipelines that assumed aligned versioning.

• breakingUpgrade sequentially from v2.2 — do not skip minor versions

  Crossplane migrates CRDs on upgrade, and skipping minor versions can leave the API server in an inconsistent state. If you are on v1.20, that branch receives extended support but you should plan your migration to v2.x. Always follow the sequential upgrade path documented in the Crossplane upgrade guide.

• enhancementUse per-resource poll annotations to reduce API server load

  Set `crossplane.io/poll-interval: 24h` on stable, infrequently-changing XRs to dramatically cut reconcile frequency. Pair it with `crossplane.io/reconcile-requested-at` to trigger on-demand reconciliation when needed. This is available immediately for XRs; for managed resources, wait for your providers to release versions based on crossplane-runtime v2.3.0 before relying on it.

• enhancementEnable Provider deletion protection in non-prod first

  The new `--enable-provider-deletion-protection` alpha flag auto-creates `ClusterUsage` resources that block Provider deletion while managed resources exist. Useful safety net in shared clusters. Enable it in staging environments first to validate that your existing `ClusterUsage` webhook setup handles the auto-created resources correctly before rolling to production.

wasmCloud v2.2.0 adds WASI Preview 3 TLS support, a customizable HTTP outgoing request handler, and several operator fixes for namespace-scoped deployments.

• breakingOperator users with `watchNamespaces` must verify RBAC after upgrade

  The fix for namespace-scoped role usage in the runtime operator changes which role bindings are applied when `watchNamespaces` is set. After upgrading, confirm your operator's RBAC permissions are correct and that it can still watch resources in the intended namespaces. A misconfigured role here means silent failures in component reconciliation.

• enhancementUse `wasi:tls` for native TLS in Wasm components

  WASI Preview 3 TLS support means you can now handle TLS connections directly inside Wasm components rather than relying on host-side termination or workarounds. If you're building components that make secure outbound connections, test against the new `wasi:tls` interface. This is early-stage — treat it as experimental in production until the WASI spec stabilizes further.

• enhancementUnblock CI pipelines with `--non-interactive` in `wash new`

  If you've been working around interactive prompts in `wash new` inside CI, this fix removes that friction. Update your pipeline scripts to use `--non-interactive` cleanly — no hacks required. Also worth re-examining your `wash config` flows now that validation and cleanup are built in.

containerd 2.0.9 patches CVE-2026-46680 and fixes a TOCTOU race in tar extraction, lost container exit events on restart, and several security hardening issues.

• securityPatch CVE-2026-46680 now

  A security vulnerability tracked as CVE-2026-46680 is fixed in this release. Any containerd 2.0.x deployment should be upgraded to 2.0.9 immediately. Check the GHSA advisory for affected configurations and severity before scheduling maintenance windows — this shouldn't wait.

• securityTOCTOU fix in tar extraction reduces image unpack risk

  The TOCTOU race during tar extraction could be exploited with a crafted image layer to escape expected paths. This is relevant for any environment pulling untrusted or third-party images. Upgrade and consider auditing your image pull policies if you haven't already restricted sources.

• breakingCheck AppArmor configs if running pre-3.0 AppArmor

  The AppArmor ABI field is now set conditionally, so systems running AppArmor older than 3.0 won't have an incompatible ABI injected into generated profiles. If you've been working around this with custom profiles, test your AppArmor setup after upgrading to confirm behavior is as expected.

• enhancementFix for lost exit events matters for high-churn workloads

  If you've seen containers stuck in unexpected states after a containerd restart — particularly in Kubernetes environments with rapid pod cycling — this fix addresses the root cause. No config change needed; upgrading is enough.

containerd 1.7.32 is a security-focused patch addressing CVE-2026-46680, plus hardening the default seccomp profile by blocking AF_ALG sockets and fixing OCI spec USER handling.

• securityPatch CVE-2026-46680 now — upgrade to 1.7.32

  CVE-2026-46680 is the primary driver for this release. Details are in the containerd security advisory. If you're running any 1.7.x version, treat this as a mandatory upgrade. Check the advisory for severity and attack surface before deciding on your maintenance window — but don't defer this long.

• securityAF_ALG is now blocked in the default seccomp profile — verify custom profiles

  The default seccomp policy now blocks the AF_ALG (kernel crypto) socket family. Containers relying on AF_ALG for hardware crypto offloading will break after this upgrade. Audit your workloads — most standard containers won't be affected, but custom crypto or HSM-adjacent workloads might. If needed, override via a custom seccomp profile rather than relaxing the default.

• breakingOut-of-range USER values now fail explicitly — check your container images

  Previously, an out-of-range UID/GID in the OCI spec could silently trigger name lookups with unpredictable results. Now containerd returns an error. If you have images or specs with numeric USER values outside valid range, containers will fail to start instead of behaving unexpectedly. Run a pre-upgrade check on your image inventory, especially anything using high numeric UIDs.

• enhancementAppArmor < 3.0 compatibility restored — relevant for older distros

  If you're running containerd on Ubuntu 20.04, Debian Bullseye, or any distro shipping AppArmor 2.x, earlier 1.7.x releases may have caused AppArmor profile load failures. This fix conditionally omits the abi directive. Upgrade and verify AppArmor profile loading if you've been seeing related errors.

containerd 2.3.1 patches CVE-2026-46680 and fixes several runtime/snapshotter bugs including seccomp hardening that blocks AF_ALG sockets by default.

• securityPatch CVE-2026-46680 now — upgrade from 2.3.0

  CVE-2026-46680 is fixed in this release. Details are in the containerd security advisory. If you're on 2.3.0, treat this as a mandatory upgrade. Check your package manager or deployment pipeline to roll out 2.3.1 across all nodes before the vulnerability details are widely circulated.

• securityAF_ALG blocked in default seccomp policy — test workloads that use kernel crypto

  The default seccomp profile now blocks AF_ALG (Linux kernel crypto API via sockets). Most containerized applications won't touch this, but anything using AF_ALG directly for cryptographic operations will break. Before upgrading in production, verify your workloads don't rely on AF_ALG — run a quick strace or audit your application's socket calls. Custom seccomp profiles are unaffected.

• breakingNon-runc runtime users: test sandbox task API behavior after upgrade

  The sandbox task API endpoint fix and deprecation of task fields in Runc options targets non-runc runtime setups (e.g., Kata Containers, gVisor). If your cluster uses alternative runtimes, validate that container creation and task management still work as expected post-upgrade. The deprecation of task fields means you should audit any custom Runc options configs to remove deprecated fields before they're removed in a future version.

v1.16.0 patches a critical OIDC token rejection bug after key rotation, fixes two correctness bugs in experimental weighted_graph_check, and updates Go to address stdlib CVEs.

• securityUpdate immediately if using OIDC auth or any Go stdlib CVEs apply

  Two separate security concerns here. First, the OIDC JWKS refresh fix means deployments that rotate issuer keys were silently rejecting valid tokens — if you've seen 401s after a key rotation, this is why. Second, the Go 1.24.3 update patches stdlib vulnerabilities; review the Go 1.24.3 release notes to assess exposure. Upgrade to v1.16.0 promptly in both cases.

• breakingweighted_graph_check users: validate results after upgrading

  Two correctness bugs were fixed in the experimental weighted_graph_check feature. Cache key collisions and false-negative caching from cancelled goroutines mean prior versions could return incorrect 'false' results. If you're running this in any meaningful capacity, run a validation pass against known-good authorization scenarios after upgrading to confirm behavior is now correct.

• enhancementConfigure PingTimeout to catch datastore connectivity issues faster

  The new PingTimeout and PingRetryMaxElapsedTime config options give you explicit control over how long OpenFGA waits to confirm datastore connectivity at startup and during health checks. Set these to values aligned with your SLOs — tighter timeouts surface infrastructure problems earlier instead of letting the server spin up against a degraded datastore.

Patch release fixing sandbox task API endpoints broken for non-runc shims — critical for anyone running alternative runtimes like Kata Containers or gVisor.

• breakingUpgrade if you run non-runc runtimes in sandbox mode

  The bug in api/v1.11.0 caused sandbox task API endpoints to malfunction for any shim that isn't runc — think Kata Containers, gVisor, or custom shims. If your cluster uses these runtimes and you're on 1.11.0, task operations against sandboxed workloads may silently fail or misbehave. Update to api/v1.11.1 immediately and verify task lifecycle operations (create, delete, exec) work correctly post-upgrade.

• enhancementValidate your shim compatibility after upgrading

  The fix adds the task API address to CreateTaskRequest at the proto level. If you maintain a custom shim, review whether your implementation reads this field — it's now populated where it wasn't before. No action needed for standard runc workloads, but non-standard shim authors should test task creation flows against this API version.

NATS v2.14.1 is a substantial patch release fixing ~30 bugs across JetStream, clustering, and core messaging — several of them data-integrity and panic-level issues worth deploying promptly.

• securitygolang.org/x/crypto bumped to v0.51.0 — update now if you embed nats-server

  The x/crypto and x/sys dependency updates often carry CVE fixes. If you embed nats-server as a Go library (common in edge/IoT deployments), rebuild and redeploy. For standard deployments, just upgrade the binary. Don't sit on this one — crypto library updates in a messaging server are not optional hygiene.

• breakingReview the 2.14 Upgrade Guide before deploying — 2.13.x was skipped

  The release notes explicitly reference backwards-compatibility notes against 2.12.x, not 2.13.x, because that minor version was never released. If your team is running 2.12.x and skipped 2.13.x, read the 2.14 upgrade guide carefully before rolling out. Pay attention to JetStream consumer and stream API changes that may affect your clients.

• enhancementUse the new client-traffic /varz metrics for baseline observability

  The four new metrics (in/out client msgs/bytes) give you a cleaner split between client traffic and internal cluster/leafnode chatter. Wire these into your Prometheus scrape or monitoring dashboard now to establish baselines. This is especially useful for capacity planning on servers that handle mixed client and cluster traffic, since previously you had to infer client load from total metrics.

v2.12.9 is a dense bug-fix release targeting JetStream stability — covering Raft correctness, consumer state corruption, and filestore encryption bugs that could silently corrupt data.

• securityUpdate: golang.org/x/crypto bumped to v0.51.0

  The x/crypto dependency was updated alongside Go 1.25.10. If your org tracks CVEs against transitive dependencies, verify your SBOM tooling picks this up. Upgrade to v2.12.9 to pull in the patched crypto library — there's no workaround at the application level.

• breakingEncrypted JetStream users must upgrade — filestore corruption risk

  A bug in filestore encryption mode conversion could cause block-level corruption when switching encryption settings (PR #8105, #8166). If you've ever changed encryption mode on an existing stream, inspect those streams after upgrading. If corruption already occurred, you'll need to restore from a pre-conversion snapshot.

• enhancementUse the new /varz client traffic metrics for capacity planning

  The four new metrics (in/out_client_msgs and in/out_client_bytes) let you separate actual client-facing load from internal cluster/leafnode traffic. Wire these into your Prometheus scrape now — they're directly useful for right-sizing clusters and spotting noisy clients without needing to parse per-connection data.

Flux v2.8.8 patches two go-git CVEs in source and image-automation controllers, fixes a memory leak in helm-controller, and adds GCP sovereign cloud registry support.

• securityUpgrade immediately to patch two go-git CVEs

  CVE-2026-45571 and CVE-2026-45570 affect source-controller and image-automation-controller. Both are fixed in go-git v5.19.1 bundled with this release. If you run either of these controllers — and most Flux installations do — upgrade to v2.8.8 now. There's no workaround short of disabling those controllers.

• breakingReview charts that place non-CRD resources under crds/ directory

  Helm-controller previously force-applied any object found under a chart's crds/ directory, not just actual CRDs. That behavior is now corrected. If you have Helm charts (especially community or third-party ones) that bundle non-CRD manifests under crds/ as a workaround for install ordering, those objects will no longer be force-applied. Audit your HelmRelease resources and test in a non-production environment before rolling this out broadly.

• enhancementInvestigate artifact fetch timeouts if reconciliations have been stalling

  The new configurable HTTP timeout for artifact fetching directly addresses indefinite blocking during fetches. If you've seen helm-controller or source-controller reconciliations hang without clear errors, this fix likely explains it. After upgrading, configure the timeout explicitly rather than relying on defaults — check the helm-controller v1.5.5 changelog for the specific field name. Also worth auditing memory usage before and after upgrade if your helm-controller pods have been growing steadily in memory.

Emissary-Ingress v4.1.0 ships Envoy 1.37.2 and fixes a stale cache bug that caused Istio mTLS cert rotation to silently fail.

• securityReview Envoy 1.37.x release notes before upgrading

  This upgrade spans Envoy 1.37.0 through 1.37.2, which includes security patches and potentially deprecated xDS fields. Pull up the Envoy 1.37.0, 1.37.1, and 1.37.2 changelogs and scan for any deprecated API fields or behavior changes that match your current Mapping/Ambassador configs before rolling out to production.

• breakingStale config cache fix may change startup behavior

  The IR.check_deltas fix now triggers a full reconfigure when an empty-delta snapshot arrives with a cached state. In practice this means Emissary will re-push config to Envoy in scenarios where it previously did nothing. If you have automation or health checks that depend on the old (broken) quiet behavior during cert rotation windows, validate them in staging first.

• enhancementUpgrade if you run Emissary alongside Istio

  If your cluster uses Istio and Emissary together, this fix directly addresses mTLS cert rotation failures (issue #4744). Stale certificates staying in the cache caused silent connectivity breakage during rotation events. Upgrading to v4.1.0 should eliminate those intermittent failures without any config changes on your part.

v1.51.0 lands six breaking changes alongside major catalog performance wins, a new AiResource entity kind, and MCP/OIDC hardening. Plan migration time before upgrading.

• breakingRun catalog DB migration SQL before deploying to large installs

  The new catalog migration adds covering indices and a UNIQUE constraint on the search table, which can be slow on large datasets. The release notes explicitly recommend running the provided SQL commands manually before deploying v1.51.0. Skipping this turns a controlled maintenance window into an uncontrolled deployment stall. Check the changelog for the exact SQL before you upgrade.

• breakingAudit six breaking changes before upgrading — OIDC and MsgGraph need immediate config review

  The OIDC CIMD/DCR patterns changed from wildcard '*' to specific MCP client defaults — any custom MCP clients will silently stop working unless you explicitly add their patterns to the allow list. Separately, Microsoft Graph now excludes disabled user accounts; if your org tracks disabled users in Backstage, add an explicit filter before upgrading. Also migrate NavItemBlueprint usages to PageBlueprint title/icon params, and update PolicyQueryUser code to use credentials instead of the removed token/expiresInSeconds fields.

• enhancementAdopt incremental Microsoft Graph ingestion for large orgs

  The new msgraph-incremental module processes users and groups one page at a time and persists cursor state, meaning a pod restart no longer forces a full re-ingest. For orgs with tens of thousands of users, this is a practical operational improvement worth switching to. Install the new module and migrate your provider config — the old MicrosoftGraphOrgEntityProvider remains available but holds the full dataset in memory.

v0.152.1 is a bug-fix-heavy release with one useful new metric. The most operationally impactful changes are snappy decompression security fixes and a Prometheus metric naming regression fix.

• securityconfighttp snappy fixes limit memory exposure from compressed payloads

  Three snappy decompression fixes land in `pkg/confighttp`: body is now closed after reading, panics in decompression libraries return HTTP 400 instead of crashing with 500, and `max_request_body_size` is enforced before the decoded buffer is allocated. The size-check fix in particular prevents a potential memory spike from a maliciously crafted compressed payload. If you accept compressed OTLP over HTTP from untrusted sources, upgrade.

• breakingPrometheus metric name format may change if you customized telemetry host

  If you explicitly set the `host` field in the telemetry metrics section of your collector config, check whether your Prometheus metric names changed after upgrading to recent versions. The bug caused `WithoutScopeInfo`, `WithoutUnits`, and `WithoutTypeSuffix` to default to false instead of true in that code path, which means your metrics may have had unexpected suffixes or scope labels. This release restores the correct defaults — metric names may shift again on upgrade, so update dashboards and alerts accordingly.

• enhancementAdd in-flight exporter metric to your dashboards

  The new `otelcol_exporter_in_flight_requests` UpDownCounter metric is available in `pkg/exporterhelper`. Add it to your dashboards to see when exporters are queuing up requests or saturating worker pools — it's a direct signal of export backpressure that was previously hard to observe without custom instrumentation.

SPIRE v1.15.0 adds HashiCorp Vault key management, rootless Podman support, and PROXY protocol rate limiting, while promoting sigstore attestation out of experimental. One CLI JSON output change requires attention before upgrading.

• breakingAudit CLI JSON consumers before upgrading

  The CLI no longer wraps objects in slices when printing JSON output. Any scripts, pipelines, or tools that parse SPIRE CLI JSON output will likely break — they expected arrays and will now get single objects. Audit all automation that calls spire-server or spire-agent CLI with JSON output flags before rolling this out. Test in a non-production environment first.

• breakingUpdate metric dashboards for 'bootstrapped' label rename

  The metric label 'bootstraped' (one 'p') was corrected to 'bootstrapped'. Any Prometheus queries, Grafana dashboards, or alerting rules referencing the old misspelled label will silently stop matching after upgrade. Find and update all references before deploying v1.15.0.

• enhancementMigrate to HashiCorp Vault Key Manager if your org already runs Vault

  If your team already operates HashiCorp Vault, the new Vault Key Manager plugin lets you consolidate key storage there instead of managing a separate AWS KMS or Azure Key Vault setup. This is particularly useful for on-prem or multi-cloud deployments where cloud-native KMS options are awkward. Review the plugin configuration docs and plan a key migration window — existing keys in other backends won't auto-migrate.

• enhancementPromote sigstore attestation to production workloads

  Sigstore-based attestation in both the k8s and docker attestors is now stable. If you've been holding off due to the experimental flag, this is the release to enable it for production. Verify your signing workflows are compatible and enable the feature in staging first to confirm selector behavior matches expectations.

v2.9.0 adds HAMi-DRA for NVIDIA (now production-ready), Ascend HAMi-core mode, VastAI support, and patches a scheduler DoS vulnerability. Prometheus metric renames require dashboard updates before upgrading.

• securityPatch scheduler DoS vector and Go security upgrades

  Two scheduler-level security fixes land in this release: an io.LimitReader guard on scheduler HTTP routes to prevent DoS (issue #554), and a Go runtime upgrade to 1.26.2 for upstream security fixes. If you run HAMi scheduler exposed to any untrusted network path, upgrade promptly.

• breakingPrometheus metric names changed — update dashboards before upgrading

  Prometheus metric and label names have been realigned to follow best practices (renamed fields). If you have dashboards or alerts built against HAMi vGPU metrics, audit your metric names after upgrading. The existing dashboard.md has been updated — cross-reference it. The new ServiceMonitor Helm chart options also make scrape config cleaner if you're on the Prometheus Operator stack.

• enhancementHAMi-DRA for NVIDIA is production-ready — start evaluating

  HAMi-DRA (Dynamic Resource Allocation) for NVIDIA is now marked ready for use. If you're on Kubernetes 1.26+ and want finer-grained GPU resource management without relying solely on device plugins, this is the release to start evaluating DRA. Test in a non-prod cluster first — DRA changes how the scheduler sees GPU resources.

Istio 1.30 ships experimental AI-focused agentgateway, ambient mode CIDR support, a new TrafficExtension API, and tightened debug endpoint auth that breaks existing setups.

• breakingDebug endpoint auth is on by default — audit your tooling now

  Port 15010 XDS debug endpoints now enforce authentication with ENABLE_DEBUG_ENDPOINT_AUTH=true as the default. Any internal tooling, dashboards, or scripts hitting syncz or config_dump without credentials will start failing after upgrade. Before upgrading, inventory everything that talks to port 15010 and either add auth or explicitly allowlist namespaces via DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES.

• breakingStart migrating off WasmPlugin to TrafficExtension API

  TrafficExtension is now the primary extensibility API, replacing WasmPlugin. WasmPlugin isn't being removed immediately, but new features will land in TrafficExtension first. If you run Wasm extensions in production, plan a migration window and test TrafficExtension parity before 1.31 hardens the deprecation.

• enhancementUse CIDR ServiceEntry in ambient mode to simplify external IP routing

  Previously, ambient mode required enumerating individual IP endpoints in ServiceEntry. CIDR support means you can now cover entire subnets — useful for external databases, on-prem services, or shared infrastructure with dynamic IPs. If you've been maintaining large lists of individual endpoints, consolidate them now and reduce operational overhead.

Istio 1.29.3 patches two security vulnerabilities — an AuthorizationPolicy bypass and a cross-namespace XDS config leak — alongside a multicluster deadlock fix and AWS EKS ambient mesh probe fix.

• securityAudit AuthorizationPolicy rules using suffix-match principals or namespace selectors — patch immediately

  Regex metacharacters (., [, etc.) in source.principals and source.namespaces were embedded into Envoy SafeRegex unescaped. This means a policy allowing 'spiffe://cluster.local/ns/foo/sa/bar.admin' could inadvertently also match 'spiffe://cluster.local/ns/foo/sa/barXadmin'. Any service with suffix-based wildcard principal matching is potentially affected. Upgrade to 1.29.3 and review policies where principals or namespace values contain dots, brackets, or other regex metacharacters.

• securityRotate access controls on XDS debug endpoints — any authenticated workload could read cross-namespace configs

  The /debug/syncz and /debug/config_dump endpoints served by StatusGen had no namespace boundary enforcement. An authenticated workload in namespace A could enumerate and read Envoy configs of workloads in namespace B. If you run multi-tenant clusters or expose istiod debug endpoints, assume cross-namespace config data may have been accessible. Upgrade immediately and audit who has accessed these endpoints via your API server audit logs.

• breakingMulti-cluster operators: the secret controller deadlock fix may change behavior during cluster updates

  The deadlock in the multicluster secret controller was triggered during remote cluster updates. If your control plane has been experiencing hangs or stalls in multi-cluster scenarios, this fix resolves the root cause — but test your cluster join/leave workflows after upgrading to confirm expected behavior is restored.

Litmus 3.29.0 patches a gRPC CVE, fixes duplicate chaos triggers under concurrent reconciles, and adds Prometheus metrics support for experiment observability.

• securityPatch CVE-2026-33186 by upgrading to 3.29.0 now

  The gRPC library was upgraded to v1.79.3 to fix CVE-2026-33186. If you're running any Litmus version prior to 3.29.0, your control plane is exposed. Upgrade immediately — this isn't a 'schedule it next sprint' situation.

• breakingVerify event-tracker behavior after the duplicate-trigger fix

  The fix for duplicate chaos experiment triggers under concurrent reconciles changes how the event-tracker handles race conditions. If you rely on the event-tracker for automated chaos injection, test your pipelines post-upgrade to confirm expected trigger counts. Duplicate runs may have been masking gaps in your experiment coverage.

• enhancementWire up Prometheus metrics to your existing dashboards

  Prometheus metrics are now natively exposed by ChaosCenter. The release includes a getting-started guide and unit tests, so integration is straightforward. Add Litmus as a scrape target and start tracking experiment pass/fail rates, run durations, and infra connectivity — this fills a long-standing observability gap for chaos workflows.

Kyverno v1.18.1 is a targeted patch fixing two regressions in generate and mutate-existing policies introduced in v1.18.0.

• breakingUpgrade immediately if you use generate policies on cluster-scoped resources

  If you upgraded to v1.18.0 and have GeneratingPolicy rules targeting cluster-scoped resources (ClusterRoles, Namespaces, CRDs, etc.), generation was silently broken. v1.18.1 restores correct behavior. Validate that expected resources were actually generated after upgrading — anything that should have been generated during the v1.18.0 window may need manual remediation or a policy re-trigger.

• breakingMutate-existing policies on v1.18.0 may have produced incorrect results

  The AdmissionRequest context was not being forwarded to UpdateRequests in mutate-existing policies. This means any rule relying on request context (user info, object, oldObject) for conditional logic or patches would have behaved incorrectly. Audit mutations applied while running v1.18.0 and verify affected resources are in the expected state after upgrading to v1.18.1.

• enhancementTreat v1.18.0 as effectively broken for generate and mutate-existing users

  Both fixes were cherry-picked from main, meaning v1.18.0 should be skipped entirely if you rely on either feature. Skip straight to v1.18.1. If you are still on v1.17.x and evaluating the v1.18 line, start your testing against v1.18.1 instead.