RATATOSKRATATOSK
Sign in

Releases

AI-analyzed release notes for CNCF graduated and incubating projects.

May 2026Clear ×

Karmada

Orchestration & ManagementMay 30, 2026

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.

Key changes (6)
  • Mandatory upgrade path: must be on v1.17.3+ before upgrading to v1.18.x (karmada-operator-chart requirement)
  • New OverflowClusterAffinities API in PropagationPolicy enables progressive spill-over from primary to supplementary cluster groups with automatic reverse contraction on scale-down
  • SchedulingOvercommitProtection feature gate (default: off) prevents resource over-commitment in rapid back-to-back scheduling by caching assumed workloads in the scheduler
  • Deprecated gRPC fields in karmada-scheduler-estimator (resourceRequest, nodeAffinity, tolerations) replaced by *Bytes equivalents for Kubernetes 1.35+ compatibility
  • Removed: --cluster-lease-duration, --cluster-lease-renew-interval-fraction flags; cluster/cluster_name Prometheus labels replaced by member_cluster; Etcd.Local.InitImage config field
  • Critical bug fixes: scheduler mis-routing bindings to backoffQ, silent eviction task drops under concurrent controller writes, ClusterTaintPolicy dropping concurrent health taints
Source

OpenCost

ObservabilityMay 29, 2026

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.

Key changes (7)
  • Security: vulnerable Go dependencies patched (GHSA-xmrv-pmrh-hhx2, CVE-2026-34986)
  • MCP server now opt-in via MCP_SERVER_ENABLED=false default
  • OVH cloud provider added; DigitalOcean and Oracle/Karpenter pricing fixes
  • AWS Spot Price History API now cached; toggle added to disable spot data feed entirely
  • Memory leak fixed in scrape target parsing; CPU usage counter overflow protection added
  • Container images now signed with cosign and include SLSA provenance attestations
  • CUR 2.0 support added for AWS cost data ingestion
Source

Confidential Containers

SecurityMay 29, 2026

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.

Key changes (5)
  • Security fix: guest-components advisory GHSA-84rc-2q4r-45pc patched
  • Four deprecations advancing to removal in v0.22: CAA docker provider, Fedora-based mkosi-built CAA podvm image, packer-built CAA podvm image, CAA csi-wrapper
  • Kata Containers updated to 3.31.0; Trustee and guest-components to 0.20.0 with KBS protocol v0.4.0
  • KBS adds resource deletion support on some storage backends; Trustee gains gRPC plugin interface and centralized storage backend
  • TPM verifier reports AK as TCB claim; Trustee improves TLS, TDX, SE support and multi-device attestation; RVPS adds basic CoRIM support; Attestation Agent better reports supported TEEs
Source

Kubescape

SecurityMay 29, 2026

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.

Key changes (6)
  • Partial GVR (resource type) collection failures are now surfaced instead of silently suppressed, and ScanCoverage reflects failed/not-evaluated controls
  • New --fail-coverage-below flag and kubescape diff command for CI coverage gating and report comparison
  • New --hide flag and anonymization pipeline scrub resource names, namespaces, labels, annotations, and container metadata from output
  • fix command now requires explicit opt-in to push images (previously pushed by default)
  • Multiple Prometheus output fixes: missing HELP/TYPE headers added, score/metrics writes routed to correct writer, duplicate headers deduplicated
  • K8s resource collection parallelized for performance, and a TOCTOU race in TimedCache was fixed
Source

Dapr

Orchestration & ManagementMay 28, 2026

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.

Key changes (4)
  • Workflow retention reminders for superseded runs now drain silently instead of retrying every second indefinitely
  • Stuck workflows on existing 1.17 deployments auto-recover after sidecar upgrade to 1.17.8 — no manual intervention required
  • Sentry OIDC `handleDiscovery` no longer honors `X-Forwarded-Host` unless `--oidc-allowed-hosts` is explicitly configured
  • OIDC issuer and jwks_uri now fall back to `r.Host` only when no allowlist is set
Source

SPIRE

SecurityMay 28, 2026

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.

Key changes (4)
  • Critical fix in azure_imds server node attestor: PKCS7 certificate chain validation was decoupled from signature verification, enabling forged node attestation
  • Go toolchain updated to 1.26.3
  • golang.org/x/net bumped to v0.55.0, golang.org/x/crypto to v0.52.0
  • go-jose/v4 updated to v4.1.4
Source

Prometheus

ObservabilityMay 28, 2026

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.

