W czerwcu 2026 roku administratorzy linuksowych klastrów Kubernetes dostali wyraźne przypomnienie, że bezpieczeństwo kontenerów nie kończy się na skanowaniu obrazów i politykach RBAC. 18 czerwca 2026 roku projekt containerd opublikował serię wydań z poprawkami bezpieczeństwa, a 25 czerwca 2026 roku Canonical wydał biuletyn USN-8473-1 dla pakietu containerd-stable. W praktyce chodzi o warstwę, która na wielu węzłach Linux odpowiada za uruchamianie workloadów przez CRI, czyli Container Runtime Interface.
To ważny temat dla adminów i zespołów DevOps, bo containerd jest często traktowany jako „niewidzialna” część platformy. Widać Kubernetes, CNI, ingress controller, registry i manifesty YAML, ale sam runtime działa w tle jako usługa systemd. Czerwcowe podatności pokazują, że właśnie tam może pojawić się ścieżka do zatrucia lokalnego cache obrazów, wykonania kodu w innym podzie, wyczerpania pamięci procesu runtime albo obejścia założeń związanych z checkpoint/restore.
Co dokładnie wydarzyło się 18 czerwca 2026 roku
18 czerwca 2026 roku w upstreamowym repozytorium containerd pojawiły się poprawkowe wydania kilku gałęzi: między innymi containerd 2.3.2, 2.2.5, 2.1.9, 2.0.10 oraz 1.7.33. W notach wydań dla gałęzi 2.1, 2.2 i 2.3 wymieniono poprawki dla pięciu CVE: CVE-2026-50195, CVE-2026-53488, CVE-2026-53492, CVE-2026-53489 i CVE-2026-47262. Starsze obsługiwane gałęzie nie zawsze mają ten sam zakres funkcji, dlatego zakres CVE w notach może się różnić zależnie od wersji.
Tego samego dnia AWS opublikował biuletyn 2026-046-AWS opisujący problem w plug-inie CRI containerd. Wskazano tam szczególnie ryzykowną klasę błędów: niezwalidowane dane z obrazów i checkpointów mogą wpływać na zachowanie runtime na współdzielonym węźle Kubernetes. To nie jest abstrakcyjny problem biblioteki Go. To scenariusz, w którym jeden workload może próbować wykorzystać założenia runtime przeciwko innym workloadom działającym na tym samym hoście Linux.
Najważniejsze podatności: cache obrazów, etykiety, CDI i DoS
Najbardziej interesująca z perspektywy operatora Kubernetes jest CVE-2026-50195. Opis wskazuje na niepoprawną walidację referencji obrazów podczas importowania checkpointów kontenerów. Skutek jest praktyczny: atakujący posiadający uprawnienia do tworzenia podów może przygotować złośliwy checkpoint, który zatruwa lokalny cache obrazów na węźle. Jeżeli inny pod na tym samym node używa polityki pobierania obrazu IfNotPresent albo Never, ryzyko rośnie, bo Kubernetes może zaufać temu, co jest już lokalnie dostępne.
CVE-2026-53488 dotyczy propagowania zarezerwowanych etykiet z konfiguracji obrazu do kontenerów bez odpowiedniej sanitizacji. Według biuletynu AWS ten problem nie wymaga włączonego checkpoint/restore, co czyni go szczególnie istotnym dla środowisk, które uznały, że brak użycia checkpointów wystarczy jako zabezpieczenie. W notach containerd widać zresztą poprawkę opisaną jako niepropagowanie zarezerwowanych labeli z konfiguracji obrazów.
CVE-2026-53492 wiąże się z CDI, czyli Container Device Interface. W uproszczeniu chodzi o zaufanie do adnotacji CDI pochodzących z niezaufanych metadanych checkpointu. W środowiskach korzystających z GPU, akceleratorów AI, wyspecjalizowanych urządzeń lub zaawansowanego passthrough sprzętu temat CDI przestaje być niszowy. Linuxowe klastry obsługujące workloady AI coraz częściej mają konfigurację urządzeń wykraczającą poza prosty CPU/RAM/dysk, więc ta powierzchnia ataku będzie ważniejsza niż kilka lat temu.
CVE-2026-53489 opisano jako problem z niezwalidowanymi ścieżkami logów kontenera podczas restore checkpointu, co może prowadzić do odczytu plików z hosta. Z kolei CVE-2026-47262 dotyczy nieograniczonego parsowania grup z obrazu, co może doprowadzić do wyczerpania pamięci i ubicia procesu containerd przez OOM. Taki DoS ma bardzo konkretny efekt operacyjny: kubelet traci sprawny runtime, nowe pody nie startują, restarty mogą się nie wykonywać, a node zaczyna zachowywać się jak częściowo martwy element klastra.
Canonical dołącza z USN-8473-1 z 25 czerwca 2026 roku
25 czerwca 2026 roku Canonical opublikował USN-8473-1 dla containerd-stable. Biuletyn wymienia trzy podatności: CVE-2026-33814, CVE-2026-47262 i CVE-2026-50195. Pierwsza z nich dotyczy obsługi ramek HTTP/2 SETTINGS i potencjalnego wejścia w pętlę CONTINUATION frames, co może skutkować odmową usługi. Canonical oznaczył poprawione wersje dla Ubuntu 26.04 LTS i Ubuntu 25.10 w pakiecie containerd-stable, odpowiednio jako 2.2.2-0ubuntu1.1 oraz 2.1.6-0ubuntu1~25.10.2.
Warto zwrócić uwagę na jeden szczegół: nazewnictwo pakietów w dystrybucji nie zawsze odpowiada bezpośrednio upstreamowym tagom containerd. Administrator nie powinien więc ślepo porównywać tylko numeru upstream, ale sprawdzać status w repozytorium dystrybucji, biuletyny bezpieczeństwa oraz changelog pakietu. W Ubuntu status może różnić się między pakietami containerd, containerd-app i containerd-stable.
Dlaczego to dotyczy Linuxa, a nie tylko Kubernetes
Kubernetes jest tutaj najgłośniejszym przykładem, ale realnym miejscem uderzenia jest linuksowy host. To na nim działa containerd.service, to tam znajduje się lokalny content store i snapshottery, to tam kernel egzekwuje namespace, cgroups, seccomp, AppArmor albo SELinux. Gdy runtime daje się oszukać co do pochodzenia obrazu, ścieżki logów, etykiet lub metadanych checkpointu, konsekwencje dotykają granicy między podami oraz między podem a hostem.
To szczególnie istotne w środowiskach multi-tenant: platformach CI/CD, klastrach deweloperskich, namespace’ach dla wielu zespołów, środowiskach z dynamicznie tworzonymi podami oraz klastrach AI, gdzie użytkownicy uruchamiają eksperymentalne obrazy z własnych registry. Nawet jeśli atak nie daje natychmiastowego roota na hoście, zatrucie cache obrazu albo wykonanie kodu w kontekście innego poda może wystarczyć do kradzieży sekretów aplikacyjnych, tokenów service account, danych z wolumenów lub dostępu do wewnętrznych API.
Co sprawdzić na węzłach Linux
Pierwszy krok to inwentaryzacja. Nie zakładaj, że wszystkie node’y w klastrze mają tę samą wersję runtime, szczególnie po częściowych aktualizacjach, autoskalowaniu lub migracjach obrazów maszyn. Na pojedynczym hoście Linux sprawdź wersję usługi i pakietu:
containerd --version
systemctl status containerd --no-pager
# Ubuntu/Debian
dpkg -l | grep -E 'containerd|runc'
apt-cache policy containerd containerd.io containerd-stable
# RHEL/Fedora/Rocky/Alma
grep -E 'VERSION_ID|PRETTY_NAME' /etc/os-release
rpm -qa | grep -E 'containerd|runc'
W klastrze Kubernetes praktyczniej jest zebrać informacje z poziomu API. Pole containerRuntimeVersion pokaże, co kubelet raportuje dla każdego node’a:
kubectl get nodes -o custom-columns='NODE:.metadata.name,RUNTIME:.status.nodeInfo.containerRuntimeVersion,KERNEL:.status.nodeInfo.kernelVersion,OS:.status.nodeInfo.osImage'
kubectl describe node <nazwa-node-a> | grep -E 'Container Runtime Version|Kernel Version|OS Image'
Jeżeli w środowisku używane są checkpointy, CRIU, funkcje restore, CDI albo pody korzystające z polityki imagePullPolicy: IfNotPresent dla obrazów tworzonych przez wielu użytkowników, ryzyko operacyjne jest większe. Nie oznacza to, że każdy klaster bez tych funkcji jest bezpieczny, ponieważ CVE-2026-53488 według biuletynu AWS nie wymaga checkpoint/restore. Oznacza to jednak, że priorytetyzacja aktualizacji powinna zacząć się od node’ów o największej ekspozycji.
Praktyczny plan aktualizacji
Najbezpieczniejsza ścieżka to aktualizacja przez repozytorium dystrybucji albo mechanizm zarządzania node’ami dostawcy chmury. Ręczne podmienianie binarek containerd z upstreamowych tarballi może być uzasadnione w środowiskach niestandardowych, ale zwiększa ryzyko rozjazdu z unitami systemd, konfiguracją CRI, wersją runc, CNI i politykami dystrybucji. Upstream containerd sam przypomina, że oprócz containerd zwykle potrzebne są także kompatybilne komponenty runc i pluginy CNI.
- Sprawdź, czy używasz gałęzi objętej poprawkami: 2.3.x, 2.2.x, 2.1.x, 2.0.x lub 1.7.x.
- Dla instalacji upstreamowych celuj co najmniej w wydania z 18 czerwca 2026 roku:
2.3.2,2.2.5,2.1.9,2.0.10albo1.7.33, z uwzględnieniem zakresu CVE dla danej gałęzi. - Dla Ubuntu sprawdź biuletyn USN-8473-1 i status konkretnego pakietu, zwłaszcza
containerd-stable,containerd-apporaz klasycznegocontainerd. - Ogranicz użycie
imagePullPolicy: Neveri ostrożnie stosujIfNotPresentw środowiskach, gdzie wiele zespołów współdzieli te same node’y. - Jeżeli checkpoint/restore nie jest wymagane, wyłącz tę funkcję lub ogranicz dostęp do mechanizmów, które pozwalają importować checkpointy.
- Jeżeli CDI nie jest potrzebne na danym poolu node’ów, wyłącz je lub przenieś workloady sprzętowe do osobnego, mocniej kontrolowanego poola.
Hardening po aktualizacji: nie kończ na restarcie usługi
Po aktualizacji runtime trzeba zaplanować restart usług i ewentualne drainowanie node’ów. W produkcyjnym Kubernetes nie warto restartować containerd „na żywo” bez oceny wpływu na działające pody. Standardowy wzorzec to kubectl cordon, następnie kubectl drain z politykami zgodnymi z danym środowiskiem, aktualizacja pakietów, restart usług, test uruchomienia poda kontrolnego i dopiero kubectl uncordon.
Po stronie polityk warto przejrzeć dopuszczanie obrazów i reguły admission control. Jeśli organizacja pozwala uruchamiać obrazy z dowolnych registry, bez podpisów i bez kontroli digestów, problem cache poisoning jest groźniejszy. Używanie referencji po digestach, polityk podpisów, kontrolerów admission i oddzielnych node pooli dla mniej zaufanych workloadów nie zastępuje patchowania, ale istotnie zmniejsza blast radius.
Warto też dodać alerty na objawy awarii runtime: restarty containerd.service, komunikaty OOM w journald, wzrost liczby podów w stanie ContainerCreating, błędy CRI w logach kubeleta oraz nietypowe użycie lokalnego cache obrazów. Przydatne są zarówno metryki node exportera, jak i logi systemd zbierane do centralnego systemu observability.
Podsumowanie praktyczne
Czerwcowe poprawki containerd z 18 czerwca 2026 roku oraz biuletyn Ubuntu USN-8473-1 z 25 czerwca 2026 roku powinny trafić na checklistę każdego zespołu utrzymującego linuksowe węzły Kubernetes. Najważniejsze działania to: zinwentaryzować wersje runtime, zaktualizować containerd z właściwego źródła, ograniczyć checkpoint/restore i CDI tam, gdzie nie są potrzebne, przejrzeć polityki pobierania obrazów oraz monitorować restarty runtime. To nie jest kosmetyczny update biblioteki. To poprawka warstwy, od której zależy izolacja i dostępność kontenerów na hoście Linux.
