リリース

This is a redirect release pointing to individual Kubeflow sub-project repositories. No actual code or features were released here.

• breakingStop watching kubeflow/kubeflow for release updates

  If your team tracks Kubeflow releases via the kubeflow/kubeflow repository, you're now missing actual releases. Each sub-project ships independently. Update your watch list, RSS feeds, or release notification pipelines to follow the individual repos: manifests, pipelines, trainer, katib, notebooks, spark-operator, model-registry, sdk, and dashboard.

• enhancementAdopt per-component upgrade cadence instead of monolithic updates

  With each component on its own release cycle, you can now upgrade just Katib or Model Registry without touching Pipelines or Trainer. Build your upgrade strategy around component-level semver tracking rather than waiting for a single Kubeflow platform release. Check kubeflow/manifests releases for the reference compatibility matrix between components.

Microcks 1.14.0 adds Kafka request-reply for async mocking and expands Callback/Sync-to-Async support across REST, gRPC, and the UI. A bug fix prevents HTTP method mutation on mocked operations.

• securityRebuild custom images on updated UBI9 base

  The base image bumps to UBI9 9.7-1776833838. If you build custom Microcks images on top of the official one, rebuild and re-test after upgrading to pick up the upstream OS patches included in this UBI update.

• breakingVerify REST mock routing after operation method fix

  The fix for issue #2028 prevents the operation HTTP method from being overridden — a subtle bug that could cause mocks to respond incorrectly if the method was being mutated. Verify any existing REST mocks that rely on method-specific routing to confirm they behave as expected after upgrade.

• enhancementAdopt Kafka request-reply for async testing

  Kafka async mocks now support request-reply semantics. If your team uses Microcks to mock event-driven services over Kafka, this unlocks proper two-way interaction testing without external tooling. Review the updated API for Callback and Sync-to-Async support alongside the new triggers UI before migrating existing Kafka mock setups.

Knative v1.22.0 completes the EndpointSlices migration, consolidates TLS configuration across all components, and adds new autoscaling observability metrics.

• enhancementScrape the new queue/active request metrics for autoscaling tuning

  kn.revision.request.queued and kn.revision.request.active are now available from queue-proxy. If you're tuning concurrency targets or debugging cold-start behavior, add these to your Prometheus scrape config and dashboards. They give you direct visibility into the queue depth per revision, which was previously only inferable from aggregate metrics.

• enhancementVerify RBAC if running with minimal cluster permissions

  The ClusterRole now includes endpointslices/restricted permissions to support the EndpointSlices migration. If your cluster uses OPA, Kyverno, or any policy engine that audits ClusterRole changes, review and approve the updated role during upgrade. Missing this permission would break autoscaler stat forwarding.

• enhancementGraceful WebSocket shutdown reduces in-flight request drops during scale-down

  The queue-proxy now shuts down WebSocket connections gracefully. If your services handle WebSocket traffic, this directly reduces dropped connections during rolling updates or scale-to-zero events. No configuration change needed — the improvement is automatic on upgrade.

Rook v1.19.5 patches several operator bugs including a CSI priority class swap, OSD CRUSH device class fix, and more reliable mon drain behavior.

• breakingAudit CSI priority classes after upgrade — they were swapped

  The provisioner and plugin priority class names were assigned to the wrong CSI components. If you set custom values for these fields, verify that your workloads are getting the priority you intended post-upgrade. Clusters running latency-sensitive storage I/O with tiered priority classes are most at risk. Check the assigned priority classes on CSI pods after the upgrade and adjust your Helm values if needed.

• enhancementUpgrade if you've hit silent CRUSH device class failures on OSD re-discovery

  When OSDs were re-discovered (e.g., after node replacement or OSD recreation), the CRUSH device class wasn't being reapplied. This caused OSDs to land in the wrong CRUSH bucket, potentially breaking data placement rules. If you use device classes (hdd/ssd/nvme) for pool or rule targeting, verify your OSD tree after upgrading to confirm correct class assignments.

• enhancementSet ROOK_UNREACHABLE_NODE_TOLERATION_SECONDS via Helm now

  Previously this required patching the operator deployment directly. With this release it's a first-class Helm value. If you've been working around this with post-install patches or custom operator manifests, clean those up and move the setting into your values file to avoid drift.

v0.151.0 has one API-level breaking change in the OTLP receiver config struct and changes the default behavior of the builder's go.mod generation. Dual-stack gRPC connection fixes and a pprofile data corruption fix are the most operationally relevant improvements.

• breakingUpdate OTLP receiver config field access in custom collectors

  The OTLP receiver's Config.Protocols is now a named field — any code accessing cfg.GRPC or cfg.HTTP directly will fail to compile. Update those references to cfg.Protocols.GRPC and cfg.Protocols.HTTP before upgrading collector builds that embed or extend the OTLP receiver.

• breakingCheck generated collector go.mod if you commit builder output

  cmd/builder now writes relative paths in Go module replace statements by default. For teams that build the collector, commit the generated source, and run it on multiple machines, this is an improvement. If you have tooling that depends on absolute paths (e.g., scripts parsing go.mod), set dist::use_absolute_replace_paths: true to preserve the old behavior while you migrate.