Key changes (18)
  • Security: Remote Write rejects snappy payloads with decoded size over 32 MB (DoS fix); STACKIT SD secret leak via /-/config endpoint patched (GHSA-39j6-789q-qxvh)
  • TSDB performance: head chunk range query lookup is now O(1) instead of O(n²); mmap skips clean series, reducing CPU at scale
  • PromQL: new experimental functions start(), end(), range(), step(); rate()/irate()/increase()/resets() updated to use start timestamps behind the use-start-timestamps feature flag
  • Service Discovery: DigitalOcean Managed Databases and Outscale VM added; AWS EC2 SD gains IPv6 support; AWS SD gets optional external_id for ECS/MSK/RDS/ElastiCache
  • Bug fixes: agent WAL race condition patched; scrape panics on malformed histograms fixed; TSDB native histogram query panic fixed; remote_write queue_config now validated at startup
  • UI: time series deletion and tombstone cleanup now available from the Status menu
  • auto-reload-config promoted to stable
  • OTLP gzip body size now capped to prevent decompression abuse
  • SD target updates propagate faster via dynamic backoff instead of static 5s interval
  • Consul SD health_filter fix for Catalog-only fields like ServiceTags
  • prometheus_sd_refresh and prometheus_sd_discovered_targets metrics cleaned up when scrape jobs are removed
  • PromQL warns when sort/sort_by_label used in range queries (no-op in that context)
  • sort/sort_by_label warning in range queries, NaN/infinite duration expressions now rejected
  • Scrape: st-synthesis feature flag added to synthesize start timestamps for cumulative metrics when using Remote Write 2.0
  • promtool query instant gains --header flag
  • aix/ppc64 compilation target added
  • /api/v1/status/self_metrics endpoint added
  • Tracing: OTLP HTTP insecure startup failure fixed
Source

Argo

CI/CD & App DeliveryMay 28, 2026

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.

Key changes (5)
  • Fixed a race condition causing InvalidSpecError during application controller startup
  • Fixed a nil pointer dereference in gitops-engine's removeWebookMutation()
  • Fixed label truncation for deletion hook resources
  • Bumped redoc/dompurify to v3.4.0 in the UI, fixing CVE-2026-41240
  • Removed resourceVersion from server-side diff (ssd) handling
Source

Argo

CI/CD & App DeliveryMay 28, 2026

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.

Key changes (6)
  • CVE-2026-41240 patched: dompurify bumped to v3.4.0 in the UI
  • Fixed race condition causing InvalidSpecError during application controller startup
  • Fixed nil pointer dereference in removeWebhookMutation() in gitops-engine
  • CLI: 'app wait' now exits immediately if app is already in desired state
  • UI: Parameters tab now returns the full source for non-hydrator apps
  • Repo depth setting now honored in gitSourceHasChanges and fetch functions
Source

Rook

Storage & DataMay 27, 2026

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.

Key changes (8)
  • Prometheus rules updated with upstream Ceph changes; cluster label added to all scraped metrics
  • OSD device class now honored in raw-mode prepare and reconcile operations
  • golang.org/x/net patched to fix network-layer vulnerability (GO-2026-5026)
  • Self-signed certificate creation retry logic added for wrapped context deadline errors
  • Node existence checks added to monitor health check iterations
  • Default ResourceRequirements added for cmd-reporter pod
  • Encryption label detection improved for dmcrypt paths
  • DNS policy corrected for rook-ceph-exporter
Source

Flatcar Container Linux

Provisioning & RuntimeMay 27, 2026

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'.

Key changes (4)
  • Linux kernel updated from previous stable to 6.12.91 (incorporating 6.12.88 through 6.12.91 changes)
  • 50+ CVEs addressed in the Linux kernel, spanning networking, drivers, and subsystem components
  • ca-certificates updated to NSS 3.124, refreshing the trusted root CA bundle
  • No userspace or configuration changes — this is a kernel + cert update only
Source

Flatcar Container Linux

Provisioning & RuntimeMay 27, 2026

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.

Key changes (4)
  • Linux kernel updated to 6.6.141, rolling up fixes from 6.6.128 through 6.6.140
  • Hundreds of CVEs patched in the kernel, spanning memory corruption, use-after-free, and out-of-bounds issues across many subsystems
  • ca-certificates updated to include NSS 3.124 and 3.123.1
  • No application-level or Flatcar-specific behavior changes noted beyond the kernel and cert store updates
Source

Falco

SecurityMay 26, 2026

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.

Key changes (7)
  • gRPC output/server support removed — migrate output consumers before upgrading
  • gVisor engine support removed — move to a supported engine if applicable
  • Legacy BPF probe removed — switch to modern eBPF probe
  • New string comparator modifiers (oneof/allof/anyof) in the rule engine
  • Unknown-key validation in rules: malformed rules now surface errors
  • falco-webui Docker service restricted to localhost access only
  • capture_events and capture_filesize stop conditions added for capture files
Source

OpenTelemetry

ObservabilityMay 25, 2026

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.

Key changes (5)
  • Seven feature gates stabilized and removed — including telemetry.UseLocalHostAsDefaultMetricsAddress, otelcol.printInitialConfig, and pdata.enableRefCounting — meaning any code still gating on these will break
  • Critical bug fix: memory corruption and fatal error in configgrpc's Snappy compression (CVE-adjacent, upgrade immediately if you use gRPC with Snappy)
  • pdata.useCustomProtoEncoding feature gate fully removed — no opt-out path remains, custom proto encoding is now always on
  • mdatagen now generates config documentation tables injected into README.md automatically, and enables reaggregation config generation by default
  • New Walker interface in xextension/storage enables storage migration and TTL-based garbage collection patterns
