sshole (CVE-2026-123158): luka w OpenSSH uderzająca w Alpine Linux i jak ją naprawić

Przez Eoin Villarin, 2026-11-07

- Luka w OpenSSH zwana sshole pozwala atakującym na zalogowanie się do kont bez hasła na Alpine Linux i innych systemach opartych na musl, i jest już wykorzystywana. Kto jest zagrożony, jak sprawdzić serwery i jak to naprawić.

Czy jestem dotknięty luką sshole w OpenSSH?

Jesteś zagrożony, jeśli serwer działa z OpenSSH starszym niż 10.6p2 na systemie opartym na musl, takim jak Alpine Linux bez PAM, umożliwia logowanie za pomocą hasła SSH i ma konto, którego pole hasła jest tylko gwiazdą obok innego konta z rzeczywistym skrótowaniem hasła. Debian, Ubuntu, Fedora i konfiguracje korzystające z PAM nie są zagrożone.

Kluczowe wnioski

CVE-2026-123158, zwana sshole, pozwala atakującym na logowanie się do kont bez hasła w systemach Linux opartych na musl poprzez wysłanie zbyt dużego hasła.
Pakiet openssh-server Alpine Linux'a jest podatny, podczas gdy systemy oparte na glibc, takie jak Ubuntu i konfiguracje korzystające z PAM, nie są.
Atakujący wykorzystali ją mniej niż dziewięć godzin po opublikowaniu i uzyskali dostęp do roota na honeypot.
Fix jest OpenSSH 10.6p2 lub pakietem patched Alpine dla Twojej gałęzi, po którym następuje restart sshd.
Jeśli nie możesz zaktualizować jeszcze, ustaw PasswordAuthentication no i użyj kluczy SSH.

Nowo ujawniona luka w OpenSSH zwana sshole, śledzona jako CVE-2026-123158, pozwala atakującym na zalogowanie się do pewnych kont Linux, które nie powinny przyjmować haseł. Wpływa na OpenSSH na systemach opartych na musl, takich jak Alpine Linux, została naprawiona 5 listopada 2026 r., a atakujący zaczęli ją wykorzystywać mniej niż dziewięć godzin po opublikowaniu. Jeśli korzystasz z serwerów Alpine, obrazów Docker opartych na Alpine z SSH lub małych urządzeń na OpenWrt, sprawdź je dzisiaj.

Co to jest luka sshole OpenSSH?

Na systemach opartych na musl, funkcja crypt() biblioteki C zwraca pojedynczą gwiazdę (*) , gdy nie udaje się zaszyfrować hasła, na przykład gdy hasło jest dłuższe niż jego limit 256-bajtowy. Wiele systemów Linux również używa pojedynczej * w polu hasła, aby oznaczyć "to konto nie ma hasła." OpenSSH porównał dwa, zobaczył *, i potraktował to jako dopasowanie. Wysłanie nadmiernie dużego hasła wystarczyło, aby zalogować się do konta bez hasła.

Zachowanie sięga do zmiany z 2016 w obsłudze hasła OpenSSH. Badacz bezpieczeństwa Özgün Kültekin znalazł to przy użyciu agentów AI, którzy wykonali około 17 600 testów uwierzytelniania. CVE niesie ze sobą wynik CVSS 3.1 w wysokości 8.1, który jest oceniany jako Wysoki, a fix został dostarczony w OpenSSH 10.6p2.

Czy jestem dotknięty?

Serwer jest zagrożony, gdy wszystkie poniższe warunki są prawdziwe:

Uruchamia OpenSSH starsze niż 10.6p2 na systemie opartym na musl, takim jak Alpine Linux, OpenWrt, Buildroot lub Yocto.
sshd nie korzysta z PAM. Jest to ustawienie domyślne dla pakietu openssh-server Alpine.
Logowanie hasłem SSH jest włączone, co jest domyślnym ustawieniem OpenSSH.
Przynajmniej jedno konto ma tylko * w polu hasła, takie jak użytkownik tylko z kluczem, obok innego konta z rzeczywistym skrótowaniem hasła.

Obrazy chmurowe Alpine'a oficjalne AWS i Azure od 3.18.11 do 3.24.3 stanowią poważny przypadek: zawierają domyślnego użytkownika alpine bez hasła i bezhasłowe doas, co oznacza, że udane zalogowanie może stać się rootem.

Nie dotyczy: systemy oparte na glibc, takie jak Debian, Ubuntu i Fedora, konfiguracje sprawdzające hasła za pomocą PAM, Dropbear i OpenBSD. Konta z rzeczywistym skrótem hasła nie mogą być ominięte w ten sposób.