• enhancementFix dual-stack DNS connection issues with passthrough gRPC resolver

  Teams running OTLP gRPC exporters in dual-stack DNS environments have reported connection issues since the grpc.NewClient migration. You can now work around this by setting the endpoint to passthrough:///host:port in your exporter config. If you've seen intermittent connection failures in IPv4/IPv6 mixed environments, try this first.

Single targeted bug fix: messages arriving during graceful shutdown or pub/sub component hot-reload no longer get silently routed to dead-letter queues.

• breakingAudit your dead-letter queues for silently lost messages

  If you run pub/sub with dead-letter queues configured, messages diverted there during past rolling deployments or restarts were never retried — they just sat in the DLQ. Before upgrading, inspect those queues for messages that should have been processed. After upgrading to 1.17.6, plan to replay or reprocess any legitimate messages found there. Going forward, monitor DLQ depth during deployments as a health signal; a spike should now indicate actual processing failures, not shutdown timing artifacts.

• enhancementUpgrade if you do rolling deployments or frequent restarts

  Any team doing Kubernetes rolling updates or frequent pod restarts with pub/sub workloads should treat this as a high-priority patch. The previous behavior was silent — no errors surfaced to your app, messages just disappeared into DLQs. The fix is low-risk (a targeted behavior change in the shutdown path), so upgrading from any 1.17.x release is straightforward.

v1.120.1 is a patch release focused on carbon cost fixes, AWS Spot pricing performance, memory optimization, and a security-relevant MCP server default change.

• breakingCheck if MCP server was relied upon — it's now off by default

  The MCP server flipped from opt-out to opt-in. If any tooling or integrations depended on the MCP server being active without explicit configuration, they will silently stop working after this upgrade. Before deploying, audit whether MCP_SERVER_ENABLED needs to be explicitly set to true in your environment config.

• enhancementAWS Spot users: Spot Price History caching reduces API pressure

  If you run workloads on AWS Spot instances, OpenCost was previously hitting the Spot Price History API more aggressively. The new caching layer cuts down on AWS API calls, which matters both for rate limiting and for cost attribution latency. No action required, but worth validating your Spot cost data accuracy after upgrading.

• enhancementCarbon cost data was wrong — upgrade if you track emissions

  The carbon cost fixes address incorrect provider detection and broken fallback logic, meaning prior carbon cost figures may have been inaccurate. If you surface carbon/emissions data to teams or dashboards, re-baseline your metrics post-upgrade rather than comparing historical data across this version boundary.

Strimzi 1.0.0 drops all pre-v1 CRD APIs — this is a hard requirement before upgrading. Also adds Kafka 4.1.2 support, TLS on the HTTP Bridge, and environment-variable-based rack awareness.

• breakingConvert all CRDs to v1 API before upgrading — no exceptions

  Strimzi 1.0.0 flat-out removes v1beta2, v1beta1, and v1alpha1. If any of your custom resources still use those API versions, the operator will not reconcile them after upgrade. Run the CRD conversion procedure documented by Strimzi before touching anything else. This applies to KafkaTopic and KafkaUser resources too, which had their own v1alpha1/v1beta1 versions. Skipping this step will break your cluster management silently.

• enhancementSwitch rack awareness to environment-variable type to drop ClusterRoleBindings

  The new type: environment-variable rack awareness reads topology from env vars rather than querying the Kubernetes API, which means it no longer needs ClusterRoleBindings. If you're running in environments with tight RBAC policies or multi-tenant clusters, this is worth migrating to. Review your Kafka CR's rack configuration and update the type field — no other infrastructure changes needed.

• enhancementUseConnectBuildWithBuildah is now on by default — verify your Connect build pipelines

  This feature gate moving to beta means Buildah is now the default build tool for Kafka Connect connector builds. If you've been relying on Kaniko-specific behavior or have custom build configurations, test your Connect builds in a non-production environment after upgrading. The Buildah image is pinned in the release, so the toolchain is stable, but behavioral differences in layer caching or registry auth handling could surface.

hami v2.8.2 was released, but the published notes are too brief to summarize. See the original release notes for details.

SPIRE v1.14.6 patches two critical security vulnerabilities in node attestation: an EC2 instance impersonation flaw and a race condition in join token validation.

• securityUpgrade immediately if using aws_iid node attestation

  The aws_iid bug is severe: any EC2 instance under attacker control could forge the identity of any other EC2 instance during attestation, bypassing all downstream SPIFFE ID assignment and workload authorization. If you use aws_iid attestation in any environment, treat this as a critical breach risk and upgrade to v1.14.6 now. After upgrading, audit your node attestation logs for anomalous registrations — specifically instances claiming identities inconsistent with their actual AWS metadata.

• securityJoin token race condition allows double-registration — patch now

  The TOCTOU flaw means two concurrent requests with the same join token could both complete attestation successfully, resulting in two agents registered under one token. If join tokens are distributed in automated pipelines or ephemeral environments, an attacker who intercepts a token could race a legitimate agent to claim it. Upgrade to v1.14.6, then review your join token issuance and revocation policies. Consider switching to shorter-lived tokens or alternative attestation methods like x509pop for sensitive workloads.

v1.13.6 patches two serious security vulnerabilities in SPIRE: an EC2 instance impersonation flaw in the AWS IID attestor and a race condition in join token handling. Upgrade immediately.