Source

Crossplane

Orchestration & ManagementMay 22, 2026

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.

Key changes (5)
  • Go runtime bumped to 1.25.10 to address stdlib CVEs
  • go-git/go-git updated to v5.19.1 (two sequential security fixes in this release)
  • golang.org/x/net updated to v0.53.0 for security fixes
  • golang.org/x/crypto updated to v0.52.0 for security fixes
  • docker/cli and in-toto-golang also patched for security issues
Source

Crossplane

Orchestration & ManagementMay 22, 2026

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.

Key changes (5)
  • Go runtime bumped to 1.25.10 to address stdlib CVEs
  • go-git updated twice (v5.19.0 → v5.19.1) to resolve security issues in git operations
  • golang.org/x/crypto and golang.org/x/net updated for security fixes
  • OpenTelemetry otel updated to v1.41.0 with security patches
  • in-toto-golang updated to v0.11.0 for supply chain security fixes
Source

Crossplane

Orchestration & ManagementMay 22, 2026

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.

Key changes (5)
  • Go runtime bumped to 1.25.10 to fix multiple stdlib CVEs
  • go-git/go-git updated twice (v5.19.0 then v5.19.1) for security fixes
  • golang.org/x/crypto updated to v0.52.0 for security fixes
  • in-toto-golang updated to v0.11.0 for security fix
  • crossplane-runtime bumped to v2.2.2 to carry the same fixes downstream
Source

Crossplane

Orchestration & ManagementMay 21, 2026

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.

Key changes (6)
  • APIs module split: `github.com/crossplane/crossplane/apis/v2` is now a separate Go module; external consumers must update import paths
  • Crossplane CLI (`crank`) moved to its own repo (`github.com/crossplane/cli`) with an independent release schedule starting after v2.3.0
  • High-fidelity `crossplane render` now runs the real composite reconciler instead of a parallel reimplementation, so local output matches actual cluster behavior
  • New per-resource annotations `crossplane.io/poll-interval` and `crossplane.io/reconcile-requested-at` give fine-grained reconciliation control (XRs immediately; managed resources need provider update to crossplane-runtime v2.3.0)
  • Alpha Provider deletion protection via `--enable-provider-deletion-protection` blocks accidental Provider removal while managed resources still exist
  • Multiple security dependency updates: Go bumped to 1.25.10 fixing stdlib CVEs, plus grpc, go-git, go-jose, cloudflare/circl, and others
Source

containerd

Kubernetes CoreMay 20, 2026

containerd v2.2.4 is a security-focused patch release addressing two CVEs plus several runtime fixes for overlay, sandbox, AppArmor, and seccomp behavior.

  • securityPatch both CVEs — update to v2.2.4 now

    Two CVEs are fixed here: one in containerd itself (CVE-2026-46680) and one in the go-jose dependency (CVE-2026-34986). Both affect production deployments. Don't wait for your next maintenance window — push this update through your standard emergency patch process. If you run containerd on Kubernetes nodes, this applies to all container runtimes backed by containerd regardless of the orchestrator.

  • securityAF_ALG is now blocked by default seccomp — test custom workloads

    The default seccomp profile now blocks AF_ALG (kernel crypto API via sockets). This reduces attack surface, but any workload relying on AF_ALG sockets — unusual but possible in cryptography-heavy or hardware-offload scenarios — will start seeing syscall denials. Run a quick audit of workloads with custom or permissive seccomp profiles before upgrading in production.

  • enhancementUserNS + overlay users should upgrade to fix layer extraction

    If you run rootless containers or pods using user namespaces with the overlay snapshotter, the previous 'rebase' capability caused layer extraction failures. This patch disables that capability automatically in UserNS contexts. No config change needed — just upgrade and verify your rootless workloads mount correctly post-update.

Key changes (5)
  • CVE-2026-46680 patched in containerd core — security advisory on GHSA-fqw6-gf59-qr4w
  • CVE-2026-34986 patched via go-jose bump to v4.1.4 — affects JWT/JWK processing
  • AF_ALG socket family blocked in default seccomp policy, closing a kernel crypto API attack surface
  • Overlay snapshotter disables 'rebase' capability in user namespaces, fixing layer extraction failures
  • OCI spec USER handling now returns explicit errors for out-of-range values instead of silent bad lookups
Source

containerd

Kubernetes CoreMay 20, 2026

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.

Key changes (5)
  • CVE-2026-46680 patched — upgrade immediately, details in the security advisory
  • TOCTOU race condition in tar extraction fixed, reducing potential for path traversal during image unpack
  • AF_ALG socket family now blocked in default seccomp policy, narrowing the kernel attack surface
  • Container exit events no longer dropped when they arrive before CRI info is cached during containerd restart
  • Sandbox service bugs fixed: Create fields forwarded correctly and event topics no longer misconfigured
Source

containerd

Kubernetes CoreMay 20, 2026

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.

