Błąd w mechanizmie cgroups jądra Linux przez 14 lat pozwalał programowi z kontenera uruchomić polecenie jako root na całym serwerze. Poprawka jest z 2022 roku, a CISA w czerwcu 2026 potwierdziła ataki. Wyjaśniamy, kogo to dotyczy i co zrobić.
Kontenery miały być osobnymi pokojami dla aplikacji. CVE-2022-0492 pokazało, że pod spodem wszystkie pokoje mają wspólny sufit: jądro systemu Linux. Błąd poprawiono w lutym 2022 roku, a mimo to 2 czerwca 2026 roku amerykańska agencja CISA dopisała go do katalogu luk wykorzystywanych w realnych atakach. Poniżej wyjaśniamy, co to oznacza dla firmy, która trzyma sklep, panel klienta czy system księgowy w kontenerach na jednym serwerze.
Katalog CISA KEV (Known Exploited Vulnerabilities) to lista luk, przy których agencja ma dowody faktycznego wykorzystania, a nie tylko teoretycznej możliwości ataku. Wpis dla CVE-2022-0492 pojawił się 2 czerwca 2026 roku, dzień po tym, jak Kaspersky w analizie ataków na środowiska kontenerowe (Securelist, 1 czerwca 2026) wymienił tę lukę wśród wykorzystywanych technik ucieczki z kontenera. Agencjom federalnym USA wyznaczono termin usunięcia na 5 czerwca 2026, czyli zaledwie trzy dni.
Element | Szczegóły |
|---|---|
Identyfikator CVE | CVE-2022-0492 |
Nazwa w katalogu CISA | Linux Kernel Improper Authentication Vulnerability |
Data dodania do CISA KEV | 2 czerwca 2026 |
Termin usunięcia (dueDate) | 5 czerwca 2026 |
Produkt | Linux, jądro systemu (kernel), funkcja cgroups v1 release_agent |
Wersje zagrożone | Jądra od 2.6.24 do wydań sprzed poprawki: poniżej 4.9.301, 4.14.266, 4.19.229, 5.4.177, 5.10.97, 5.15.20, 5.16.6 oraz 5.17-rc1 i rc2 |
Wersje bezpieczne | 4.9.301, 4.14.266, 4.19.229, 5.4.177, 5.10.97, 5.15.20, 5.16.6, 5.17-rc3 i każde nowsze jądro |
Typ podatności | Eskalacja uprawnień i ucieczka z izolacji kontenera; CWE-862 (brak autoryzacji) oraz CWE-287 (niewłaściwe uwierzytelnienie) |
Ocena CVSS | 7.8/10 WYSOKA według NVD (atak lokalny, niskie uprawnienia); Red Hat: 7.0/10, ważność Important |
Użycie w ransomware | Nieznane (flaga CISA: Unknown) |
Dystrybucje Linuksa wydały własne pakiety z poprawką. To one, a nie numer wersji jądra z kernel.org, są punktem odniesienia dla większości firm:
Dystrybucja | Wersja z poprawką | Biuletyn i data |
|---|---|---|
Debian 11 bullseye | linux 5.10.103-1 | DSA-5095-1, 9 marca 2022 |
Debian 10 buster | linux 4.19.232-1 | DSA-5096-1, 9 marca 2022 |
Debian 9 stretch (LTS) | linux 4.9.303-1 | DLA-2940-1, marzec 2022 |
Ubuntu 20.04 LTS | linux 5.4.0-105.119 | biuletyny USN z marca 2022 |
Ubuntu 18.04 LTS | linux 4.15.0-173.182 | biuletyny USN z marca 2022 |
Ubuntu 22.04 LTS i nowsze | nie dotyczy | jądro wydane już z poprawką |
Red Hat Enterprise Linux 8 | kernel-4.18.0-348.20.1.el8_5 | RHSA-2022:0825, 10 marca 2022 |
Red Hat Enterprise Linux 7 | kernel-3.10.0-1160.66.1.el7 | RHSA-2022:4642, 18 maja 2022 |
Red Hat Enterprise Linux 9 | nie dotyczy | według Red Hat |
Ważne: podatne są też urządzenia z wbudowanym Linuksem, na przykład wymienione w NVD systemy NetApp z serii H oraz SolidFire. Macierze, bramki i appliance'y aktualizuje się firmware'em producenta, a nie poleceniem systemowym.
Wyobraź sobie biuro w otwartej przestrzeni podzielone przepierzeniami. Każdy dział ma swój boks: księgowość, sprzedaż, magazyn. Przepierzenia działają dobrze w codziennej pracy, ale sufit, instalacja elektryczna i portiernia są wspólne. Kontenery działają tak samo: każda aplikacja ma swój boks, ale wszystkie korzystają z jednego jądra systemu.
Przy portierni wisiał zeszyt z rubryką „co zrobić, gdy ostatnia osoba wyjdzie z sali”. Portier wykonywał wpisane polecenie, mając przy sobie klucz do wszystkich pomieszczeń. Problem w tym, że przez 14 lat nikt nie sprawdzał, kto wpisuje polecenia do zeszytu. Intruz, który dostał się do jednego boksu, mógł wpisać „otwórz serwerownię i wynieś dokumenty”, a portier to wykonywał.
Scenariusz | Normalnie | Z podatnością |
|---|---|---|
Granica kontenera | Aplikacja widzi tylko swoje pliki i procesy | Włamywacz z jednego kontenera wychodzi na cały serwer |
Kto może ustawić polecenie release_agent | Tylko administrator głównego systemu | Proces z wnętrza kontenera, w sprzyjającej konfiguracji |
Z jakimi uprawnieniami działa polecenie | Z uprawnieniami nadanymi przez administratora | Z pełnymi uprawnieniami root na serwerze |
Skutek włamania do jednej aplikacji | Szkoda ograniczona do tej aplikacji | Dostęp do wszystkich kontenerów, baz i kopii na maszynie |
Kto kontroluje dane | Firma | Atakujący |
Słowniczek: kontener to wydzielone środowisko dla aplikacji (np. Docker, Kubernetes), które dzieli jądro z innymi kontenerami na tym samym serwerze.
Słowniczek: cgroups (control groups) to mechanizm jądra, który przydziela kontenerom pamięć i procesor; release_agent to program uruchamiany przez jądro, gdy grupa procesów opustoszeje.
Słowniczek: root to najwyższe uprawnienia w systemie Linux, odpowiednik klucza generalnego do budynku.
Poprawka autorstwa Erica W. Biedermana (commit 24f6008564183aa120d07c03d9289519c2fe02af, „cgroup-v1: Require capabilities to set release_agent”) dopisuje w dwóch miejscach ten sam warunek: ustawić release_agent może tylko proces z głównej przestrzeni użytkowników systemu, mający uprawnienie administracyjne CAP_SYS_ADMIN. Portier przestał przyjmować polecenia od osób z korytarza.
Mogę Ci jakoś pomóc?
To nie jest luka, przez którą ktoś wejdzie z internetu prosto na serwer. To drugi krok ataku. Najpierw napastnik musi uruchomić kod wewnątrz kontenera, na przykład przez dziurawą wtyczkę sklepu, wyciek hasła do panelu lub zainfekowany obraz kontenera. Dopiero wtedy CVE-2022-0492 zamienia włamanie do jednej aplikacji w przejęcie całej maszyny.
Według analizy Unit 42 (Palo Alto Networks) ucieczka z kontenera udaje się tylko wtedy, gdy spełnione są wszystkie warunki naraz:
Warunek po stronie kontenera lub serwera | Stan sprzyjający atakowi | Stan blokujący atak |
|---|---|---|
Użytkownik w kontenerze | root lub brak flagi no_new_privs | zwykły użytkownik z no_new_privs |
AppArmor lub SELinux | wyłączone | włączone (domyślnie w Dockerze i OpenShift) |
Seccomp | wyłączony | włączony (domyślny profil Dockera blokuje potrzebne wywołanie) |
Przestrzenie nazw użytkownika | dostępne dla zwykłych użytkowników lub kontener z CAP_SYS_ADMIN | wyłączone, brak CAP_SYS_ADMIN |
Wersja cgroups | cgroups v1 | tylko cgroups v2, gdzie release_agent nie istnieje |
Jądro | sprzed poprawki z lutego 2022 | zaktualizowane |
Timeline ataku:
Etap | Czas | Akcja hakerów | Wynik |
|---|---|---|---|
1 | Dni lub tygodnie wcześniej | Włamanie do aplikacji w kontenerze (podatna wtyczka, skradzione hasło, złośliwy obraz) | Kod napastnika działa w jednym kontenerze |
2 | T+0 min | Sprawdzenie, czy kontener działa jako root, bez seccomp i AppArmor, na cgroups v1 | Potwierdzenie, że ucieczka jest możliwa |
3 | T+2 min | Zamontowanie grupy cgroups i wpisanie własnego skryptu jako release_agent | Jądro przyjmuje wpis bez sprawdzenia uprawnień |
4 | T+3 min | Opróżnienie grupy procesów, co wyzwala uruchomienie skryptu | Skrypt działa jako root na serwerze, poza kontenerem |
5 | T+10 min | Dostęp do pozostałych kontenerów, baz danych, kluczy i kopii zapasowych na maszynie | Pełna kontrola nad serwerem |
6 | T+1 h i dalej | Kopanie kryptowalut, kradzież danych, instalacja trwałego dostępu lub szyfrowanie | Straty operacyjne i wyciek danych |
Etapy 2-4 są dostępne jako gotowe narzędzie: moduł docker_cgroup_escape w Metasploit Framework, publicznym narzędziu testów penetracyjnych, dodany w grudniu 2023 roku. Obniża to próg wejścia dla mniej zaawansowanych atakujących.
Konkretne scenariusze zagrożenia:
Najważniejsza lekcja brzmi: kontener to opis architektury, a nie gwarancja bezpieczeństwa. Jeśli wykonawca mówi „wszystko działa w kontenerach, więc jest bezpiecznie”, właściwe pytanie brzmi: jak stare jest jądro serwera, na którym te kontenery stoją, i kto odpowiada za jego aktualizację.
Obszar biznesu | Potencjalny wpływ | Czas do wystąpienia | Koszty szacunkowe |
|---|---|---|---|
Operacyjny | Przestój wszystkich aplikacji na przejętym serwerze, odtwarzanie maszyny od zera | Godziny po ucieczce z kontenera | 2 000-15 000 EUR za dzień przestoju |
Bezpieczeństwo danych | Wyciek baz klientów, dokumentów, haseł i kluczy API ze wszystkich kontenerów | Minuty po ucieczce | 20 000-150 000 EUR (analiza, powiadomienia, obsługa prawna) |
Finansowy | Koszty reakcji na incydent, rachunki za zasoby chmury zużyte przez koparki | Dni | 10 000-60 000 EUR |
Reputacyjny | Utrata zaufania klientów, szczególnie B2B z danymi powierzonymi | Tygodnie | spadek sprzedaży rzędu 5-20% |
Prawny | Zgłoszenie do UODO w 72 h, kary RODO do 20 mln EUR lub 4% rocznego obrotu, obowiązki NIS2 | Miesiące | od kilku tysięcy EUR do górnych limitów RODO |
Kwoty w tabeli to szacunki poglądowe dla małej lub średniej firmy, a nie dane z konkretnego incydentu; limit kar RODO wynika wprost z przepisów.
Macierz ryzyka (pozycja CVE-2022-0492):
Wpływ
5 | ■ ← CVE-2022-0492 (niezaktualizowane jądro, luźne kontenery)
4 | ■ ■
3 | ■ ■ ■
2 | ■ ■ ■ ■ ● ← to samo CVE przy seccomp + AppArmor/SELinux
1 | ■ ■ ■ ■
+--------------------
1 2 3 4 5 Prawdopodobieństwo
Mogę Ci jakoś pomóc?
Wpływ jest maksymalny, bo CISA ocenia skutek techniczny jako całkowity. Prawdopodobieństwo zależy od konfiguracji: w typowym Dockerze z domyślnymi zabezpieczeniami atak się nie udaje, ale na zapomnianym serwerze z wyłączonymi zabezpieczeniami wystarczy jedna dziurawa aplikacja.
Porównanie przed i po działaniach:
Stan | Przed | Po |
|---|---|---|
Jądro serwera | sprzed lutego 2022, bez restartu od lat | wersja z poprawką, restart zaplanowany |
Kontenery | uruchamiane jako root, część w trybie uprzywilejowanym | zwykły użytkownik, bez CAP_SYS_ADMIN |
Seccomp i AppArmor lub SELinux | wyłączone „bo coś nie działało” | włączone domyślne profile |
Wiedza o infrastrukturze | nikt nie wie, jakie jądro działa u dostawcy | inwentarz wersji i umowa z obowiązkiem aktualizacji |
Priorytet | Działanie | Termin | Odpowiedzialny | Status |
|---|---|---|---|---|
🔴 NATYCHMIAST | Spisać serwery z kontenerami i odczytać wersję jądra (uname -r) | Dzisiaj | IT Manager | ☐ |
🔴 NATYCHMIAST | Zaktualizować jądro do wersji z poprawką (np. Debian 11: 5.10.103-1 lub nowsze, RHEL 8: 4.18.0-348.20.1 lub nowsze) i zrestartować serwer | Dzisiaj lub w najbliższym oknie serwisowym | Administrator systemów | ☐ |
🔴 NATYCHMIAST | Wyszukać kontenery uruchomione z --privileged lub z CAP_SYS_ADMIN i odebrać im te uprawnienia | Dzisiaj | DevOps | ☐ |
🟠 PILNIE | Włączyć seccomp (RuntimeDefault w Kubernetes) oraz AppArmor lub SELinux | Do jutra | DevOps | ☐ |
🟠 PILNIE | Sprawdzić serwery pod kątem nieznanych procesów root, koparek i zmian w plikach release_agent | 24-48 h | Incident Response | ☐ |
🟠 PILNIE | Wysłać dostawcy hostingu pytanie o wersję jądra i datę ostatniej aktualizacji | 48 h | Kierownik zakupów IT | ☐ |
🟡 WAŻNIE | Wdrożyć monitoring zdarzeń mount i unshare w kontenerach (np. Falco, Sysdig) | W ciągu tygodnia | SOC | ☐ |
🟡 WAŻNIE | Zaplanować migrację na cgroups v2 i wspierane wydania systemów | W ciągu miesiąca | Architekt IT | ☐ |
Jeśli aktualizacja nie jest dostępna od razu:
Czasowa miara ochronna | Efektywność | Łatwość wdrożenia |
|---|---|---|
Domyślny profil seccomp dla wszystkich kontenerów | ok. 90% | Wysoka |
AppArmor lub SELinux w trybie wymuszania | ok. 90% | Średnia |
Uruchamianie kontenerów bez roota, bez --privileged i CAP_SYS_ADMIN | ok. 85% | Średnia |
Wyłączenie nieuprzywilejowanych przestrzeni nazw użytkownika na serwerze | ok. 80% | Średnia, może zepsuć część narzędzi |
Poprawka jądra nakładana bez restartu (Canonical Livepatch LSN-0085-1, kpatch w RHEL) | ok. 95% | Wysoka, jeśli usługa jest wykupiona |
Przeniesienie aplikacji z wrażliwymi danymi na osobną maszynę wirtualną | ok. 99% | Niska |
Wartości efektywności to szacunki poglądowe. Red Hat zaznacza, że nie publikuje obejścia spełniającego jego kryteria i pełnym rozwiązaniem jest aktualizacja jądra; w OpenShift i Red Hat Virtualization atak blokuje domyślnie włączony SELinux.
Aspekt | Informacja |
|---|---|
Czy jest wykorzystywana? | TAK, potwierdzone wpisem CISA KEV z 2 czerwca 2026; ocena CISA: wykorzystanie aktywne, atak nieautomatyzowalny, skutek całkowity |
Grupy przestępcze | Brak publicznie potwierdzonych danych; Kaspersky nie wskazał sprawców ani ofiar |
Kampanie ransomware | Brak publicznie potwierdzonych danych (flaga CISA: Unknown) |
Ocena CVSS | 7.8/10 WYSOKA (NVD i CISA), 7.0/10 (Red Hat, wyższa złożoność ataku) |
PoC dostępny publicznie? | TAK: moduł Metasploit docker_cgroup_escape (grudzień 2023), skrypty testowe Unit 42 i inne na GitHub |
Liczba atakowanych firm | Brak publicznie potwierdzonych danych |
EPSS (prawdopodobieństwo próby ataku w 30 dni) | ok. 5,5%, wyżej niż 92% wszystkich ocenianych luk (FIRST, 13 września 2026) |
Dlaczego alarm zabrzmiał cztery lata po poprawce? Nowe serwery od dawna mają poprawione jądro. Ataki trafiają w to, o czym firmy zapomniały: VPS-y bez restartu od 2021 roku, appliance'y z wbudowanym Linuksem, stare węzły Kubernetes i obrazy maszyn wirtualnych klonowane z przestarzałego szablonu.
Linia czasu incydentu:
2008-01 : Jądro 2.6.24 wprowadza release_agent w cgroups (początek podatnego kodu)
2021-11-03 : Aqua Security opisuje koparki uciekające z uprzywilejowanych kontenerów przez release_agent
2022-01-20 : Eric W. Biederman przygotowuje poprawkę (zgłoszenie: Tabitha Sable)
2022-02-04 : Publiczne ujawnienie podatności
2022-02-05 : Stabilne jądra 5.16.6, 5.15.20, 5.10.97 i 5.4.177 z poprawką
2022-02-11 : Starsze gałęzie 4.19.229, 4.14.266 i 4.9.301 z poprawką
2022-02-22 : Ubuntu USN-5302-1, pierwsza z serii poprawek Canonical
2022-03-03 : Publikacja w NVD, analiza Unit 42 o ucieczce z kontenerów
2022-03-09 : Debian DSA-5095-1 i DSA-5096-1
2022-03-10 : Red Hat RHSA-2022:0825 dla RHEL 8
2022-03-23 : Canonical Livepatch LSN-0085-1 (poprawka bez restartu)
2023-12 : Moduł docker_cgroup_escape w Metasploit
2026-06-01 : Kaspersky (Securelist) opisuje wykorzystanie luki w atakach na kontenery
2026-06-02 : CISA dodaje CVE-2022-0492 do katalogu KEV
2026-06-05 : Termin usunięcia dla agencji federalnych USA
2026-09-14 : TUTAJ JESTEŚMY - sprawdź jądra i konfigurację kontenerów teraz ✓ | Zadanie | Kto | Deadline |
|---|---|---|---|
☐ | Pobrać poprawki z repozytorium dystrybucji: Debian https://www.debian.org/security/2022/dsa-5095, Ubuntu https://ubuntu.com/security/CVE-2022-0492, Red Hat https://access.redhat.com/security/cve/CVE-2022-0492 | IT Manager | DZISIAJ |
☐ | Przetestować nowe jądro na serwerze testowym lub jednym węźle klastra | QA / DevOps | DZISIAJ |
☐ | Zakomunikować klientom i zespołom okno serwisowe z restartem | Project Manager | DZISIAJ |
☐ | Wdrożyć jądro na produkcji i zrestartować serwery (lub nałożyć livepatch) | DevOps | DO JUTRA |
☐ | Uruchomić test podatności kontenerów (skrypt Unit 42 can-ctr-escape-cve-2022-0492) | IT Security | DO JUTRA |
☐ | Sprawdzić logi pod kątem montowania cgroups i nietypowych procesów root | SOC | DO JUTRA |
☐ | Potwierdzić wersje jądra po restarcie i zamknąć zadanie w rejestrze ryzyk | IT Manager | Za 3 dni |
☐ | Uzupełnić umowę z hostingiem o obowiązek aktualizacji jądra w określonym czasie | CFO / dział prawny | W ciągu miesiąca |
Źródło techniczne poprawki: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af
Mogę Ci jakoś pomóc?
# | Pytanie | Odpowiedź | Priorytet |
|---|---|---|---|
1 | Czy mamy serwery z jądrem Linux starszym niż 4.9.301, 4.14.266, 4.19.229, 5.4.177, 5.10.97 lub 5.15.20 (albo pakietem dystrybucji bez poprawki z 2022)? | TAK / NIE | 🔴 |
2 | Jakie jądro działa dziś na każdym serwerze z kontenerami i kiedy był ostatni restart? | Lista serwerów z wynikiem uname -r | 🔴 |
3 | Czy którykolwiek kontener działa z --privileged, jako root lub z CAP_SYS_ADMIN? | TAK / NIE | 🔴 |
4 | Czy seccomp oraz AppArmor lub SELinux są włączone na wszystkich hostach i w Kubernetes? | TAK / NIE | 🟠 |
5 | Czy nasze urządzenia z wbudowanym Linuksem (np. macierze NetApp) mają aktualny firmware? | TAK / NIE | 🟠 |
6 | Czy umowa z dostawcą hostingu obejmuje aktualizacje systemu, a nie tylko dostępność sprzętu? | TAK / NIE | 🟠 |
7 | Czy mamy wykupioną poprawkę jądra bez restartu (Livepatch, kpatch)? | TAK / NIE | 🟡 |
8 | Czy kopie zapasowe są przechowywane poza serwerem, na którym stoją kontenery? | TAK / NIE | 🟡 |
Pytania diagnostyczne dla managera:
Podsumowanie dla zarządu: 🔴 luka jest atakowana, ale wymaga wcześniejszego włamania do kontenera. 🟠 Ochroną jest aktualne jądro i włączone domyślne zabezpieczenia kontenerów. 🟡 Najczęstszym słabym punktem nie jest technologia, tylko zapomniany serwer, którego nikt nie aktualizował od 2021 roku.
Mogę Ci jakoś pomóc?
Zestaw zmienia się codziennie, więc przy kolejnej wizycie zobaczysz inny wycinek bloga.
Błąd w NetScaler ADC i Gateway, opisany przez producenta jako awaria, pozwala według badaczy przejąć bramę VPN bez hasła. Publiczny kod istnieje, ataki trwają. Zaktualizuj urządzenia i sprawdź ślady włamania.
Czytaj artykułPrzepełnienie bufora w FortiOS i FortiSwitchManager pozwala bez hasła uruchomić kod na zaporze. CISA potwierdza ataki, a przestępcy instalują trojana PivotC2. Zaktualizuj FortiOS i sprawdź zapory pod kątem włamania.
Czytaj artykułLuka o ocenie 10.0 w SonicWall SMA1000 daje dostęp do funkcji urządzenia bez logowania, a z CVE-2026-83549 pozwala je przejąć. SonicWall i CISA potwierdzają ataki. Zainstaluj hotfix i sprawdź urządzenie.
Czytaj artykułKrótka rozmowa wystarczy, żeby ocenić zakres prac i podać widełki kosztu. Bez zobowiązań.
Klikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.