CVE-2026-95838

containerd to open-source'owe środowisko uruchomieniowe kontenerów. Wersje 1.7.28 i starsze, 2.0.0-beta.0 do 2.0.6, 2.1.0-beta.0 do 2.1.4 oraz 2.2.0-beta.0 do 2.2.0-rc.1 zawierają błąd w implementacji CRI Attach, który pozwala użytkownikowi wyczerpać pamięć na hoście z powodu wycieków goroutine. Problem naprawiono w wersjach 1.7.29, 2.0.7, 2.1.5 i 2.2.0. Obejściem jest skonfigurowanie kontrolera admission kontrolującego dostęp do zasobów pods/attach.

containerd w wersjach od 0.1.0 do 1.7.28, od 2.0.0-beta.0 do 2.0.6, od 2.1.0-beta.0 do 2.1.4 oraz od 2.2.0-beta.0 do 2.2.0-rc.1 ma podatność związaną z nadmiernie szerokimi domyślnymi uprawnieniami. Katalogi /var/lib/containerd, /run/containerd/io.containerd.grpc.v1.cri oraz /run/containerd/io.containerd.sandbox.controller.v1.shim są tworzone z nieprawidłowymi uprawnieniami.

W containerd przed wersjami 1.6.38, 1.7.27 i 2.0.4 kontenery uruchamiane z użytkownikiem ustawionym jako UID:GID większy niż maksymalna 32-bitowa liczba całkowita ze znakiem mogą powodować przepełnienie, w wyniku którego kontener działa jako root (UID 0).

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