Key changes (5)
  • CVE-2026-46680 patched — update immediately if running 1.7.x
  • AF_ALG socket family now blocked in default seccomp socket policy, tightening the default container sandbox
  • OCI spec USER values that are out-of-range now return an explicit error instead of silently triggering unexpected username/group lookups
  • hosts.toml can now contain only root-level fields with no [host] section, fixing a config parsing bug
  • AppArmor abi directive is now set conditionally, restoring compatibility with AppArmor < 3.0
Source

containerd

Kubernetes CoreMay 20, 2026

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.

Key changes (5)
  • CVE-2026-46680 patched — upgrade immediately if running 2.3.0
  • Default seccomp policy now blocks AF_ALG socket family, tightening container isolation
  • Out-of-range USER values in OCI spec now return explicit errors instead of triggering unexpected username/group lookups
  • Sandbox task API endpoints fixed for non-runc runtimes; task fields in Runc options deprecated
  • BoltDB files for metadata and mount plugins now properly closed on server shutdown, preventing resource leaks
Source

OpenFGA

SecurityMay 20, 2026

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.

Key changes (5)
  • OIDC authentication now refreshes JWKS on unknown 'kid', fixing valid token rejections after issuer key rotation (rate-limited to once per minute)
  • Go toolchain updated to 1.24.3 to address Go standard library security vulnerabilities
  • Fixed two bugs in experimental weighted_graph_check: cache key collisions in union resolution and false negatives from cancelled in-flight goroutines
  • weighted_graph_check now falls back to the standard algorithm instead of erroring when v2Check fails
  • New datastore ping timeout configs: PingTimeout and PingRetryMaxElapsedTime for better connection health control
Source

NATS

Networking & MessagingMay 20, 2026

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.

Key changes (5)
  • 30+ bug fixes across JetStream Raft, consumer state, filestore encryption, and cluster routing
  • New /varz metrics (in_client_msgs, in_client_bytes, out_client_msgs, out_client_bytes) for client-only traffic visibility
  • Consumer redelivery drift fixed across multiple paths: workqueue streams, max_deliver, purge/compaction scenarios
  • Filestore block cache corruption on encryption mode conversion patched (critical data integrity fix)
  • TLS handshake timeout logs demoted to debug level, reducing operational noise in busy clusters
Source

NATS

Networking & MessagingMay 20, 2026

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.

Key changes (5)
  • New /varz metrics (in_client_msgs, in_client_bytes, out_client_msgs, out_client_bytes) isolate client-only traffic from internal messaging
  • Fixed filestore encryption mode conversion that caused block-level corruption — critical for encrypted JetStream deployments
  • Fixed multiple consumer redelivered-state drift bugs affecting workqueue/interest streams with max_deliver, purges, and compactions
  • Deadlock fix in cluster info processing under Raft lock contention — relevant for busy clustered deployments
  • Raft correctness improvements: WAL truncation cache invalidation, checkpoint cancellation, truncated entry panics, and unknown peer removal
Source

Flux

CI/CD & App DeliveryMay 20, 2026

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.

Key changes (5)
  • go-git updated to v5.19.1 to address CVE-2026-45571 and CVE-2026-45570 in source-controller and image-automation-controller
  • helm-controller fix: unbounded memory growth from Kubernetes client transport retry wrapper accumulating on every reconcile cycle
  • New configurable HTTP timeout for artifact fetching prevents indefinite blocking and stalled reconciliations in helm-controller
  • helm-controller no longer force-applies non-CRD objects placed under a chart's crds/ directory — a behavioral correction that could affect existing charts
  • GCP sovereign cloud artifact registry support added to source-controller and image-reflector-controller
Source

Emissary-Ingress

Networking & MessagingMay 19, 2026

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.

Key changes (3)
  • Envoy proxy upgraded from 1.36.2 to 1.37.2 (spans three Envoy minor releases)
  • Fixed IR.check_deltas bug: empty-delta snapshots now force a full reconfigure instead of holding stale cache entries
  • Istio mTLS certificate rotation failures caused by the stale cache issue are resolved
Source

OpenTelemetry

ObservabilityMay 19, 2026

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.

Key changes (7)
  • New `otelcol_exporter_in_flight_requests` metric tracks concurrent export requests per exporter, useful for detecting worker pool saturation
  • Three `pkg/confighttp` fixes for snappy decompression: panic recovery (now returns 400), body cleanup, and pre-allocation size enforcement
  • `pcommon.Value.AsString` no longer HTML-escapes `<`, `>`, `&` in map and slice values — output may change if you relied on escaped output
  • Noisy gRPC disconnect messages (`connection reset by peer`) no longer emit at WARN level during normal client disconnects
  • Prometheus config default mismatch fixed: explicitly setting telemetry host no longer silently changes metric name format
  • Return noop tracer provider when no trace processors are configured, avoiding unnecessary overhead
  • API: `xconfmap.Validator` deprecated; migrate to `confmap.Validator` and `confmap.Validate`
Source

Keycloak

SecurityMay 19, 2026

