CVE-2026-53492
KrytyczneCVSS 9.6Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 33 — wyżej niż 33% wszystkich znanych CVE
Streszczenie
W systemie containerd przed wersjami 2.3.2, 2.2.5 i 2.1.9 wykryto podatność w implementacji CRI, która nieprawidłowo ufa adnotacjom CDI z nieufnych metadanych obrazów punktów kontrolnych podczas przywracania kontenera. Osoba z uprawnieniami do tworzenia podów może ominąć standardowe przydzielanie zasobów Kubernetes i wymusić wstrzyknięcie dowolnych urządzeń lub montowań hosta do przywróconego kontenera.
Ocena ryzyka
Ryzyko polega na możliwości eskalacji uprawnień i naruszenia izolacji kontenerów, co może prowadzić do nieautoryzowanego dostępu do zasobów hosta oraz potencjalnego przejęcia całego węzła Kubernetes.
Rekomendacja
Należy niezwłocznie zaktualizować containerd do wersji 2.3.2, 2.2.5 lub 2.1.9. Jeśli aktualizacja nie jest możliwa, rozważ wyłączenie CDI na węzłach, które nie wymagają tej funkcji.
Oryginalny opis (angielski, źródło NVD)
containerd is an open-source container runtime. In Versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod's create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9.