CVE-2026-53488

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.

Podatność w containerd przed wersjami 2.3.2, 2.2.5 i 2.1.9 pozwala atakującemu z uprawnieniami do tworzenia podów na zatrucie lokalnego cache obrazów poprzez spreparowany obraz punktu kontrolnego (checkpoint). Brak walidacji referencji obrazów w konfiguracji importu punktu kontrolnego umożliwia przypisanie dowolnego lokalnego tagu do złośliwego obrazu.

containerd przed wersjami 1.7.35, 2.0.12, 2.2.8 i 2.3.5 zawiera błąd, w którym obsługa rozpakowywania warstw wielokrotnie przechodzi przez katalogi dla niektórych konfiguracji opaque whiteout. Złośliwa warstwa obrazu może wywołać powtarzające się przechodzenie przez katalogi podczas przetwarzania opaque whiteout. Pobranie lub zaimportowanie obrazu może zużywać CPU, opóźniać uruchamianie kontenerów i zmniejszać współbieżność pobierania obrazów dla niepowiązanych wdrożeń.

containerd to open-source'owy runtime kontenerów. Od wersji 2.1.0 do 2.2.7 i 2.3.4, przywracanie punktu kontrolnego CRI CreateContainer jest podatne, ponieważ CRIU przywraca stan bezpieczeństwa procesu z danych punktu kontrolnego zamiast egzekwować docelowy ContainerConfig. Atakujący, który może utworzyć kontener z przygotowanego punktu kontrolnego, może dostarczyć przywrócone poświadczenia, capabilities, no_new_privs i stan seccomp. Przywrócony proces może działać jako root z pełnymi capabilities i bez egzekwowanych filtrów seccomp, podczas gdy CRI raportuje żądaną konfigurację. Systemy, które nie używają CRI checkpoint restore, nie są dotknięte. Problem naprawiono w wersjach 2.2.7 i 2.3.4.

Podatność w containerd (open-source runtime kontenerów) przed wersjami 1.7.36, 2.0.13, 2.2.9, 2.3.6 i 2.4.1. Spreparowany graf OCI index może wymusić bardzo wysokie zużycie CPU/pamięci podczas PullImage (przed uruchomieniem kontenera), powodując długie opóźnienia ContainerCreating, a przy większych rozmiarach niestabilność węzła/runtime'u.

W containerd na Linuksie z włączoną wtyczką CRI, przed wersjami 1.7.35, 2.0.12, 2.2.8 i 2.3.5, funkcja drainExecSyncIO w internal/cri/server/container_execsync.go może zostać zablokowana na czas nieokreślony, gdy CRI ExecSync jest używane przez sondy exec lub hooki cyklu życia uruchamiające długotrwałe procesy potomne zachowujące potoki stdin/stdout. Faza opróżniania wejścia i wyjścia nie ma domyślnego limitu czasu i nie zatrzymywała się przy anulowaniu kontekstu żądania.

Podatność w containerd pozwala na odczyt dowolnego pliku na hoście przez polecenie kubectl logs. Błąd występuje w pluginie CRI, który przywraca plik container.log z obrazu punktu kontrolnego bez walidacji ścieżki dowiązania symbolicznego.

Podatność w containerd pozwala na wyczerpanie pamięci poprzez specjalnie spreparowany obraz kontenera, co prowadzi do zabicia procesu containerd (OOM) i uniemożliwia korzystanie z API środowiska uruchomieniowego. Problem dotyczy wersji przed 1.7.33, 2.0.10, 2.1.9, 2.2.5 i 2.3.2.

W containerd przed wersjami 1.7.32, 2.0.9, 2.2.4 i 2.3.1, kontenery z dyrektywą User ustawioną na wartość liczbową, która nie może być sparsowana jako 32-bitowa liczba całkowita, są błędnie traktowane jako nazwa użytkownika. Umożliwia to ominięcie ograniczenia runAsNonRoot w Kubernetes, jeśli spreparowany obraz zawiera wpis w /etc/passwd mapujący tę dużą liczbę na roota, co powoduje uruchomienie kontenera jako root (UID 0).