Keycloak 26.6.2 is a security-heavy patch release addressing 16 CVEs spanning session fixation, XSS, access control bypass, redirect URI validation, and cryptographic weaknesses. Upgrade immediately.

  • securityUpgrade immediately — multiple account takeover and data leakage CVEs

    This release patches session fixation (CVE-2026-7507) enabling account takeover, redirect URI bypass (CVE-2026-7504), access token disclosure (CVE-2026-7571), stored XSS in org templates (CVE-2026-37980), and PII enumeration via account resource lookup (CVE-2026-37981). These are not theoretical — they affect standard OIDC flows and admin APIs. Any Keycloak 26.x deployment should be upgraded to 26.6.2 without delay. Check your change management process, but treat this as an emergency patch.

  • securityFreeMarker RCE risk — audit custom login themes before upgrading

    CVE tracked under #47915 allowed FreeMarker templates to instantiate arbitrary Java objects and execute OS commands. If you have custom login themes that accept any user-influenced input in FTL files, audit them now. The fix adds proper expression escaping in JS blocks within FTL pages. After upgrading, test your custom themes to ensure the new escaping doesn't break existing behavior — especially in frontchannel-logout.ftl.

  • securityWebAuthn AAGUID policy bypass — re-verify authenticator enrollment policies

    CVE-2026-6856 allowed packed self-attestation to bypass AAGUID allowlist policies during WebAuthn registration. If you rely on AAGUID restrictions to enforce specific authenticator hardware (e.g., FIDO2 security keys in regulated environments), credentials may have been enrolled that violate your policy. After upgrading, review recently enrolled WebAuthn credentials and consider requiring re-enrollment if strict hardware attestation is a compliance requirement.

Key changes (5)
  • 16 CVEs patched including critical issues: session fixation in OIDC flow (account takeover), redirect URI validation bypass, access token disclosure via forged client data, and stored XSS in organization template
  • WebAuthn AAGUID policy bypass via packed self-attestation fixed — attestation enforcement was not reliable before this patch
  • OIDC introspection endpoint now enforces audience restrictions, preventing claim leakage from lightweight access tokens
  • FreeMarker templates hardened against object instantiation and OS command execution — a serious RCE-class vulnerability in login UI
  • JDBC_PING cluster discovery updated to not break under 26.7 schema changes, easing rolling upgrades
Source

hami

AI & MLMay 19, 2026

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.

Key changes (6)
  • HAMi-core mode added for Ascend devices, with performance optimizations and new benchmarks published
  • HAMi-DRA (NVIDIA) declared production-ready; CDI support added via Volcano-vgpu-device-plugin sync with v0.19
  • Scheduler DoS protection added via io.LimitReader on HTTP routes; Go upgraded to 1.26.2
  • Prometheus metric/label names realigned to best practices — existing dashboards will need updates
  • VastAI device support added; Ascend 910C SuperPod module-pair allocation supported; MIG-in-CDI-mode bug fixed
  • Multiple panic/nil-pointer fixes in scheduler (calcScore, leaderelection, ondelpod) improve stability under edge cases
Source

OpenCost

ObservabilityMay 18, 2026

v1.120.2 is a substantial release with security fixes, memory leak patches, AWS CUR 2.0 support, OVH cloud provider, and supply chain security improvements via cosign image signing.

  • securityUpgrade immediately for CVE-2026-34986 fix

    This release patches GHSA-xmrv-pmrh-hhx2 and CVE-2026-34986 in Go dependencies. If you're running any prior v1.120.x or v1.119.x version, upgrade to v1.120.2 now. Check your vulnerability scanner output to confirm the affected packages are resolved post-upgrade.

  • enhancementVerify cosign image signatures in your admission pipeline

    OpenCost images are now signed with cosign keyless signing and include SLSA provenance attestations. If your cluster uses an admission controller (e.g., Kyverno, Connaisseur), add a policy to enforce signature verification on opencost images. This closes a real supply-chain gap for teams running OpenCost in regulated environments.

  • enhancementEnable AWS CUR 2.0 and tune spot data feed behavior

    If your AWS billing is already on CUR 2.0, you can now configure OpenCost to use it directly. Additionally, if you don't use the AWS spot data feed, set the new toggle to disable it — this suppresses noisy warnings and avoids unnecessary config polling. Teams with spot-heavy workloads should also benefit from the new spot price API caching layer reducing API call volume.

Key changes (5)
  • Security: Patched vulnerable Go dependencies (GHSA-xmrv-pmrh-hhx2, CVE-2026-34986) — upgrade promptly
  • AWS CUR 2.0 support added, plus a configurable toggle to disable the spot data feed and spot price API caching
  • Memory leak fixed in scrape target parsing; CPU counter overflow/reset protection added
  • Container images now signed with cosign keyless signing and SLSA provenance attestation
  • OVH cloud provider added; PV pricing can now be set via annotations; PV capacity parsing fixed for Ki/Mi/Gi/Ti units
Source

Istio

Networking & MessagingMay 18, 2026

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.