• securityUpgrade now if you use AWS IID node attestation

  The AWS IID attestor vulnerability is severe: any attacker controlling an EC2 instance could forge the identity of any other EC2 instance in your environment during node attestation. All downstream RBAC, SVID issuance, and workload identity decisions would operate on the forged identity. If you run SPIRE with the aws_iid server plugin, treat this as a critical incident — patch to v1.13.6 before doing anything else. Review your SPIRE server logs for unexpected node attestation events from EC2 instances, especially cross-account or cross-region patterns.

• securityAudit join token usage if you allow concurrent agent bootstrapping

  The TOCTOU bug in join token handling means two agents racing to attest with the same token could both succeed — violating the one-time-use guarantee. In practice this could allow unauthorized agents to join your trust domain. After upgrading, rotate any join tokens that may have been used during periods of concurrent agent bootstrapping. If you use join tokens in automation (e.g., init containers, CI pipelines), review whether parallel execution could have triggered this race.

NATS v2.12.8 is a substantial bug-fix release targeting JetStream stability — particularly clustered stream/consumer reliability, Raft edge cases, and a bearer JWT disclosure vulnerability in the monitoring API.

• securityPatch immediately: /connz was leaking bearer JWTs

  Any deployment using JWT-based auth with the monitoring endpoint exposed (even internally) was potentially leaking bearer tokens in /connz responses. Rotate any JWTs that may have been exposed, audit monitoring endpoint access logs, and upgrade to v2.12.8 now. If you can't upgrade immediately, restrict /connz access via firewall or NATS monitoring auth.

• securityCLI argument secrets now redacted in monitoring

  Route and cluster URLs passed as CLI arguments (which often contain credentials) were previously visible in monitoring output. Upgrade to v2.12.8 and review any monitoring dashboards or log aggregation pipelines that may have captured this data historically.

• enhancementJetStream cluster operators: test your scaling and recovery paths

  This release fixes several nasty edge cases — stream leader catch-up from snapshots, Raft commit index resets on term mismatches, in-flight assignment visibility for stream/consumer info, and the 'last sequence mismatch' error from failed proposals. If you've been seeing any of these intermittent errors in clustered JetStream, v2.12.8 is a high-priority upgrade. After upgrading, monitor for reduced error rates in stream info and consumer info endpoints during scaling operations.

NATS v2.11.17 is a security and stability patch addressing JWT bearer token exposure in monitoring endpoints, credential redaction gaps, and several crash/correctness bugs.

• securityPatch immediately: /connz was leaking bearer JWTs

  Any operator exposing the NATS monitoring port (default 8222) to internal or external networks should treat this as urgent. Bearer tokens visible in /connz could be harvested and replayed. Rotate any JWTs that may have been exposed, audit who had access to your monitoring endpoints, and upgrade to 2.11.17 now. If you cannot upgrade immediately, firewall the monitoring port.

• securityCLI-embedded secrets were visible in monitoring output

  If your NATS deployment passes route or cluster URLs with embedded credentials as command-line arguments, those secrets were previously visible in monitoring output. Audit your monitoring data for any historical exposure, rotate affected credentials, and upgrade. Long-term, prefer config files or environment-based secret injection over CLI arguments.

• breakingRepeated CONNECT behavior change may affect edge-case clients

  The fix for repeated CONNECT messages clearing subscriptions changes previously tolerated (but incorrect) behavior. Custom clients or unusual connection patterns that send multiple CONNECT messages on the same connection could see subscriptions unexpectedly dropped. Audit any non-standard client code before upgrading in production.

Prometheus v3.11.3 patches three security vulnerabilities: a credential leak, a DoS vector via malformed snappy payloads, and a stored XSS in the classic UI.

• securityRotate AzureAD client secrets if /-/config was accessible

  If you use AzureAD remote write and the /-/config endpoint was reachable by anyone other than trusted admins, treat your client_secret as compromised. Rotate it in Azure AD immediately, then upgrade to v3.11.3. Also audit who has access to that endpoint — it should never be public-facing.

• securityUpgrade immediately if remote-read is enabled and exposed

  The snappy decode vulnerability lets an attacker send a crafted request with an inflated declared length, potentially exhausting memory. If your Prometheus remote-read endpoint is reachable from outside your trust boundary, this is a real DoS risk. Upgrade to v3.11.3 as soon as possible — there's no config-level workaround short of disabling remote-read entirely.

• securityAssess XSS exposure if you still run the classic UI

  The stored XSS in the old UI heatmap affects any deployment where users can influence label values (e.g., via instrumented applications) and other users view those charts. If you've already migrated to the new UI, you're not affected. If you haven't, upgrade now — or at minimum restrict UI access to trusted users until you do.

v1.15.0 brings latency improvements for complex authorization models via edge pruning, fixes a cache bug in the experimental weighted graph checker, and patches Go stdlib CVEs by upgrading to Go 1.26.2.

• securityUpdate immediately to patch Go stdlib vulnerabilities

  This release ships Go 1.26.2, which addresses vulnerabilities in the Go standard library. If you run OpenFGA as a managed binary or container, pull the new image now. If you build from source, ensure your toolchain matches. Don't wait on this — stdlib vulns can affect TLS, HTTP parsing, and crypto paths that OpenFGA relies on.

• enhancementRe-benchmark list objects performance on complex models

  Edge pruning in the list objects pipeline cuts unnecessary graph traversal. If your authorization model has deep or wide relationship graphs, you should see reduced p99 latency on ListObjects calls. Run your existing load tests against v1.15.0 and compare — this is a free win that requires no config changes.

