[Security Advisory] CVE-2025-0426: Node Denial of Service via kubelet Checkpoint API

Announcements
1

Hello Kubernetes Community,

A security issue was discovered in Kubernetes where a large number of container checkpoint requests made to the unauthenticated kubelet read-only HTTP endpoint may cause a Node Denial of Service by filling the Node’s disk.

This issue has been rated Medium (6.2) (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and assigned CVE-2025-0426.

Am I vulnerable?

All clusters running an affected version listed below with the kubelet read-only HTTP port enabled and using a container runtime that supports the container checkpointing feature, such as CRI-O v1.25.0+ (with enable_criu_support set to true) or containerd v2.0+ with criu installed, are affected.

Affected Versions

  • kubelet v1.32.0 to v1.32.1

  • kubelet v1.31.0 to v1.31.5

  • kubelet v1.30.0 to v1.30.9

How do I mitigate this vulnerability?

This issue can be mitigated by setting the ContainerCheckpoint feature gate to false in your kubelet configuration, disabling the kubelet read-only port, and limiting access to the kubelet API, or upgrading to a fixed version listed below, which enforces authentication for the kubelet Checkpoint API.

Fixed Versions

  • kubelet v1.32.2

  • kubelet v1.31.6

  • kubelet v1.30.10

  • kubelet v1.29.14

    • Note: Container checkpoint support was an off by default Alpha feature in v1.25-v1.29

Detection

A large number of requests to the kubelet read-only HTTP server’s /checkpoint endpoint, or a large number of checkpoints stored (by default) under /var/lib/kubelet/checkpoints on a Node may indicate an attempted Denial of Service attack using this bug.

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Additional Details

See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/130016

Acknowledgements

This vulnerability was reported and fixed by Tim Allclair @tallclair from Google.

The issue was coordinated by:

Tim Allclair @tallclair

Sascha Grunert saschagrunert@

Craig Ingram @cji

Jordan Liggitt liggitt@

Thank You,

Craig Ingram on behalf of the Kubernetes Security Response Committee

1 Like