Przez ponad osiem lat nikt nie zauważył, że w jądrze Linuksa siedzi błąd, który dosłownie otwiera drzwi do roota każdemu, kto ma konto zwykłego użytkownika. Nie chodziło o zaawansowany atak zero-day wymagający miesięcy pracy – exploit ma 732 bajty, działa w Pythonie ze standardowej biblioteki i uruchamia się jedną linią w terminalu. Podatność CVE-2026-31431, nazwana Copy Fail, dotyka każdej dystrybucji Linuksa zbudowanej po 2017 roku, w tym popularne Ubuntu, Debian, RHEL, Fedora, Arch, SUSE. Jeśli zarządzasz serwerem linuksowym albo masz na nim konto – masz powód, żeby przeczytać ten tekst do końca.
Skąd się wziął błąd
Wszystko zaczyna się w module algif_aead, będącym częścią interfejsu AF_ALG – czyli mechanizmu, który pozwala programom w przestrzeni użytkownika korzystać z kryptograficznych funkcji jądra. W 2017 roku ktoś wdrożył tam optymalizację wydajności dla operacji „w miejscu” (ang. in-place). Pomysł był dobry – dane nie muszą być kopiowane, co przyspiesza operacje. Problem w tym, że implementacja miała błąd logiczny: algorytm authencesn wykonuje 4-bajtowy zapis poza granicą wyjściowego bufora, co skutkuje uszkodzeniem page cache – pamięci podręcznej plików jądra.
Page cache jest współdzielony między wszystkimi procesami. Jeśli uda się tam wstrzyknąć zmodyfikowany kod binarny setuid (np. /usr/bin/su), jądro załaduje zmodyfikowaną wersję przy następnym wywołaniu i uruchomi ją z uprawnieniami roota. Co ważne, modyfikacja nie jest trwała, po restarcie systemu znika. Na dysku nic się nie zmienia.
Kogo dotyczy luka
Praktycznie każdego, kto używa Linuksa z jądrem zbudowanym między 2017 a datą wydania łatki. Badacze z Theori bezpośrednio przetestowali podatność na Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 i SUSE 16. Jednakowe zachowanie wykazują też Debian, Arch, Fedora, Rocky, Alma i Oracle Linux.
Exploit działa niezależnie od dystrybucji, bo AF_ALG jest domyślnie włączony w praktycznie każdej konfiguracji jądra. Nie potrzebujesz dostępu sieciowego, nie potrzebujesz żadnych specjalnych uprawnień, nie musisz majstrować przy debugowaniu jądra. Wystarczy, że masz konto lokalnego użytkownika i Python 3.10.
Żeby zobrazować skalę problemu w 2024 roku w jądrze Linuksa zidentyfikowano 3108 podatności CVE – to wzrost o 79% względem roku 2023. W 2025 roku liczba skoczyła do 5530. Copy Fail wyróżnia się jednak na tle całego zgiełku – jest niezawodny i działa na wszystkich dystrybucjach bez żadnych modyfikacji.
Jak działa exploit krok po kroku
Theori opublikowało gotowy skrypt PoC liczący zaledwie 732 bajty – mniej niż typowy e-mail powitalny z działu HR. Skrypt jest napisany w czystym Pythonie, wymaga wyłącznie biblioteki standardowej (os, socket, zlib) i domyślnie celuje w /usr/bin/su.
Po wykonaniu exploita system zwracał:
# id uid=0(root) gid=1002(user) groups=1002(user)
Exploit przebiega w czterech wywołaniach systemowych, bez wyścigu (ang. race condition), bez zgadywania adresów pamięci i bez żadnych „magicznych” warunków wstępnych. Zespół Theori – ten sam, który wielokrotnie wygrywał DEF CON CTF i zajął trzecie miejsce w konkursie DARPA AIxCC, znalazł błąd w niecałą godzinę używając narzędzia Xint Code do analizy podsystemu crypto/ jądra.
Warto podkreślić, że uruchamianie exploita na systemach, których nie jesteś właścicielem albo do testowania których nie masz pisemnego pozwolenia, jest łamaniem prawa. Można go uyć tylko na systemach, do których masz pozwolenie, w celu sprawdzenia podatności.
Szczegółowe informacje znajdują się na stronie copy.fail (w momencie pisania artykułu luka została już załatana – zalecana aktualizacja jeśli tego jeszcze nie zrobiłeś).
Największe zagrożenie – środowiska wielodostępne
Podatność jest szczególnie groźna wszędzie tam, gdzie wiele osób lub procesów współdzieli to samo jądro. W środowiskach Kubernetes i klastrach kontenerowych page cache jest wspólny dla całego hosta, więc przecięcie jednego poda może przełożyć się na przejęcie całego węzła. Microsoft Defender opisał Copy Fail jako zagrożenie dla „milionów klastrów Kubernetes”.
Systemy CI/CD to kolejna kategoria wysokiego ryzyka. GitHub Actions self-hosted runners, GitLab CI, Jenkins – każde z nich wykonuje kod z zewnętrznych pull requestów jako zwykły użytkownik na współdzielonym jądrze. W praktyce oznacza to, że dostawca złośliwego oprogramowania może uzyskać roota na serwerze budującym projekt.
Cloudowe usługi SaaS uruchamiające kod użytkownika (notebooki, środowiska sandbox, funkcje serverless) zamykają listę scenariuszy o wysokim priorytecie. Dla standardowych serwerów produkcyjnych z dostępem tylko dla zaufanego zespołu ryzyko jest niższe – błąd służy wtedy jako skok uprawnień po wcześniejszym przejęciu konta zwykłego użytkownika przez inną podatność lub skradzione dane logowania.
Jak się zabezpieczyć?
Docelowe rozwiązanie jest jedno – aktualizacja jądra do wersji zawierającej commit a664bf3d603d, który cofa optymalizację algif_aead z 2017 roku. Większość głównych dystrybucji udostępniła już łatki. Sprawdź dostępność aktualizacji przez standardowy menedżer pakietów swojej dystrybucji – apt, dnf, zypper lub odpowiednik.
Jeśli z jakiegoś powodu nie możesz od razu zaktualizować jądra, tymczasowym obejściem jest wyłączenie modułu algif_aead. Wykonujesz to dwoma poleceniami jako root:
# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf # rmmod algif_aead
Dobre wieści są takie, że wyłączenie tego modułu niemal niczego nie psuje. Nie wpływa na dm-crypt/LUKS, kTLS, IPsec, SSH ani domyślne konfiguracje OpenSSL/GnuTLS. Moduł AF_ALG jest frontem dla przestrzeni użytkownika, jego wyłączenie powoduje jedynie, że aplikacje, które go używają, cofają się do bibliotek kryptograficznych w przestrzeni użytkownika, co dla ogromnej większości systemów jest standardem.
Jeśli zarządzasz środowiskami kontenerowymi lub CI/CD, dodatkowym krokiem jest blokada tworzenia gniazd AF_ALG przez seccomp – niezależnie od stanu łatki jądra.
Możesz sprawdzić, czy cokolwiek w systemie aktywnie używa AF_ALG, poleceniem:
lsof | grep AF_ALG
lub:
ss -xa
Jak do tego doszło?
Copy Fail jest świetnym przykładem na to, że bezpieczeństwo i wydajność nie zawsze idą w parze. Ktoś w 2017 roku wprowadził optymalizację, która była poprawna z punktu widzenia wydajności, lecz niosła ze sobą subtelny błąd logiczny. Kod przeszedł review, testy i na osiem lat trafił do produkcji na setkach milionów serwerów. Podatność dostała wynik CVSS 7.8 i trafiła do katalogu aktywnie eksploatowanych podatności CISA KEV.
Dla porównania w Q4 2025 liczba użytkowników Linuksa, którzy zetknęli się z exploitami, podwoiła się w stosunku do Q3 2025. Ponad połowa wszystkich ataków linuksowych z użyciem exploitów w 2025 roku przypadła właśnie na czwarty kwartał roku. Wspomniana liczba będzie w 2026 roku wyższa – Copy Fail z pewnością dołoży do statystyk swoją cegiełkę.
Ujawnienie Copy Fail wskazuje też, w jakim kierunku zmierza bezpieczeństwo ofensywne – błąd znaleziony przez AI w niespełna godzinę, w podsystemie, który przeszedł przez ludzkie code review bez zastrzeżeń przez prawie dekadę. Łatka jest dostępna, harmonogram ujawnienia był odpowiedzialny – od zgłoszenia do upublicznienia minęło ponad pięć tygodni. Teraz piłka jest po stronie administratorów systemów. Aktualizacja jądra to nie jest przyjemna robota w piątek rano, ale Copy Fail bardzo skutecznie podnosi jej priorytet.
Źródło: copy.fail, GitHub, Własne
