Osoby, które samodzielnie hostują serwer VPN Amnezia, powinny jak najszybciej sprawdzić jego konfigurację i zainstalować aktualizacje. Krytyczna luka w jądrze Linuksa może narazić serwery korzystające z protokołu Xray na przejęcie przez atakującego. Użytkownicy usług Amnezia Premium, Free i Business nie muszą podejmować działań — dostawca informuje, że zaktualizował już własną infrastrukturę.
Na czym polega zagrożenie?
Luka oznaczona jako CVE-2026-98432 dotyczy obsługi nowych połączeń TCP przez IPv4. Jest obecna w Linuksie od wersji 4.4, a jej ocenę ważności określono na 9,8 w dziesięciostopniowej skali.
Problem ma charakter tzw. wyścigu, czyli błędu, który może doprowadzić do nieprawidłowego zarządzania pamięcią podczas obsługi połączenia sieciowego. Według opisu zagrożenia wykorzystanie luki nie wymaga działania użytkownika ani znajomości hasła, a przejęcie podatnego serwera może zająć około 53 minut.
Luki w jądrze systemu mogą stanowić poważne zagrożenie dla serwerów dostępnych z internetu. Szczególną uwagę powinny zwrócić osoby samodzielnie zarządzające własną infrastrukturą VPN. Warto regularnie sprawdzać komunikaty dostawcy i instalować zalecane aktualizacje.
Dlaczego szczególnie zagrożony jest Xray?
Atak wykorzystuje funkcję MPTCP, czyli rozszerzenie TCP umożliwiające korzystanie z wielu ścieżek sieciowych. Xray, używany między innymi przez odporne na cenzurę protokoły takie jak VLESS, może włączyć MPTCP domyślnie, ponieważ jest napisany w języku Go.
W efekcie administrator serwera może nie wiedzieć, że funkcja zwiększająca ryzyko jest aktywna. Amnezia ocenia użytkowników Xray jako grupę szczególnie narażoną i zaleca im wykonanie aktualizacji.
MacPaw przenosi ClearVPN, który stawia prywatność na pierwszym miejscu, na największe domowe ekrany. Sprawdź także, jak rozwijają się rozwiązania VPN dla użytkowników domowych.
Jak zabezpieczyć własny serwer Amnezia?
Do przeprowadzenia opisanej procedury potrzebna jest aplikacja Amnezia w wersji 5.1.0.6 lub nowszej. Aktualizacja obejmuje usunięcie Xray, zaktualizowanie pakietów systemowych i ponowną instalację protokołu.
W aplikacji wykonaj następujące czynności:
- Otwórz Ustawienia, przejdź do sekcji Serwery i wybierz swój serwer.
- Na karcie Protokoły usuń Xray.
- Przejdź do karty Zarządzanie i wybierz opcję aktualizacji pakietów serwera.
- Po wyświetleniu komunikatu uruchom serwer ponownie — to pozwoli załadować zaktualizowane jądro.
- Wróć do karty Protokoły i zainstaluj Xray ponownie.
Nowa instalacja Xray korzysta z wersji 26.10.31. Podczas ponownego uruchamiania serwer będzie niedostępny, a dotychczasowe połączenia przestaną działać. Po zakończeniu aktualizacji może być konieczne ponowne udostępnienie dostępu użytkownikom.
Ważne zastrzeżenie i rozwiązania tymczasowe
Samo użycie przycisku aktualizacji pakietów nie daje gwarancji, że system otrzymał już poprawioną wersję jądra. W niektórych wydaniach Ubuntu łatka jest dostępna jedynie w kanale testowym „-proposed”, a ponowne uruchomienie serwera może sprawić, że problem powróci. Do czasu wydania poprawki w aplikacji Amnezia po takim restarcie może być konieczne ponowne przeinstalowanie Xray.
Jeśli nie możesz na razie zaktualizować jądra, Amnezia sugeruje tymczasowe zablokowanie opcji IP za pomocą reguły zapory sieciowej. Innym rozwiązaniem jest usunięcie Xray i przejście na oparty na UDP protokół AmneziaWG.
Jeśli ktoś self-hostuje Amnezię z Xray to nie ma co zwlekać — update teraz. MPTCP w Go włączony domyślnie to petarda: race condition w stosie TCP = idealna wekselka dla exploitów. Szybkie usunięcie Xray, aktualizacja pakietów i restart to minimum, a potem reinstalacja 26.10.31.
Szczerze? To wygląda na kolejną chaotyczną reakcję zamiast przemyślanej polityki bezpieczeństwa. Amnezia mogła od razu zablokować MPTCP w swoich obrazach zamiast każdemu mówić „usuń i zainstaluj na nowo”. Dodatkowo poleganie na kanale -proposed w Ubuntu to proszenie się o niespójne stany po reboocie — nie ufam takim instrukcjom dla produkcyjnych VPS.
CVE-2026-98432 to klasyczny race / use-after-free przy obsłudze nowych socketów TCP (MPTCP/IPv4). Kilka praktycznych kroków: 1) sprawdź kernel: uname -r; 2) sprawdź czy kernel ma MPTCP: zgrep CONFIG_MPTCP /boot/config-$(uname -r) || (zcat /proc/config.gz 2>/dev/null | grep MPTCP); 3) jeżeli jest opcja sysctl dla MPTCP to można tymczasowo wyłączyć (spróbuj sysctl -a | grep -i mptcp), ale nie wszystkie dystrybucje expose’ują to. Zawsze weryfikuj, która wersja kernela zawiera poprawkę (changelog pakietu linux-image) zanim zaufasz samej procedurze w aplikacji.
Mam Amnezie na VPS od roku i wlasnie przerabialem ten update — reinstalacja Xray zrobila przerwe ok. 20 min, ale musialem recznie przywracac niektore ustawienia i users.conf. Uwaga: zaplanuj maintenance window i poinformuj uzytkownikow, bo po restarcie serwer moze byc nieosiagalny. (tak, troche sie spieszylem i zostawilem typo w configu przy pierwszym uruchomieniu).
Ktoś może podpowiedzieć praktyczne reguły nft/iptables do „zablokowania opcji IP”? W artykule sugerują blokadę opcji IP jako workaround — czy to wystarczy dla serwera z Xray, czy lepiej od razu przesiadać się na AmneziaWG (UDP)? Mam klientów na VLESS/Vmess i boję się, że przejście na UDP popsuje kompatybilność.
Sytuacja pokazuje dwa problemy: 1) coraz więcej funkcjonalności trafia do kernele bez świadomości adminów (MPTCP włącza się „po drodze”), 2) brak koordynacji między dystrybucjami a dostawcami aplikacji. Amnezia mogła przygotować obraz z MPTCP wyłączonym domyślnie lub dostarczyć jasne skrypty rollbacku. Po takich wpadkach zaczynam patrzeć inaczej na zaufanie do hostowanego stosu — nie każdemu warto oddawać full control.