Releases

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

• securitySchedule node reboots promptly — 50+ kernel CVEs patched

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

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

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

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

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

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

• securityUpgrade from 4081.3.7 without delay

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

• enhancementCheck TLS trust store assumptions after ca-certificates bump

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

Flatcar stable-4593.2.1 is a security-only update: 130+ Linux kernel CVEs patched and the kernel bumped to 6.12.87. Reboot nodes to apply.

• security130+ Linux kernel CVEs patched — reboot nodes promptly

  This release patches 130+ Linux kernel CVEs (CVE-2026-31xxx and CVE-2026-43xxx series), rolling up kernel versions 6.12.82 through 6.12.87. The sheer volume suggests a large stable-kernel backport batch. Treat this as a high-priority update — schedule a node rolling restart via your update operator or manually drain and reboot nodes running stable-4593.2.0 as soon as your change window allows.

• enhancementCA certificates updated to NSS 3.123.1 — check custom CA chains

  ca-certificates updated to NSS 3.123.1. If you have services doing TLS certificate validation at the OS level (not inside containers), verify that trust store changes don't affect any pinned or custom CA chains after the node reboots.

metal3-io v0.13.0 drops the iRMC driver, deprecates BMH firmware spec, and ships HostClaim CRDs plus multi-arch PXE boot — a release with real breaking changes that demand pre-upgrade review.

• breakingAudit iRMC usage and BMH.Spec.Firmware fields before upgrading

  The iRMC driver is gone — any BareMetalHost resources targeting iRMC BMC endpoints will stop reconciling after upgrade. Separately, BMH.Spec.Firmware is now deprecated; while it won't immediately break, you should plan migration to the replacement API. Scan your BMH manifests and Helm values for both before touching production.

• breakingVerify CAPI and controller-runtime compatibility in your management cluster

  The jump to CAPI v1.13.1 and controller-runtime v0.23.3 is not trivial. If you run other CAPI providers alongside metal3, check their compatibility matrices now. A version mismatch between providers sharing the same management cluster can cause subtle CRD conflicts or webhook failures at runtime.

• enhancementAdopt HostClaim CRDs for declarative bare-metal host allocation

  HostClaim and HostClaimSet resources give you a Kubernetes-native way to request and reserve bare-metal capacity without writing custom controllers. If you're currently managing host allocation through scripts or external tooling, evaluate whether HostClaim covers your use case — it's now feature-complete enough to replace simple reservation workflows.

OpenYurt v1.7.0 ships OTA image preheating for near-zero-downtime edge upgrades, label-driven YurtHub deployment, K8s-on-K8s support, and Kubernetes v1.34 compatibility — alongside removal of several deprecated components.

• breakingAudit usage of removed components before upgrading

  YurtAppOverrider, YurtAppDaemon (controller + webhook), yurt-coordinator, and the delegate lease controller are gone. If your workloads or Helm charts reference any of these, they will break silently or fail to deploy post-upgrade. Audit your manifests, Helm values, and any automation scripts before cutting over. The NodePool CRD also moves to v1beta2 — verify your tooling handles the new API version and the renamed field (enableLeaderElections replaces enablePoolScopeMetadata).

• enhancementAdopt OTA image preheating for edge DaemonSet upgrades

  If you manage DaemonSets on edge nodes with constrained or intermittent connectivity, the new ImagePreHeat controller is a practical fix for upgrade-induced downtime. Trigger preheating via the new OTA API endpoint before scheduling the rollout. Watch the PodImageReady condition to confirm images are cached before initiating the actual upgrade. This is especially valuable for large images or nodes behind slow WAN links.

• enhancementSwitch to label-driven YurtHub onboarding

  The new YurtNodeConversionController lets you onboard and offboard edge nodes by applying a label — no more running yurtadm join manually per node. This is a meaningful operational improvement if you manage fleets of edge nodes. Start testing this workflow in a non-production node pool first, since it interacts with systemd directly and the feature is new in this release.