Key changes (5)
  • Security fix: AuthorizationPolicy bypass via unescaped regex metacharacters in source.principals (suffix matches) and source.namespaces — legal Kubernetes names like 'foo.bar' could match unintended identities
  • Security fix: XDS debug endpoints (/debug/syncz, /debug/config_dump) now enforce same-namespace authorization — previously any authenticated workload could read config dumps across namespaces
  • Fixed deadlock in multicluster secret controller during remote cluster updates — critical for multi-cluster deployments
  • Fixed leaf certificate NotAfter time potentially exceeding the signing CA's expiration
  • AWS EKS ambient mesh fix: kubelet health probe failures for pods using Security Groups for Pods (branch ENI) resolved via new AMBIENT_ENABLE_AWS_BRANCH_ENI_PROBE flag (on by default)
Source

Litmus

ObservabilityMay 18, 2026

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.

Key changes (5)
  • Security: gRPC bumped to v1.79.3 to address CVE-2026-33186
  • Bug fix: concurrent reconciliation no longer triggers duplicate chaos experiments via the event-tracker
  • New feature: Prometheus metrics added to ChaosCenter for experiment observability, with unit tests and a getting-started guide
  • Bug fix: experiments can now be stopped even when the connected infra is disconnected
  • Bug fix: CronWorkflow run history no longer shows a blank page in the UI
Source

The Update Framework (TUF)

SecurityMay 18, 2026

v7.0.0 fixes a Windows-specific security vulnerability in delegation path matching and tightens the ngclient API with one breaking constructor change.

  • securityPatch Windows deployments immediately for GHSA-qp9x-wp8f-qgjj

    Delegation path matching was broken on Windows, meaning a malicious or misconfigured repository could match targets it shouldn't. If any of your TUF clients run on Windows, upgrade to v7.0.0 now. Linux/macOS deployments are unaffected, but upgrading is still the right move before paths diverge further.

  • breakingUpdate all Updater() call sites to use the named bootstrap argument

    The Updater() constructor signature changed: 'bootstrap' is now a required keyword argument. Any code calling Updater() without explicitly passing 'bootstrap' will break. Audit your code for Updater instantiations — if you weren't passing a bootstrap value before, add bootstrap=None to restore the previous behavior. This is a one-line fix per call site, but it will cause an immediate TypeError if missed.

  • enhancementWatch for securesystemslib.hash removal in upcoming releases

    This release starts phasing out the securesystemslib.hash dependency. If your codebase or any custom TUF extensions directly import or rely on securesystemslib.hash, start planning a migration now rather than scrambling when a future release drops it entirely.

Key changes (5)
  • Security fix for GHSA-qp9x-wp8f-qgjj: incorrect delegation path matching on Windows could allow unauthorized targets to be trusted
  • Updater() constructor now requires 'bootstrap' as a named argument — previously it had a default, now you must be explicit
  • To preserve old behavior with no bootstrap, pass bootstrap=None explicitly
  • Preparatory work to drop securesystemslib.hash dependency in a future release
  • Several documentation corrections
Source

Dapr

Orchestration & ManagementMay 15, 2026

Dapr v1.17.7 is a dense bug-fix release targeting workflow reliability, messaging correctness, and control-plane resilience. Fourteen production-grade fixes land here — upgrade if you run workflows, Kafka, or RabbitMQ.

  • securityUpgrade sentry immediately if you downgraded from 1.18 or use Ed25519/RSA issuer keys

    A type-switch bug in dapr/kit caused sentry to crash on startup with 'unsupported key type' for Ed25519 and RSA issuer keys. Sentry enters a crash-loop, stops issuing mTLS identities, and halts cert rotation. Sidecars with unexpired certs keep running, but any pod restart or cert expiry silently breaks identity. If your trust bundle was generated by 1.18 or you manually rotated to Ed25519/RSA keys, this is a crash-loop waiting to happen. Upgrading to 1.17.7 is the only fix — no trust bundle migration needed.

  • breakingScheduler etcd compaction mode change requires PVC capacity review

    The embedded etcd compaction mode switches from periodic (10 min) to revision-based (1,000,000 revisions), and the default storage size jumps from 1Gi to 16Gi. Kubernetes StatefulSet volumeClaimTemplates are immutable, so existing 1Gi PVCs are NOT automatically resized. If you're running the scheduler at any real workflow throughput, check your current PVC utilization now. If you're close to capacity, expand the PVC on the cluster before upgrading. The helm chart uses a lookup helper to avoid overwriting existing PVC sizes, but it cannot expand them for you.

  • enhancementAdd workflow payload size ratio dashboards before upgrading

    Two new histograms — dapr_runtime_workflow_payload_size_ratio and dapr_runtime_workflow_activity_payload_size_ratio — report payload size as a fraction of --max-body-size. Before upgrading, set up a Prometheus alert on histogram_quantile(0.99, ...) > 0.9 so you catch workflows trending toward the 0.95 stall threshold before they freeze. This is especially useful for workflows with large activity payloads or long histories. Note: metrics are only recorded when --max-body-size is explicitly configured.

