Przejdź do treści
Infrastruktura

Luka w jądrze Linuksa CIFSwitch: 19-letnie ryzyko eskalacji do roota w dystrybucjach Ubuntu, Kali i Rocky Linux

Nowo odkryta luka CVE-2026-46243 w jądrze Linuksa, nazwana CIFSwitch, umożliwia lokalne uzyskanie uprawnień roota. Artykuł wyjaśnia mechanizm podatności, zagrożone dystrybucje i konkretne kroki obronne dla administratorów.

4 min read
An abstract representation of a Linux kernel: a translucent shield with multiple layers being cracked from the inside by a single glowing exclamation mark, while a lock symbol remains intact in the background. No text or readable elements.

Wykryto podatność w fundamencie systemu Android – luka CVE-2026-46243 w jądrze Linuksa Nowo odkryta luka w jądrze Linuksa, oznaczona jako

CVE-2026-46243

i nazwana

“CIFSwitch”

, umożliwia lokalnemu atakującemu uzyskanie uprawnień administratora (root) w wielu dystrybucjach Linuksa, w tym popularnych w Polsce wersjach Ubuntu, Kali Linux, Rocky Linux oraz AlmaLinux. Problem nie wynika z błędów w aplikacjach użytkownika, lecz z zaufanego mechanizmu uwierzytelniania w samym jądrze. Dla firm i użytkowników korzystających z Linuksa oznacza to jedno: im szybciej zostaną wdrożone łaty, tym mniejsze ryzyko nieautoryzowanego przejęcia systemów i kradzieży danych.

Jak działa “CIFSwitch” – podatność ukryta od prawie 20 lat

Luka CVE-2026-46243 dotyczy podsystemu CIFS (Common Internet File System) w jądrze Linuksa, który służy do montowania udziałów sieciowych. Kiedy udział wymaga uwierzytelniania Kerberos, jądro odwołuje się do programu pomocniczego w przestrzeni użytkownika –

cifs.upcall

– który działa z uprawnieniami roota. Jak wyjaśnia

Asim Viladi Oglu Manizada

, inżynier bezpieczeństwa w SpaceX, który odkrył i nazwał podatność: „The kernel requests a cifs.spnego-type key, and the normal keyutils/request-key config runs cifs.upcall as root to fetch or build the Kerberos/SPNEGO material”. Problem powstaje, ponieważ jądro nie weryfikuje, czy żądanie klucza cifs.spnego pochodzi rzeczywiście od klienta CIFS jądra. Nieuprawniony użytkownik może sfałszować takie żądanie i uruchomić cały mechanizm uwierzytelniania. Manizada dodaje, że atakujący może „force a namespace switch and then triggering a Name Service Switch (NSS) lookup before privileges are dropped”. Dzięki temu atakujący ładuje złośliwy moduł NSS i wykonuje kod jądra z poziomem roota, przejmując całkowitą kontrolę nad systemem.

Które systemy są zagrożone, a które już chronione?

Manizada potwierdził, że luka została wprowadzona do jądra w 2007 roku – prawie 19 lat temu. Nie oznacza to jednak, że wszystkie dystrybucje są podatne w równym stopniu.

Lista dystrybucji podatnych w domyślnej konfiguracji

:

Linux Mint 21.3 / 22.3, CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, Kali Linux 2021.4–2026.1, SLES 15 SP7

. Badacz zaznacza, że wiele wersji Ubuntu, Debian, Pop!_OS, openSUSE, Oracle Linux oraz Amazon Linux może być zagrożonych, jeśli jest zainstalowany pakiet

cifs-utils

. Z kolei dystrybucje takie jak

Ubuntu 26.04, Fedora 40-44, CentOS Stream 10, Rocky Linux 10, SLES 16, AlmaLinux 10 czy openSUSE Leap 16

domyślnie blokują możliwość wykorzystania luki za pomocą polityk SELinux lub AppArmor. Całkowicie bezpieczne z uwagi na brak funkcji przełączania przestrzeni nazw pozostały Amazon Linux 2 oraz starsze wersje Kali.

Jak się bronić – praktyczne kroki dla administratorów

Producenci jądra Linuksa opublikowali już poprawkę (

upstream commit 3da1fdf

), która dodaje walidację pochodzenia żądań cifs.spnego. Ponieważ wersje jądra różnią się między dystrybucjami, każdy administrator powinien niezwłocznie:

  • Zaktualizować jądro i pakiet cifs-utils do najnowszej stabilnej wersji dostępnej dla danej dystrybucji – to priorytet.
  • Wyłączyć moduł CIFS, jeśli nie jest potrzebny w środowisku. W wielu firmach protokół ten bywa wyparty przez nowsze rozwiązania, a wyłączenie nieużywanego modułu eliminuje podatność.
  • Usunąć cifs-utils, jeżeli żaden system nie wymaga montowania udziałów sieciowych za pomocą Kerberos.
  • Ograniczyć dostęp do przestrzeni nazw użytkownika – wyłączenie nieuprzywilejowanych przestrzeni nazw (unprivileged user namespaces) znacząco utrudnia eksploatację luki.
  • Przetestować środowisko – Manizada opublikował działający exploit proof-of-concept. Mimo że kod ten został udostępniony w celu testów, każda organizacja może wykorzystać go w bezpiecznym środowisku laboratoryjnym do potwierdzenia skuteczności wdrożonych poprawek i konfiguracji.

Co dalej – szerszy kontekst i długofalowe wnioski

CIFSwitch nie jest pojedynczym incydentem. W ostatnich miesiącach opublikowano podobne podatności eskalacji uprawnień w Linuksie:

‘Copy Fail’, ‘Dirty Frag’, ‘Fragnesia’, ‘DirtyDecrypt’ czy ‘PinTheft’

. Jak zauważa Cisco Talos w swoim newsletterze Threat Source: „frontier AI models autonomously discovering and exploiting zero-days in minutes, the traditional vulnerability lifecycle has completely collapsed”. Oznacza to, że tempo odkrywania nowych luk znacząco wyprzedza tempo łatania. W tej sytuacji kluczowe staje się nie tylko szybkie wdrażanie poprawek, ale także budowanie głębokiej obrony: segmentacja sieci, kontrola dostępu, monitorowanie anomalii i minimalizacja zbędnych usług. Dla polskich administratorów CIFSwitch to sygnał, że tak utrwalone i zaufane technologie jak protokół CIFS mogą kryć dziedziczone przez dekady błędy. Nie należy ufać domyślnej konfiguracji jądra – nawet jeśli system jest aktualizowany regularnie, pojedyncza linijka kodu bez walidacji może zniweczyć całe zabezpieczenia. Wykorzystanie luki jest lokalne, co oznacza, że atakujący musi już mieć dostęp do terminala lub zainfekowanego procesora. Dlatego warto w pierwszej kolejności zabezpieczyć serwery wielodostępne, skrzynki developerskie oraz stacje robocze z zainstalowanymi narzędziami CIFS. Tam ryzyko jest największe. Regularne audyty, polityki AppArmor i SELinux oraz monitorowanie logów systemowych pozwolą wychwycić próby eskalacji, zanim sprawca zdoła wykraść dane lub utrwalić obecność. Źródło:

BleepingComputer – New CIFSwitch Linux flaw gives root on multiple distributions

oraz

Cisco Talos – A tale of two eras

.

Redakcja sekuret.pl

Redakcja sekuret.pl

AUTHOR