• enhancementRe-evaluate weighted_graph_check cache behavior if you hit cold-start issues

  The experimental weighted_graph_check feature was silently skipping its cache on cold start or when the cache controller was disabled, which could explain unexpected latency spikes early in pod lifecycle. The fix aligns behavior with the documented contract: zero invalidation time means use the cache. If you're using this experimental feature, test it again — behavior will differ from what you may have measured before.

Prometheus v3.5.3 is a security-only release patching four vulnerabilities: credential exposure, two snappy decompression bombs, and a stored XSS in the legacy UI.

• securityRotate AzureAD client_secret immediately if /-/config was exposed

  Any Prometheus instance using AzureAD remote write had its OAuth client_secret visible in plaintext at the /-/config endpoint. If that endpoint was reachable by untrusted users or scraped by monitoring tools, treat the secret as compromised. Rotate it in Azure AD, update your Prometheus config, and then upgrade to v3.5.3. After upgrading, restrict /-/config access via --web.enable-admin-api controls or a reverse proxy allowlist.

• securityUpgrade now if you accept remote-read or remote-write from untrusted sources

  Both remote-read and remote-write endpoints were vulnerable to decompression bomb attacks — a crafted snappy request with an inflated declared size could exhaust memory. If your Prometheus is internet-facing or accepts data from multiple tenants, this is a denial-of-service risk. Upgrade to v3.5.3 immediately. There is no config-level workaround; the fix is in the code.

• securityPatch stored XSS if anyone uses the legacy UI with untrusted label values

  The old UI heatmap rendered 'le' label values without escaping, allowing stored XSS. If your users browse the legacy UI and your metrics include 'le' labels sourced from external or user-controlled systems, malicious JavaScript could execute in their browsers. Upgrade to v3.5.3. As a short-term measure, direct users to the new UI instead.

A large security maintenance release for the LTS channel: kernel jumps from 6.6.107 to 6.6.127 and closes hundreds of CVEs accumulated since the last LTS point release, plus a ca-certificates update and a local dev fix for arm64 Macs.

• securityApply the kernel update promptly — large CVE backlog closed

  This release rolls up roughly 20 kernel point releases (6.6.107 through 6.6.127), closing several hundred CVEs accumulated over that span. Treat this as a mandatory patch cycle rather than a routine bump — teams on 4081.3.6 or earlier have been running with months of unpatched kernel CVEs, some of which affect networking, filesystems, and memory management subsystems commonly hit in container workloads. Roll this out to fleets on the LTS channel as soon as your update ring allows.

• enhancementVerify TLS trust chains after ca-certificates 3.116→3.122 jump

  ca-certificates jumped from 3.116 to 3.122, spanning multiple NSS releases. If you pin or vendor CA bundles separately from the OS image, check for any removed or distrusted root certificates in that range that could break TLS validation for internal services or older endpoints.