Jak sprawdzić swoje serwery

Uruchom te jako root na każdym serwerze Alpine lub kontenerze, który uruchamia sshd:

Sprawdź ustawienia SSH: sshd -T | grep -i -E 'passwordauthentication|usepam'. Jeśli uwierzytelnianie hasłem jest wyłączone lub PAM jest włączone, ta luka nie może być wykorzystana.
Sprawdź zainstalowany pakiet: apk list --installed | grep openssh, i porównaj to z poprawionymi wersjami poniżej.
Lista kont bez hasła: awk -F: '$2=="*" {print $1}' /etc/shadow.
Sprawdź loginy do tych kont: grep "Accepted password" /var/log/messages. Logowanie hasłowe do konta z * w polu hasła oznacza, że serwer prawdopodobnie został zaatakowany.

Jak naprawić CVE-2026-123158 na Alpine Linux

Alpine dostarczył poprawione pakiety dla każdej gałęzi od 3.16 do edge w dniu ujawnienia. Zaktualizuj i uruchom ponownie sshd, ponieważ instalacja aktualizacji nie uruchamia ponownie procesu:

apk upgrade -U -a i wtedy rc-service sshd restart

Gałąź Alpine	Naprawiona wersja openssh
brzeg	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Dla Docker, przebuduj każdy obraz zawierający openssh z świeżego obrazu bazowego i redeploy go. Zwróć uwagę, że niektóre obrazy SSH na Docker Hub, takie jak linuxserver's openssh-server, wyłączają logowanie hasłem domyślnie, ale stają się narażone, gdy ustawisz PASSWORD_ACCESS=true.

Wydania Alpine starsze niż 3.16 nie otrzymują poprawionego pakietu. Zaktualizuj je do obsługiwanej wersji lub skorzystaj z obejścia poniżej.

Quick workaround: wyłącz logowanie hasłem SSH

Jeśli nie możesz zaktualizować od razu, ustaw PasswordAuthentication no w /etc/ssh/sshd_config, zrestartuj sshd i uruchom ponownie sprawdzenie sshd -T. Upewnij się, że logowanie za pomocą klucza SSH działa przed wykonaniem tego kroku, w przeciwnym razie możesz zablokować sobie dostęp. Tylko klucz SSH jest dobrą wartością domyślną dla każdego serwera.

Co zrobić, jeśli myślisz, że zostałeś trafiony

Przejrzyj użycie doas, nowo utworzonych użytkowników i każdy plik authorized_keys.
Sprawdź nieznane procesy, zadania cron i połączenia wychodzące.
Jeśli nie możesz wykluczyć kompromitacji, traktuj serwer jako zagrożony: przebuduj go z czystego obrazu i zmień każde hasło, klucz i token, które posiadał.
Nie pobieraj exploitów proof-of-concept z GitHub, aby testować swoje serwery. Badacze ostrzegają, że niektóre nie są zweryfikowane i mogą zawierać malware.

Utrzymywanie serwerów patched jest dużym elementem utrzymanie strony internetowej Robię to dla klientów. Jeśli chcesz pomocy w sprawdzaniu Twojego hostingu, konfiguracji Docker lub SSH, skontaktuj się.

Często zadawane pytania

Czy Ubuntu lub Debian są zagrożone przez sshole?

Nie. Systemy oparte na glibc, takie jak Debian, Ubuntu, Fedora i inne, nie są zagrożone, podobnie jak konfiguracje korzystające z PAM do sprawdzania haseł.

Czy SSH tylko z kluczem chroni mnie?

Tak. Gdy PasswordAuthentication jest ustawione na no, serwer nie akceptuje haseł, więc luka nie może być wykorzystana.

Czy CVE-2026-123158 jest wykorzystywany?

Tak. Firma wywiadowcza Previdian zobaczyła pierwszą próbę mniej niż dziewięć godzin po opublikowaniu CVE, a atakujący uzyskał dostęp do roota na jednym ze swoich honeypotów działających na Alpine Linux.

Jaka wersja OpenSSH to naprawia?

OpenSSH 10.6p2. Na Alpine zainstaluj poprawiony pakiet openssh dla swojej gałęzi i ponownie uruchom sshd.

Czy kontenery Docker są zagrożone?

Kontenery oparte na Alpine, które uruchamiają sshd z włączonymi logowaniami za pomocą hasła, mogą być zagrożone. Przebuduj je z zaktualizowanego obrazu podstawowego i redeploy.

Czy muszę ponownie uruchomić po aktualizacji?

Tak. Uruchomiony sshd zachowuje wrażliwy kod w pamięci do momentu ponownego uruchomienia usługi.