Releases

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.

Confidential Containers v0.21.0 patches a moderate guest-components security advisory (GHSA-84rc-2q4r-45pc) and formally advances four deprecations toward removal in v0.22, while bundling Kata 3.31.0, Trustee 0.20.0, and several Trustee/KBS capability additions including gRPC plugins and centralized storage.

• securityPatch guest-components security advisory GHSA-84rc-2q4r-45pc

  GHSA-84rc-2q4r-45pc is a moderate-severity vulnerability in guest-components. Upgrade to v0.21.0 to receive the patch.

• breakingCAA docker provider scheduled for removal in v0.22

  The CAA docker provider, deprecated since v0.20, will be removed in v0.22. Migrate to an alternative provider before the next release.

• breakingFedora-based mkosi-built CAA podvm image scheduled for removal in v0.22

  The Fedora-based mkosi-built CAA podvm image, deprecated since v0.20, will be removed in v0.22. Switch to an alternative image build method.

• breakingPacker-built CAA podvm image scheduled for removal in v0.22

  The packer-built CAA podvm image, deprecated since v0.17, will be removed in v0.22. Update your podvm image build configuration.

• breakingCAA csi-wrapper component scheduled for removal in v0.22

  The CAA csi-wrapper component is deprecated and will be removed in v0.22. Plan to remove or replace this component in your deployment.

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.

SPIRE v1.15.1 fixes a node attestation forgery vulnerability in the azure_imds plugin; anyone using Azure IMDS attestation should patch now.

v1.14.7 patches a critical azure_imds node attestor vulnerability that allowed forged VM identity during node attestation. Mandatory upgrade for any Azure IMDS users.

• securityUpgrade immediately if using azure_imds node attestor

  The azure_imds node attestor had a certificate validation bug: it anchored the PKCS7 certificate bag's first cert to Azure roots, but verified the signature against a separate signer cert from SignerInfo. An attacker could slip a real Azure cert into the bag alongside content signed by an unrelated cert, getting a forged node attestation accepted. If you use Azure IMDS node attestation, treat this as a mandatory upgrade — an attacker with network access could impersonate arbitrary Azure VMs during node attestation.

• enhancementDependency updates bundled in this release

  golang.org/x/net, golang.org/x/crypto, and go-jose/v4 are all updated alongside Go 1.26.3 toolchain. These dependency updates are routine but include security fixes in the upstream packages. No action needed beyond upgrading SPIRE.

Contour v1.33.5 is a security patch: it closes a JWT verification bypass that was possible when fallback certificates were combined with JWT-protected HTTPProxy routes.

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.

OpenFGA v1.16.1 is a bug-fix and security patch release, mainly hardening the experimental weighted_graph_check algorithm and updating grpc-health-probe for Go std lib CVEs.{}}}}} ,

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.

Argo CD v3.3.11 is a routine patch release on the 3.3 branch, bundling six bug fixes and one dependency security update (CVE-2026-41240).

• securityPatch dompurify CVE in Argo CD UI

  This patch bumps redoc/dompurify to v3.4.0 in the UI to fix CVE-2026-41240. If you run the Argo CD UI, upgrade to v3.3.11 to close this XSS-related dependency vulnerability.

• enhancementFixes for controller startup race and nil pointer crash

  A race condition could raise an InvalidSpecError during application controller startup, and a nil pointer dereference existed in removeWebookMutation() from gitops-engine. Both are fixed here; upgrade if you've seen spurious spec errors or controller crashes on startup.

Argo CD 3.4.3 is a patch release fixing a UI XSS CVE (CVE-2026-41240 via dompurify), a controller startup race, a webhook nil-pointer crash, and several CLI/UI bugs.

• securityPatch CVE-2026-41240 in the UI (dompurify bump)

  dompurify was bumped to v3.4.0 to fix CVE-2026-41240. If you're running Argo CD 3.4.x with the web UI exposed — especially to less-trusted users — upgrade to 3.4.3 promptly. Check whether your current version is behind 3.4.3 and roll it out during your next maintenance window or sooner if the UI is internet-facing.

• enhancementFix startup race condition and nil-pointer crash in webhook mutation

  A race condition in application controller startup could trigger InvalidSpecError incorrectly, and a nil pointer dereference in removeWebhookMutation() could cause crashes. Both are fixed here. If you've seen spurious errors at controller startup or webhook-related panics, 3.4.3 addresses them directly.

• enhancement'app wait' no longer hangs when app is already synced

  'app wait' now returns immediately when the app is already in the desired state, instead of blocking. If you use 'app wait' in CI/CD pipelines or scripts as a sync gate, this means faster pipeline runs when apps are already healthy — no code changes needed, just upgrade.

Rook v1.19.6 is a targeted patch release addressing OSD device class handling, Prometheus metric labeling, and a network-layer dependency vulnerability. Mainly operational refinements for Ceph clusters already in production.

• securityPatch golang.org/x/net vulnerability

  Rook v1.19.6 bumps golang.org/x/net twice (to fix govulncheck CI failures and address GO-2026-5026). If you run Rook in high-traffic environments or handle untrusted network input, review the golang.org/x/net advisory for the specific vulnerability. Upgrade to 1.19.6 to inherit the patched dependency, but do not delay if your Rook instance exposes networking logic to untrusted sources.