Key changes (7)
  • Workflow state saves now use optimistic concurrency (ETag) to prevent silent history corruption during placement rebalances
  • Sentry crash-loop on Ed25519/RSA issuer keys fixed — critical for anyone who downgraded from 1.18 or rotated keys
  • Kafka graceful shutdown now drains in-flight messages before tearing down consumer sessions, eliminating spurious duplicate processing
  • RabbitMQ subscription restart no longer cascades and kills sibling subscriptions on the same connection
  • Scheduler embedded etcd defaults retuned for workflow workloads; compaction mode changed from periodic to revision-based; default storage bumped to 16Gi for fresh installs
  • daprd no longer self-destructs when the scheduler is briefly unavailable during WatchHosts stream open
  • Two new workflow payload size ratio metrics added for proactive capacity planning before stalls occur
Source

Linkerd

Networking & MessagingMay 15, 2026

Native sidecars promoted to GA and enabled by default, plus a security fix restricting Server resources from affecting workloads outside their namespace. Heavy dependency refresh across Rust and Go stacks.

  • securityServer namespace isolation fix — review cross-namespace Server resources immediately

    A fix was applied so that Server resources can no longer affect workloads in namespaces other than their own. If you have intentionally or accidentally created Server policies that were influencing workloads cross-namespace, those policies will silently stop applying after this upgrade. Audit your Server resources across all namespaces and verify that authorization policies still behave as expected post-upgrade. The risk of misconfigured over-broad policies is reduced, but any reliance on the previous behavior will break.

  • breakingNative sidecars are now on by default — audit your cluster before upgrading

    Native sidecar support (using Kubernetes init containers with restartPolicy: Always) is now GA and enabled by default. If your cluster runs Kubernetes < 1.29, native sidecars are unsupported and this will break injection. Even on supported versions, verify that any tooling, admission webhooks, or pod lifecycle assumptions in your workloads are compatible. Test in a staging environment before rolling out to production. If you need the old behavior, explicitly disable the feature flag during install/upgrade.

  • enhancementConfigure honorTimestamps on the linkerd-proxy PodMonitor

    If you're using the Prometheus Operator and have timestamp alignment issues in your Linkerd proxy metrics (e.g., stale or out-of-order samples), you can now set honorTimestamps in the Helm chart for the linkerd-proxy PodMonitor. This is a quality-of-life win for teams with strict metric ingestion pipelines. Set it explicitly during your next Helm upgrade rather than leaving it at the default.

Key changes (6)
  • Native sidecar injection promoted to GA and now enabled by default — no more feature gate needed
  • Security fix: Server resources are now restricted from affecting workloads in other namespaces
  • Gateway liveness synchronization improved for multi-cluster setups
  • rustls bumped to 0.23.40, openssl and aws-lc-rs updated — crypto stack refreshed
  • Proxy updated to v2.352.0, Go toolchain to 1.25.10, Helm to 3.21.0
  • PodMonitor honorTimestamps now configurable for linkerd-proxy metrics scraping
Source

Helm

Kubernetes CoreMay 14, 2026

Helm v3.21.0 bumps Kubernetes client libs to v1.36, patches OpenTelemetry CVEs, fixes OCI index chart pulling, and corrects nil value preservation in chart merging. Helm v3 EOL is approaching.

  • securityUpgrade immediately to patch OpenTelemetry CVEs

    OpenTelemetry packages were patched specifically to address CVEs. If you're running Helm in CI/CD pipelines or as part of automation tooling, upgrade to v3.21.0 now. Don't wait for the next patch release.

  • breakingPlan your Helm v4 migration — v3 EOL is real

    The release explicitly warns that Helm v3 is approaching end-of-life. This is not a distant concern — v3.22.0 targets Kubernetes v1.37 and v3.21.1 is just a bug fix release. Start evaluating Helm v4 changes now, especially if you maintain custom plugins or automation built around Helm's CLI or Go SDK.

  • enhancementTest OCI index-based chart pulls if you use multi-arch registries

    The fix for pulling charts from OCI indices means setups using image index manifests (common in multi-arch environments) should now work reliably. If you previously worked around this with direct digest references or manifest-specific tags, revisit those workarounds — they may no longer be necessary.

Key changes (5)
  • Kubernetes client libraries updated to v1.36, aligning with current cluster versions
  • OpenTelemetry packages patched to address CVEs — direct security fix
  • Fixed chart pulling from OCI image indices (multi-arch/index manifests now work correctly)
  • Fixed dot-name path bug in chart handling
  • nil values in chart values are now preserved correctly when the chart default is an empty map
Source

Cilium

Networking & MessagingMay 13, 2026

Cilium v1.19.4 is a stability-focused patch release with 20+ bug fixes covering crash prevention, IPsec reliability, and Cluster Mesh correctness — upgrade if you run any of those features.

  • securityUpdate moby/spdystream dependency (security fix included)

    This release bumps github.com/moby/spdystream to v0.5.1 as a security fix. The dependency is used in Kubernetes API communication paths. No CVE number is listed in the release notes, but treat this as a prompt to upgrade — staying on v1.19.3 leaves the exposure open.

  • breakingHand-managed EndpointSlices need service-proxy-name label added

    If you set --k8s-service-proxy-name and manage EndpointSlices manually, those slices will now be filtered OUT at the watch level unless they carry the matching service.kubernetes.io/service-proxy-name label. After upgrading, any untagged hand-managed slice becomes invisible to Cilium, causing traffic drops. Audit your EndpointSlices before upgrading and stamp the label on any that are missing it.

  • enhancementPrioritize upgrade if you run IPsec, WireGuard, or Cluster Mesh

    Three distinct data-plane reliability fixes land here: IPsec packet drops during rolling key rotation, WireGuard silent packet loss under constrained MTU with IPv6, and Cluster Mesh missing backends for multi-port services. Any of these can cause hard-to-diagnose intermittent connectivity issues. If your environment uses any of these features, this patch should move to the front of your upgrade queue.