• enhancementFaster local VM testing on Apple Silicon

  The QEMU launcher script now enables HVF acceleration on arm64 Macs (Flatcar#1901). If you develop or test Flatcar images locally on Apple Silicon, update your local scripts/tooling to pick this up — VM boot and test cycles should be noticeably faster.

Flatcar stable-4593.2.0 is a large security + infrastructure release: 150+ kernel CVEs patched, openssh/openssl/curl/intel-microcode updated, and significant initrd/partition layout changes that need attention before upgrading.

• securityMass CVE remediation across kernel and userspace — update now

  Linux kernel patches cover 150+ CVEs, and userspace components (openssh 10.2_p1, openssl 3.5.4, curl 8.16.0, intel-microcode, gnupg, pam) each carry their own CVE fixes. This is a large security catch-up from Stable 4459.2.4. Any Flatcar node on stable should be updated promptly — the auto-update mechanism will handle it, but verify nodes are actually cycling through updates if you have update pauses configured.

• breakingsshd now uses OpenSSH upstream defaults including post-quantum key exchange

  sshd_config no longer hard-codes Ciphers, MACs, and KexAlgorithms; OpenSSH upstream defaults now apply, which includes post-quantum key exchange. If your environment requires specific legacy algorithms (e.g., for compliance tooling or older SSH clients), add drop-in config to /etc/ssh/sshd_config.d/ before upgrading. Test SSH connectivity after the update in a non-prod node first.

• breakingPartition layout changed; kernel module availability in first-stage initrd is reduced

  Partition sizes have grown: /boot to 1 GB, /usr to 2 GB, /oem to 1 GB. Existing nodes can still update, but new disk images will use the larger layout. If you have tight disk quotas, pre-provision or verify disk images have room. Also, the kernel+initrd on /boot is now half the size due to a two-stage initrd split — if any required drivers were only in the first-stage initrd, you may see boot issues. Report regressions to the Flatcar team immediately.

Cortex v1.21.0 graduates several experimental features to stable, fixes multiple PRW2 data corruption and panic bugs, and introduces a new Parquet mode for Store Gateway alongside an Overrides API.

• breakingAudit and update renamed flags before upgrading

  Several flags were renamed: -experimental.ruler.enable-api → -ruler.enable-api, -experimental.alertmanager.enable-api → -alertmanager.enable-api, -distributor.otlp.enable-type-and-unit-labels is now a no-op (consolidated into -distributor.enable-type-and-unit-labels), and parquet cache flags/configs dropped 'queryable' from their names. The users-scanner cleanup-interval became update-interval. Old flags are deprecated but not removed yet — audit your config files and Helm values now, before they disappear in a future release.

• breakingPRW2 data corruption and panic fixes require validation of existing pipelines

  Three separate bugs in the Remote Write V2 handler were fixed: shallow copying of Samples/Histograms caused data corruption, dirty sync.Pool reuse caused index-out-of-range panics, and Symbols backing array wasn't cleared on pool return causing memory leaks. If you're using PRW2, treat this upgrade as mandatory. Validate your ingestion pipeline after upgrading and check that downstream metrics are intact.

• enhancementBucket index is now on by default — verify storage permissions

  The bucket index is enabled by default in this release. If your object storage IAM policies restrict list operations or your Cortex deployment had bucket index disabled intentionally, verify that the bucket index can be written and read correctly post-upgrade. Cortex will generate and maintain the index automatically, but storage permission errors will surface as query failures rather than obvious configuration errors.

Patch release upgrading to Wasmtime 44 and fixing a pooling allocator crash, plus new glibc builds for GPU workloads on Linux.

• securityUpgrade if you hit pooling allocator crashes — the fix prevents silent failures

  The pooling allocator was being enabled without checking whether the host hardware actually supports it, which could cause runtime crashes or unpredictable memory behavior. If you've seen wash-runtime instability on certain host types, this fix directly addresses that. Upgrade and monitor memory allocation behavior post-deploy.

• breakingTest Wasmtime 44 upgrade in staging before rolling to production

  Wasmtime 44 is a major version bump for the underlying runtime. While wasmCloud wraps it, Wasmtime releases frequently carry behavior changes in memory handling, WASI interfaces, or component model semantics. Validate your component workloads in a non-production environment before upgrading clusters.

• enhancementGPU workloads on Linux now have proper glibc builds — start testing if relevant

  If you're running or planning wasmCloud workloads that touch GPU features on Linux, the new glibc builds resolve compatibility issues with standard Linux distributions that expect dynamically linked runtimes. Pull the new artifacts and validate against your target GPU host environment.

KubeVirt v1.7.3 is a focused patch release fixing 11 bugs across live migration, ARM64/s390x guest support, VMExport, and virt-handler stability.

• breakingBackend storage volume name has changed — check existing VMs

  VMs using backend storage volumes will now report the volume name as 'persistent-state-for-this-vm' instead of a name derived from the VM name. If you have monitoring, automation, or tooling that references the old volume name pattern, update those references before upgrading. Verify existing VMs with backend storage in your environment to understand impact before rolling out v1.7.3.

• enhancementUpgrade if you run ARM64 or s390x guests, or use decentralized live migration

  Three targeted fixes land for non-x86 architectures: ARM64 SMBIOS visibility and s390x PCIe controller errors are both resolved. Separately, decentralized live migration now correctly reports success and supports Windows VMs requiring Hyper-V enlightenments. If any of these scenarios apply to your cluster, this patch is worth prioritizing over staying on v1.7.2.

• enhancementvirt-handler socket recovery is now automatic — no more manual pod restarts

  Two separate fixes address domain-notify server crashes and socket deletion. Previously, a deleted or crashed notify socket would leave virt-handler in a broken state requiring manual intervention. After upgrading, this recovers automatically. If you've been seeing unexplained VM communication failures on nodes, this is likely the culprit.

KubeVirt v1.6.5 is a patch release with 61 fixes targeting decentralized live migration reliability, virt-handler stability, and monitoring accuracy.

• breakingBackend storage volume rename may affect existing tooling

  VMs using backend storage volumes will now report the volume name as 'persistent-state-for-this-vm' rather than a name derived from the VM name. If you have scripts, dashboards, or alerts that reference the old volume naming pattern, update them before upgrading. Check if any PVC-based tooling depends on that name convention.

• enhancementUpgrade if you rely on decentralized live migration

  Three separate bugs in decentralized live migration are fixed here: cross-volumeMode failures, broken migration for enlightened (Hyper-V) VMs, and incorrect 'succeeded' status reporting after compute migration. If your cluster runs Windows VMs or mixes volume modes, this patch directly unblocks those scenarios. Prioritize this upgrade over staying on v1.6.4.

• enhancementMonitoring alert baselines are now more accurate

  The low-count alert for KubeVirt components now fires based on the configured replica count in the deployment, not a hardcoded value. Non-schedulable nodes are also excluded from kubevirt_allocatable_nodes. Review your existing alert thresholds after upgrading — alerts may behave differently if your environment has non-schedulable nodes or custom replica counts.

Maintenance-heavy edge release with OpenSSL/rustls security bumps, a policy admission fix for Gateway routes, and a more robust annotation-to-metric-label conversion in the injector.

• securityPick up OpenSSL and rustls-webpki patches now

  Two OpenSSL crate bumps landed in this release, plus a rustls-webpki update. These sit in the proxy's TLS stack. If you're running any Linkerd edge build in a security-sensitive environment, upgrade to edge-26.4.4 to get the patched cryptographic dependencies rather than waiting for the next stable.

• breakingVerify Gateway route policies after the admission webhook fix

  The admission webhook previously ran full validation on Gateway routes even when they contained fields Linkerd doesn't support, causing legitimate routes to be rejected. That's fixed now — but if you worked around this by restructuring routes, review whether those workarounds are still needed or are now masking misconfigurations.

• enhancementTest chart override behavior if you use custom install values

  The fix to apply overrides to chart values on install closes a gap where certain Helm value overrides weren't being applied. If you have installation automation that relies on specific override patterns, run a dry-run install against this version to confirm the resulting values match expectations before rolling to production.

Crossplane v1.20.7 was released, but the published notes are too brief to summarize. See the original release notes for details.

Envoy v1.38 is a massive release with several breaking changes requiring immediate action — RSA key usage enforcement, BoringSSL build flag changes, and tcp_proxy config validation are the top priorities before upgrading.

• securityPatch CVE-2026-27135 by upgrading to v1.38

  This release includes the nghttp2 patch for CVE-2026-27135, which affects HTTP/2 header field handling. If you're running Envoy as an HTTP/2 gateway or proxy, this is a direct exposure. Prioritize upgrading clusters that terminate or proxy HTTP/2 traffic. RBAC header matcher also received a fix preventing concatenation-based bypass attacks — another reason to treat this upgrade as security-relevant.

• breakingAudit TLS configs before upgrading — RSA key usage now enforced

  enforce_rsa_key_usage defaults to true starting this release and will be removed entirely next release, making it permanent. Any upstream TLS connection where the certificate's key usage doesn't match the negotiated cipher will be rejected. Before upgrading, audit your upstream certificate configurations. Test in staging first — silent failures in prod will be connection resets, not helpful error messages.

• breakingUpdate BoringSSL FIPS build pipelines before building v1.38

  The --define=boringssl=fips Bazel flag is gone. CI/CD pipelines or Dockerfiles that build Envoy with FIPS mode will fail silently or error out. Replace with --config=boringssl-fips. If you're consuming official binaries rather than building from source, this doesn't affect you directly, but verify your supply-chain tooling if you maintain custom builds.

• enhancementOpenTelemetry metrics over HTTP — drop the collector sidecar

  The OTel stat sink can now push metrics directly via OTLP/HTTP without requiring a collector sidecar. If you're running otel-collector as a DaemonSet purely for Envoy metrics forwarding, you can simplify that architecture. Evaluate whether direct OTLP/HTTP export to your backend (Grafana Cloud, Honeycomb, etc.) reduces operational overhead in your environment.

v1.16.4 is a security-focused patch release addressing 15+ CVEs across Kyverno's dependency chain, plus a critical behavioral change that disables HTTP in namespaced policies by default.

• securityUpgrade immediately — 15+ CVEs patched, including supply chain components

  This release patches CVEs across sigstore/rekor, go-tuf, docker/cli, Go stdlib, and Kyverno's own code. Several of these touch the image verification and policy fetch paths. If you're running any image signing workflows with Kyverno, the rekor and go-tuf bumps are directly relevant. Plan an upgrade in your next maintenance window — do not wait for the next major cycle.

• breakingHTTP disabled by default in namespaced policies (CVE-2026-4789) — test before upgrading

  Namespaced policies that fetch external data over plain HTTP will silently stop working after this upgrade. If you use URL context sources or external data fetches in namespaced ClusterPolicy or Policy resources, audit them for HTTP (non-HTTPS) endpoints before upgrading. This is a security hardening change, but it will break existing policies that relied on insecure endpoints. Switch those endpoints to HTTPS or migrate to HTTPS-capable data sources first.

• breakingRestricted ConfigMap access for namespaced policies — RBAC may need review

  Namespaced policies now have reduced ConfigMap access scope. If your policies rely on reading ConfigMaps outside their namespace for context or configuration, those reads will fail post-upgrade. Review your policy definitions for cross-namespace ConfigMap references and adjust either the policy logic or the access grants accordingly before rolling out this version.

v1.17.2 is a security-heavy patch release addressing multiple CVEs and fixing critical bugs in MutatingPolicy, ValidatingPolicy, webhook reconciliation, and namespaced policy handling.

• securityUpgrade immediately — 6+ CVEs fixed in this release

  This release patches at least six CVEs across dependencies and Go stdlib, plus CVE-2026-4789 which disables HTTP in namespaced policies by default. If you run namespaced policies that rely on HTTP-based external data sources or webhooks, audit those configurations before upgrading — they will stop working silently. Upgrade path: update your Helm chart or manifests to v1.17.2 and validate policy behavior in a staging environment first.

• breakingNamespaced policies: HTTP disabled and ConfigMap access restricted

  Two separate hardening changes affect namespaced policies. HTTP is now disabled by default (CVE-2026-4789), and ConfigMap access has been scoped down. If your namespaced policies fetch context from HTTP endpoints or read ConfigMaps outside their namespace, those policies will fail silently or error post-upgrade. Run a dry-run or audit scan against your namespaced policies before deploying to production.

• enhancementWebhook reconciliation loop fix — reduces controller churn in large clusters

  Inconsistent webhook rule ordering was causing repeated reconciliation loops, which generates excess API server load and noisy controller logs. This is fixed. If you've been seeing constant webhook object churn in your audit logs or elevated kyverno-controller CPU, this release resolves it. No action needed post-upgrade, but worth monitoring controller metrics after rollout to confirm stabilization.

Buildpacks v0.40.3 was released, but the published notes are too brief to summarize. See the original release notes for details.

Kubernetes v1.36 is a large release with multiple GA promotions, significant DRA expansions, new gang-scheduling APIs, and several metric renames that require immediate action before upgrading.

• breakingUpdate monitoring before upgrading: two metric renames

  The metrics `volume_operation_total_errors` and `etcd_bookmark_counts` have been renamed to `volume_operation_errors_total` and `etcd_bookmark_total` respectively. Any Prometheus alerts or Grafana dashboards using the old names will silently stop firing after upgrade. Audit your monitoring stack and update all references before rolling out v1.36 to production.

• breakingDRA RBAC changes required if using DRAResourceClaimGranularStatusAuthorization

  The `DRAResourceClaimGranularStatusAuthorization` feature gate is beta and on by default in v1.36. DRA schedulers and controllers now need explicit `update`/`patch` on `resourceclaims/binding`, and DRA drivers need `associated-node:update` or `arbitrary-node:update` on `resourceclaims/driver` scoped to their specific `resourceNames`. If you run DRA drivers, audit and update their RBAC manifests before upgrading, or pods will fail to schedule.

• breakingflex-volume and git-repo volume plugin removals

  kubeadm no longer mounts the flex-volume plugin directory automatically, and the git-repo volume plugin is permanently disabled. If any workloads still use git-repo volumes, they will stop working — there's no flag to re-enable it. Migrate to an init container pattern or a CSI driver. For flex-volumes in kubeadm environments, you must manually configure extraVolumes and a non-distroless KCM image before upgrading to v1.36.

• breakingStrictIPCIDRValidation on by default — check your IP/CIDR fields

  API fields now reject IPs with leading zeros (e.g., `010.0.0.1`) and CIDRs with host bits set (e.g., `192.168.1.5/24` instead of `192.168.1.0/24`). Existing objects are preserved via validation ratcheting, but new creates and updates will fail if they use these formats. Audit your manifests, Helm charts, and automation for non-canonical IP/CIDR values before upgrading.

• enhancementMutatingAdmissionPolicy is now GA — consider replacing webhook boilerplate

  MutatingAdmissionPolicy (CEL-based mutation) is now v1 and enabled by default. If you're running simple mutating webhooks that set defaults or inject labels/annotations, this is a good time to evaluate replacing them with MutatingAdmissionPolicy resources. CEL-based policies eliminate the need to maintain webhook servers, certificates, and availability concerns. Start with low-risk, stateless mutations.

Backstage v1.50.3 was released, but the published notes are too brief to summarize. See the original release notes for details.

metal3-io v0.12.4 was released, but the published notes are too brief to summarize. See the original release notes for details.

metal3-io v0.11.7 was released, but the published notes are too brief to summarize. See the original release notes for details.

CoreDNS v1.14.3 ships full TSIG verification across all transports, multiple Go security CVE fixes, cache prefetch improvements, and a new forward plugin max_age option — a solid operational hardening release.

• securityUpgrade immediately for 13 Go CVE fixes and TSIG transport hardening

  Go 1.26.2 in this build addresses 13 CVEs. Beyond the runtime fixes, TSIG verification gaps in DoH, DoH3, QUIC, and gRPC transports are now closed — if you run any of those transports with TSIG, unauthenticated requests could previously slip through. Upgrade to v1.14.3 and verify your TSIG configurations are still valid after the stricter enforcement.

• breakingDoH oversized GET requests are now rejected — validate your clients

  CoreDNS now rejects oversized dns query parameters in DoH GET requests. Any client sending unusually large DNS-over-HTTPS GET queries will start getting errors. Test your DoH clients against this build in staging before rolling out; most well-behaved clients are unaffected, but custom or non-standard DoH implementations should be checked.

• enhancementUse max_age in the forward plugin to prevent stale upstream connections

  Long-lived upstream connections can silently degrade or get dropped by middleboxes. The new max_age option in the forward plugin lets you set an absolute connection lifetime. If you've seen sporadic upstream timeouts or resolution failures that resolve themselves, configure max_age to force periodic reconnection — start with something like 30s–5m depending on your upstream stability.

v2.0.4 is a minor maintenance release with TLS improvements for wash dev/host, a Helm chart fix for gateway routing, and governance updates.

• breakingCheck your Helm chart values if using local gateway routing

  The gateway is now disabled in values.local.yaml, and the hello-world example routes through a Kubernetes Service instead. If you forked or customized local Helm values with gateway-based routing, your setup may stop working after this update. Review your local values files against the updated defaults before upgrading.

• enhancementEnable TLS on wash dev/host if you're running local or production clusters

  TLS support now works across both wash dev and wash host. If you've been skipping TLS for local dev because it was unsupported, that excuse is gone. Test your TLS config in dev to catch certificate or connection issues before they surface in production.

Argo CD v3.3.8 is a patch release with six bug fixes targeting core mode syncs, AppSet resource limits, CLI diff accuracy, and informer cache staleness.

• breakingRefresh behavior changed again — validate your autosync pipelines

  The revert of the informer resync fix means refresh behavior is back to pre-3.3.7 state. If you tuned anything around reduced refresh frequency after upgrading to 3.3.7, re-examine those assumptions. Check autosync event logs to confirm expected behavior before promoting to production.

• enhancementCore mode users: upgrade immediately to unblock syncs

  The missing server.secretkey bug caused silent sync failures in core mode deployments — a serious operational gap that's easy to miss in monitoring. If you run Argo CD in core mode, this patch is not optional. Upgrade, then verify sync status across all applications post-upgrade.

• enhancementLarge ApplicationSets now default to 5,000 resource status entries

  If you manage ApplicationSets with hundreds of apps, you may have hit the old resource status count ceiling without realizing it. After upgrading, review any ApplicationSets that showed truncated or missing resource statuses and confirm they now report correctly.

Argo CD v3.2.10 is a pure bug-fix patch that resolves five regressions, including a critical core-mode sync failure and a stale cache issue in RevisionMetadata.

• breakingCore-mode deployments: upgrade immediately if apps are stuck out-of-sync

  If you run Argo CD in core mode (no API server) and recently saw apps failing to sync with secret-related errors, the missing server.secretkey bug was silently blocking all syncs. Upgrade to v3.2.10 and verify affected apps reconcile cleanly afterward.

• breakingAutosync event message format reverted — re-check any alerting rules you updated

  A message format change introduced recently and then reverted means the autosync event messages are back to their original format. If you updated Prometheus alerting rules, Grafana queries, or log parsers to match the new format, roll those changes back before upgrading to avoid false positives or missed alerts.

• enhancementsourceHydrator users: upgrade to get correct app diff behavior

  The CLI was using the wrong source revision for app diff and manifests commands when sourceHydrator was in use, meaning you could be reviewing diffs against the wrong state. After upgrading, re-run any diff checks you performed on v3.2.9 to confirm the output is accurate.

Patch release with two targeted bug fixes: a revert of a problematic refresh prevention change and a core mode sync failure when server.secretkey is absent.

• breakingRevert of refresh-prevention fix may re-expose original behavior

  The cherry-picked fix for preventing automatic refreshes from informer resyncs and status updates was reverted because it caused problems in 3.1. If you upgraded to 3.1.x specifically expecting that behavior to be fixed, it's gone again. Watch the upstream issue for a corrected implementation before relying on it. No action needed otherwise, but be aware of potential extra refresh churn in large clusters.

• enhancementUpgrade immediately if running Argo CD in core mode without server.secretkey

  A bug caused the application controller to fail syncing entirely when running in core mode and the server.secretkey was absent from the cluster secret. If your core-mode installations have ever had intermittent sync failures that were hard to diagnose, this is likely the culprit. Upgrade to 3.1.15 and verify syncs resume normally after rollout.

Pure security patch: Go runtime bumped to 1.23.9 and vulnerable dependencies updated. No functional changes — upgrade is the only action needed.

• securityUpgrade to v1.19.5 immediately — this is a pure CVE fix

  The cert-manager team explicitly recommends all users upgrade. The changes are limited to Go runtime and dependency bumps, so there is no functional risk in upgrading. If you are on any v1.19.x release, this is a straight swap with no migration steps. Check your deployment method (Helm, static manifests, OperatorHub) and roll it out to all clusters. Delaying leaves your cert-manager pods running with known vulnerable Go packages.

Flux v2.8.6 is a patch release fixing helm-controller post-renderer conflicts, a notification-controller regression for generic providers, and adding a MigrateAPIVersion feature gate in kustomize-controller.

• breakingAdd 'audience' to GCR Receiver secrets before upgrading to v2.9

  The 'audience' field on GCR Receiver secrets is currently optional but will become mandatory in v2.9. Audit your Receiver resources now and add the audience field to any GCR-backed secrets. Doing this proactively prevents a hard failure on your next major upgrade.

• breakingGeneric provider commit status events were broken — upgrade immediately if you rely on them

  A regression in notification-controller stopped generic providers from forwarding commit status events. If your CI/CD pipelines depend on those webhooks for pipeline gating or observability, they have been silently failing since the prior release. This patch restores that behavior — upgrade to v2.8.6 without delay.

• enhancementUse MigrateAPIVersion feature gate when managing resources with deprecated API versions

  If kustomize-controller manages resources that use older API versions tracked in managed field entries, the new MigrateAPIVersion feature gate handles migration automatically. Enable it in environments where you're seeing API version drift or drift detection noise from deprecated APIs.

KubeVirt v1.8.2 is a patch release with 12 bug fixes covering hotplug volumes, live migration, TLS config, qcow2 disk handling, and multi-arch VM stability.

• breakingBackend storage volume naming changed — check for impacts

  VMs using backend storage volumes will now report the volume name as 'persistent-state-for-this-vm' instead of a name derived from the VM name. If you have monitoring alerts, scripts, or tooling that match on the old volume name pattern, they will silently break. Audit any automation that references backend storage volume names before upgrading.

• enhancementUpgrade s390x and ARM64 clusters — arch-specific VM failures resolved

  Two separate fixes land here: ARM64 guests now correctly expose SMBIOS system info, and s390x VMs failing to create due to unsupported PCIe root-port controllers from the v3 PCI topology change are fixed. If you're running multi-arch clusters and held back on v1.8.x due to these issues, v1.8.2 is the version to move to.

• enhancementTLS config from KubeVirt CR now respected by sync-controller and virt-exportserver

  Previously, the sync-controller healthz server and virt-exportserver ignored the TLSConfiguration set in the KubeVirt CR, potentially using weaker defaults. After upgrading, verify your KubeVirt CR TLS settings are correct — they'll actually take effect now. This matters most for clusters with strict cipher or TLS version requirements.