Releases

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

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

Flatcar stable-4593.2.3 ships Linux 6.12.93 with eight kernel CVE patches and adds NVMe/TCP support for NVMe-oF storage backends.

• securityPatch eight kernel CVEs — update nodes now

  This release fixes eight Linux kernel CVEs. Details on severity are not yet in NVD for these 2026-prefixed IDs, but any kernel CVE batch warrants prompt node rotation. If you run Flatcar on bare metal or cloud VMs, schedule a node drain-and-replace cycle soon — do not wait for the next maintenance window if these IDs affect your kernel subsystems.

• enhancementNVMe/TCP opens up NVMe-oF storage backends

  NVMe over Fabrics via TCP is now available in the kernel module set. If your storage team uses NVMe-oF targets (e.g., disaggregated storage arrays or SPDK-based backends), Flatcar nodes can now connect without a custom kernel build. Test in staging before relying on this in production — confirm the nvme-tcp module loads correctly on your target image.

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.

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.

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.

KubeEdge v1.23 ships a major edge DB refactor (Beego → GORM), node query optimization to cut edge-cloud bandwidth, device anomaly detection in CRDs, and solid Windows EdgeCore improvements.

• breakingUpdate all Device status reads to use the new DeviceStatus CRD

  Device status has been extracted from the Device CRD into a standalone DeviceStatus CRD. The release says backward compatibility is maintained for the CRD schema itself, but any code, scripts, or automation that reads device status directly from the Device object will silently miss updates after the upgrade. Audit your operators, dashboards, and GitOps pipelines before upgrading — reroute status reads to the new DeviceStatus CRD.

• enhancementValidate edge DB behavior after the Beego-to-GORM migration

  The entire edge database layer has been rewritten. GORM replaces Beego ORM and all DB operations are now funneled through a single MetaManager entry point. This is a lower-risk change but still a deep internal refactor. Run your existing edge workloads against a staging environment on v1.23 before rolling to production — watch for any edge cases in MetaManager behavior, especially around reconnect and offline-mode scenarios.

• enhancementTake advantage of local node query optimization for large deployments

  If you're running dozens or hundreds of edge nodes, the shift from remote CloudCore node queries to local edge DB lookups should noticeably reduce your edge-cloud tunnel bandwidth. No configuration change is required — CloudCore automatically syncs node updates to the edge DB. Still worth monitoring your edge-cloud channel metrics post-upgrade to confirm the improvement in your specific topology.