CVE-2022-0492 – Ucieczka z kontenera przez cgroups v1. CISA wpisuje podatność do KEV cztery lata po patchu

CVE-2022-0492 to podatność klasy privilege escalation w jądrze Linux, zlokalizowana w funkcji cgroup_release_agent_write w pliku kernel/cgroup/cgroup-v1.c. Oceniona na CVSS 7.8 (High), umożliwia lokalnemu atakującemu eskalację uprawnień i obejście izolacji namespace'ów.

Podatność jest o tyle wyjątkowa, że pozwala użytkownikowi działającemu wewnątrz kontenera Docker lub Kubernetes uciec z jego środowiska i uruchomić dowolny kod jako uprzywilejowane konto na hoście — bez wymagania żadnej konkretnej capability.

Dlaczego to ważne teraz, w 2026?

Podatność, oryginalnie załatana w 2022 roku, została 2 czerwca 2026 dopisana do katalogu CISA Known Exploited Vulnerabilities (KEV) z terminem remediacji dla agencji federalnych wyznaczonym na 5 czerwca 2026. Czterolecia przerwy między wydaniem patcha a wpisem do KEV to klasyczny wzorzec: duża część systemów produkcyjnych — szczególnie legacy, air-gapped i urządzeń embedded — nigdy nie dostała aktualizacji jądra Linuxa.

Wpis do KEV to wyraźny sygnał aktywnej eksploatacji. Atakujący odkryli, że znaczna populacja niezaktualizowanych systemów nadal jest podatna, opracowali tooling i zaczęli go wdrażać.

Jak działa mechanizm ataku

Fundamentem podatności jest funkcja release_agent w cgroups v1.

Jedną z cech cgroups v1 jest plik release_agent. Pozwala administratorom skonfigurować program, który zostanie uruchomiony w momencie zakończenia wszystkich procesów w danej cgroup. Gdy proces umiera, kernel sprawdza, czy cgroup miała włączone notify_on_release.

W kontekście kontenerów oznacza to, że atakujący z dostępem do operacji na filesystem cgroup — z poziomu kontenera lub ograniczonego procesu — może zmanipulować konfigurację release_agent i wykonać dowolne polecenia na hoście z podniesionymi uprawnieniami.

Problem wyróżnia się prostotą: kernel Linuksa błędnie udostępnił uprzywilejowaną operację nieuprzywilejowanym użytkownikom. Atakujący może podmontować cgroupfs w nowym user namespace, a następnie zmodyfikować plik release_agent.

Podatność dotyczy wyłącznie cgroups v1 — aktualnie znacznie powszechniejszej architektury. Cgroups v2 nie implementuje funkcji release_agent i nie jest podatne.

Czego dotyczy podatność

Zagrożone są przede wszystkim:

• hosty kontenerowe z Docker, Kubernetes, LXC lub innymi runtime'ami korzystającymi z cgroups v1,
• legacy serwery Linux, urządzenia embedded i IoT, które nie otrzymały aktualizacji kernela,
• systemy air-gapped z vendor-locked kernelami.

Większość aktualnych dystrybucji (Ubuntu 20.04+, RHEL 8+, Debian 11+) dostarcza już załatane kernele. Ryzyko koncentruje się na instalacjach, gdzie kernel hosta był zaniedbany na rzecz patchwania samych kontenerów.

Wpływ na środowiska Kubernetes

W klastrach Kubernetes, bez odpowiednich pod security policies, eskalacja może być kaskadowa: atakujący kompromituje jeden kontener, exploituje podatność na hoście z cgroups v1, ucieka na node i potencjalnie uzyskuje dostęp do wszystkich podów zaplanowanych na tym węźle, a stąd może pivotować do kolejnych węzłów klastra.

Kiedy jesteś chroniony

Domyślny seccomp filter Dockera oraz polityka AppArmor blokują eksploatację tej podatności. Kontenery uruchomione z AppArmor, SELinux lub Seccomp są bezpieczne.

Problem dotyczy środowisk uruchamianych bez tych hardenigów lub z nadmiarowymi uprawnieniami — co w praktyce produkcyjnej nie jest rzadkością.

Jak sprawdzić, czy używasz cgroups v1

Na hoście:

bash

# cgroups v1 – wiele podkatalogów (cpu, memory, devices, ...)
ls /sys/fs/cgroup/

# cgroups v2 – unified hierarchy (jeden katalog z plikami cgroup.*)
cat /sys/fs/cgroup/cgroup.controllers

W Kubernetes sprawdź konfigurację kubeleta:

bash

kubectl get node <node-name> -o yaml | grep cgroupDriver
# lub
cat /var/lib/kubelet/config.yaml | grep cgroupDriver

Driver cgroupfs wskazuje zazwyczaj na v1, systemd w połączeniu z nowoczesną dystrybucją — na v2.

Remediacja

Kroki do podjęcia:

1. Zaktualizuj kernel hosta — użyj apt update && apt upgrade (Debian/Ubuntu) lub dnf update kernel (RHEL/Fedora). Sprawdź wersję przez uname -r i porównaj z security advisory swojej dystrybucji.

2. Zrestartuj hosty — aktualizacje kernela wymagają restartu. Jeśli restarty są problematyczne, rozważ live-patching (Canonical Livepatch, KernelCare), ale zaplanuj pełny restart.

3. Zmigruj do cgroups v2 — jeśli środowisko to umożliwia, migracja z v1 na v2 eliminuje powierzchnię ataku związaną z release_agent całkowicie. Docker 20.10+, containerd 1.4+ i Kubernetes 1.25+ w pełni wspierają cgroups v2.

4. Weryfikuj hardeningi kontenerów — upewnij się, że AppArmor, SELinux lub Seccomp są aktywne dla wszystkich workloadów.

Podsumowanie

CVE-2022-0492 nie jest nową podatnością — patch istnieje od czterech lat. Wpis do CISA KEV w czerwcu 2026 to jednak twarde potwierdzenie, że ktoś aktywnie szuka i kompromituje niezaktualizowane systemy. W środowiskach kontenerowych container escape oznacza kompromitację całego węzła, a w gorzej skonfigurowanych klastrach — potencjalnie całego klastra.

Zweryfikuj wersje kerneli na hostach kontenerowych. Jeśli nadal działasz na cgroups v1 bez seccomp/AppArmor, traktujesz to jako incydent wymagający natychmiastowej reakcji — nie jako zadanie w backlogu.

Źródła: NVD, CISA KEV, Sysdig, Palo Alto Unit 42, Aqua Security, threat-modeling.com