• enhancementOSD device class detection fixed in raw-mode

  OSD device class handling now works correctly in raw-mode prepare and reconcile operations (#17407). If you use device classes to segregate fast (NVMe) from slow (HDD) storage, verify after upgrading that your OSD topology reflects the correct device classes. Check `ceph osd crush tree` and OSD weight distribution to ensure placement rules work as intended.

• enhancementCluster label added to Prometheus metrics

  Prometheus scrape metrics now include a `cluster` label from upstream Ceph rules (#17544). If you aggregate Rook metrics across multiple Ceph clusters, this label addition improves metric cardinality and avoids collisions. Update any Prometheus rules, dashboards, or alerts that rely on the old label set; test in non-production first to catch any PromQL query breaks.

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.

A pure security patch release: 50+ Linux kernel CVEs patched via a jump to kernel 6.12.91, plus updated CA certificates. No feature changes.

• securitySchedule node reboots promptly — 50+ kernel CVEs patched

  This release patches a large batch of kernel CVEs, including several from 2025 and some tagged 2026 (likely pre-publication assignments). The sheer volume suggests broad attack surface coverage across networking and driver subsystems. Flatcar uses automatic updates by default, but if you've disabled auto-reboot or use a maintenance window controller like FLUO or Kured, verify that nodes are cycling through the update. Clusters where nodes haven't rebooted recently are carrying all of these exposures.

• securityCA certificate bundle updated to NSS 3.124 — verify custom PKI setups

  The ca-certificates update to NSS 3.124 may add or distrust specific root CAs. If your workloads pin to system trust stores or you've layered custom CA bundles on top of the system bundle, test after the node update to confirm TLS handshakes still succeed. This is low-risk for standard setups but can quietly break internal services that rely on specific intermediates.

• enhancementConfirm your update group is tracking stable, not pinned to a fixed version

  With patch-only releases like this, the fastest path to safety is having nodes enrolled in the stable channel with automatic updates enabled. If you pinned a specific image version for consistency, this is a good moment to re-evaluate — security-only patch releases are exactly the scenario the auto-update mechanism is designed for. Check your Container Linux Config or Butane spec to ensure the update strategy isn't set to 'off'.

Flatcar LTS 4081.3.8 is a security-focused update that bundles 12 kernel releases (6.6.128-6.6.141) worth of CVE fixes plus a ca-certificates refresh. No feature or config changes — just patch and move on.

• securityUpgrade from 4081.3.7 without delay

  This release rolls up 12 kernel point releases (6.6.128 through 6.6.141) covering several hundred CVEs, mostly memory-safety and use-after-free fixes across drivers, filesystems, and networking subsystems. If you're running LTS 4081.3.7 or earlier, treat this as a mandatory upgrade rather than routine maintenance given the sheer volume of kernel-level fixes since the last release.

• enhancementCheck TLS trust store assumptions after ca-certificates bump

  ca-certificates moved to NSS 3.124 (including 3.123.1). If you pin certificate bundle versions or vendor your own trust store on top of Flatcar, verify your TLS validation still works as expected after the update, since NSS releases occasionally drop or distrust certain root CAs.

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.

v1.20.8 is a security-only patch for the v1.20 line, bumping Go to 1.25.10 and patching multiple dependency CVEs across go-git, golang.org/x/net, x/crypto, and docker/cli.

• securityUpgrade v1.20 clusters to v1.20.8 now — multiple CVEs addressed

  This patch covers a broad sweep of dependency CVEs: go-git (two separate fixes), golang.org/x/net, golang.org/x/crypto, docker/cli, and in-toto-golang, plus Go stdlib CVEs via the 1.25.10 runtime bump. If you're running any v1.20.x version below this, you're exposed. The go-git and x/crypto vulnerabilities are particularly relevant if your Crossplane setup pulls packages from Git repositories. Plan the upgrade soon — this is not a 'schedule it next sprint' situation.

• enhancementConsider moving to v1.21+ if still on v1.20

  The v1.20 line is receiving security backports, but it won't get feature improvements. If you've been holding on v1.20 for stability reasons, this patch is a good opportunity to audit your upgrade blockers. The v1.21 line has been out long enough to be considered stable, and staying on an older minor version means you'll keep chasing security patches like this one.

v2.1.6 is a security-focused patch for the v2.1 line, bumping Go to 1.25.10 and patching several vulnerable dependencies including go-git, golang.org/x/crypto, and OpenTelemetry.

• securityUpgrade to v2.1.6 immediately if running v2.1.x

  This release patches multiple CVEs across Go stdlib, go-git, x/crypto, and x/net. These aren't theoretical risks — go-git vulnerabilities can affect package fetching behavior, and x/crypto/x/net issues can expose TLS and HTTP handling. If you're on any v2.1.x release, upgrade now. No API or behavioral changes are included, so the upgrade is low-risk.

• securityCheck your provider images for the same vulnerable dependencies

  Crossplane core is patched, but your installed providers (AWS, GCP, Azure, etc.) are separate images with their own dependency trees. Run a container image scan (Trivy, Grype) against your active provider pods to check if they carry the same vulnerable versions of go-git or x/crypto. Provider maintainers will need to release their own patches.

Pure security patch release: Go runtime bumped to 1.25.10 and several dependencies updated to address stdlib CVEs and git-related vulnerabilities.

• securityUpgrade to v2.2.2 immediately if running v2.2.x

  This release is entirely security-driven. Go 1.25.10 patches stdlib CVEs, go-git v5.19.1 addresses git-related vulnerabilities, and x/crypto v0.52.0 closes cryptographic issues. No feature or behavioral changes are included, so the upgrade risk is minimal. If your team scans images or has compliance requirements, staying on v2.2.1 or earlier will trigger findings — update now.

• securityCheck scanner results against the new image digest

  The go-git library was patched twice in quick succession, which suggests active exploitation pressure on that attack surface. After upgrading, re-run your vulnerability scanner against the new Crossplane image digest to confirm all findings are cleared. Pay particular attention to any CVEs tagged against git operations or supply-chain tooling, since in-toto-golang was also updated.

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.