Key changes (5)
  • Agent no longer crashes on transient network errors during CiliumNode updates — retries instead of calling Fatal
  • IPsec rolling restarts with key rotation fixed: SPI advertisement now deferred until XFRM states are ready, eliminating packet drops
  • WireGuard MTU clamped to IPv6 minimum (1280) when IPv6 is enabled, preventing silent packet loss in tunnel+encryption setups
  • EndpointSlice watch now filtered by service-proxy-name label at the watch level — operators with hand-managed slices must add the label
  • Cluster Mesh: missing global service backends restored when multiple service ports share the same target port
Source

Cilium

Networking & MessagingMay 13, 2026

v1.17.16 patches a cross-namespace traffic hijacking vulnerability in CiliumLocalRedirectPolicy, fixes an IPsec panic on malformed input, and resolves a static pod identity resolution bug.

  • securityAudit LRP addressMatcher configs before upgrading

    The LRP addressMatcher change fixes a real attack vector: a policy in one namespace could previously override a Service frontend and redirect traffic cross-namespace. After upgrading, any LRP that was relying on this override behavior will stop working silently — traffic won't redirect as expected. Before upgrading, audit your CiliumLocalRedirectPolicy objects for addressMatcher entries that overlap with existing Service frontends. If you legitimately need the old behavior, set --enable-lrp-address-matcher-override=true, but treat that as a temporary measure and redesign the policy.

  • securityUpgrade if running IPsec — agent crash risk on malformed input

    The parseSPI panic means a malformed IPsec packet could crash the Cilium agent, taking down networking on that node. This is a low-complexity denial-of-service risk for any cluster using Cilium's IPsec transparent encryption. Upgrade to v1.17.16 promptly if IPsec is enabled in your environment.

  • breakingLRP addressMatcher behavior change is not fully backward-compatible

    This is a behavior change, not just a bug fix. If you have CiliumLocalRedirectPolicies using addressMatcher that overlap with Service ClusterIPs or external IPs, those policies will now be rejected or ignored where they previously worked. Test your LRP configurations in a non-production environment before rolling this upgrade out. The opt-in flag --enable-lrp-address-matcher-override=true exists, but using it means you are accepting the previously-vulnerable behavior.

Key changes (5)
  • CiliumLocalRedirectPolicy addressMatcher now blocks overriding existing Service frontends — prevents cross-namespace traffic hijacking and service-map corruption; legacy behavior requires opt-in flag
  • IPsec: fixed panic in parseSPI when processing malformed SPI input — previously could crash the agent
  • Static pod endpoint identity resolution fixed for cases where CNI pod UID differs from the Kubernetes mirror pod UID
  • Cluster-pool IPAM metrics for CiliumNode synchronization now properly registered with Kubernetes
  • Security dependency update: moby/spdystream bumped to v0.5.1 (security fix)
Source

Cilium

Networking & MessagingMay 13, 2026

Cilium v1.18.10 is a stability-focused patch release fixing agent crashes, IPsec panics, Cluster Mesh backend gaps, and a data race in IPAM — all backported from upstream.

  • securitymoby/spdystream and x/net security updates are included

    This release pulls in a security fix for github.com/moby/spdystream and bumps x/net to v0.53. Both are network-layer dependencies. If your policy or threat model tracks transitive dependency CVEs, this patch justifies the upgrade on its own.

  • breakingUpgrade encrypted clusters to fix IPsec panic risk

    A panic in parseSPI on malformed IPsec input could crash the agent on nodes running encrypted traffic. If you use IPsec encryption, treat this as a priority upgrade — a malformed packet or misconfigured peer can take down the agent process entirely.

  • enhancementCluster Mesh users with shared target ports should upgrade

    The missing global service backends bug silently dropped backends from services where multiple ports mapped to the same target port. Traffic would route correctly within a single cluster but fail cross-cluster. Upgrade and verify affected services post-rollout using hubble observe or service endpoint inspection.

Key changes (5)
  • Agent no longer crashes fatally on transient network errors during CiliumNode updates — it retries instead
  • IPsec panic on malformed SPI input fixed, preventing node-level disruption in encrypted clusters
  • Cluster Mesh now correctly propagates global service backends when multiple ports share the same target port
  • CiliumLocalRedirectPolicy no longer hijacks an existing Service frontend before its backend pods are Ready
  • Data race in MultiPoolManager IPAM node updates resolved; x/net bumped to v0.53 for security
Source
Older →
Browse by month