CVE-2026-95837

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ń.

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).

Wtyczka CRI w containerd przed wersjami 1.7.33, 2.3.2, 2.2.5, 2.1.9 i 2.0.10 propaguje etykiety z konfiguracji obrazu (instrukcja LABEL w Dockerfile) do kontenera bez walidacji. Może to umożliwić wykonanie dowolnego polecenia na hoście przez wtyczkę, która wykorzystuje etykiety kontenerów do pewnych operacji.