sshole (CVE-2026-123158): OpenSSH-bristen som påverkar Alpine Linux och hur du åtgärdar den

Av Eoin Villarin, 2026-11-07

- En OpenSSH-brist som kallas sshole låter angripare logga in på lösenordsfria konton på Alpine Linux och andra musl-baserade system, och den utnyttjas redan. Vem påverkas, hur du kontrollerar dina servrar och hur du åtgärdar det.

Är jag påverkat av sshole OpenSSH-bristen?

Du är i riskzonen om en server kör OpenSSH äldre än 10.6p2 på ett musl-baserat system som Alpine Linux utan PAM, tillåter SSH-lösenordsinloggningar och har ett konto vars lösenordsfält är endast ett asterisk bredvid ett annat konto med en riktig lösenordshash. Debian, Ubuntu, Fedora och installationer som använder PAM påverkas inte.

Viktiga takeaways

CVE-2026-123158, kallad sshole, låter angripare logga in på lösenordsfria konton på musl-baserade Linux genom att skicka ett för stort lösenord.
Alpine Linuxs standard openssh-server-paket är påverkat, medan glibc-system som Ubuntu och installationer som använder PAM inte är det.
Angripare utnyttjade det mindre än nio timmar efter att det publicerades och fick root på en honeypot.
Fixen är OpenSSH 10.6p2 eller Alpines patchade paket för din gren, följt av en omstart av sshd.
Om du ännu inte kan uppdatera, sätt PasswordAuthentication till no och använd SSH-nycklar.

En nyligen avslöjad OpenSSH-brist kallad sshole, spårad som CVE-2026-123158, låter angripare logga in på vissa Linux-konton som inte är tänkt att acceptera lösenord alls. Den påverkar OpenSSH på musl-baserade system som Alpine Linux, den fixades den 5 november 2026, och angripare började använda den mindre än nio timmar efter att den publicerades. Om du kör Alpine-servrar, Alpine-baserade Docker-bilder med SSH, eller små enheter på OpenWrt, kontrollera dem idag.

Vad är sshole‑bristen i OpenSSH?

På musl-baserade system returnerar C-bibliotekets crypt()‑funktion en ensam asterisk (*) när den misslyckas med att hasha ett lösenord, till exempel när lösenordet är längre än dess 256‑bytes gräns. Många Linux‑system använder också en ensam * i lösenordsfältet för att betyda "detta konto har inget lösenord." OpenSSH jämförde de två, såg *, och behandlade det som en match. Att skicka ett överdimensionerat lösenord var tillräckligt för att logga in på ett konto utan lösenord.

Beteendet går tillbaka till en ändring 2016 i OpenSSH:s lösenordshantering. Säkerhetsforskaren Özgün Kültekin fann det med AI‑agenter som körde cirka 17 600 autentiseringstester. CVE har en CVSS 3.1‑poäng på 8.1, vilket klassas som Hög, och fixen levererades i OpenSSH 10.6p2.

Är jag påverkat?

En server är i riskzonen när allt följande är sant:

Den kör en äldre OpenSSH än 10.6p2 på ett musl-baserat system, såsom Alpine Linux, OpenWrt, Buildroot eller Yocto.
sshd använder inte PAM. Detta är standard för Alpines openssh-server-paket.
SSH-lösenordsinloggning är aktiverad, vilket är OpenSSH‑standard.
Minst ett konto har bara * i sitt lösenordsfält, till exempel en nyckel-användare, bredvid ett annat konto med en riktig lösenordshash.

Alpines officiella AWS- och Azure-molnimages från 3.18.11 till 3.24.3 är ett allvarligt fall: de inkluderar en standardanvändare alpine med inget lösenord och lösenordsfritt doas, vilket betyder att ett lyckat inlogg kan bli root.

Ej påverkade: glibc-baserade system som Debian, Ubuntu och Fedora, installationer som kontrollerar lösenord via PAM, Dropbear och OpenBSD. Konton med en riktig lösenordshash kan inte kringgås på detta sätt.

Hur du kontrollerar dina servrar

Kör dessa som root på varje Alpine‑server eller container som kör sshd:

Kontrollera SSH-inställningarna: sshd -T | grep -i -E 'passwordauthentication|usepam'. Om lösenordsautentisering är av eller PAM är på, kan denna brist inte användas.
Kontrollera det installerade paketet: apk list --installed | grep openssh, och jämför det med de fasta versionerna nedan.
Lista konton utan lösenord: awk -F: '$2=="*" {print $1}' /etc/shadow.
Sök efter inloggningar till dessa konton: grep "Accepted password" /var/log/messages. Ett lösenordsinlogg till ett konto med * i dess lösenordsfält betyder att servern troligen attackerades.

Hur du åtgärdar CVE-2026-123158 på Alpine Linux

Alpine skickade lappade paket för varje gren från 3.16 till edge på samma dag som avslöjandet. Uppdatera och starta om sshd, eftersom installation av uppdateringen inte startar om den körande processen:

apk upgrade -U -a och sedan rc-service sshd restart

Alpine gren	Fixad OpenSSH-version
kant	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

För Docker, bygg om varje bild som innehåller OpenSSH från en färsk basbild och distribuera den igen. Observera att vissa SSH-bilder på Docker Hub, såsom linuxserver's openssh-server, har lösenordsinloggning avstängd som standard men blir exponerade när PASSWORD_ACCESS=true sätts.

Alpine-utgåvor äldre än 3.16 får inget fixat paket. Uppgradera dem till en understödd utgåva, eller använd det tillfälliga lösningen nedan.

Snabb lösning: stäng av SSH-lösenordsinloggning

Om du inte kan uppdatera omedelbart, ställ in PasswordAuthentication no i /etc/ssh/sshd_config, starta om sshd och kör sshd -T-kontrollen igen. Se till att din SSH-nyckel-inloggning fungerar innan du gör detta, annars kan du låsa dig själv ute. Endast SSH-nyckel är en bra standard för alla servrar i alla fall.

Vad du ska göra om du tror att du blev drabbat

Granska doas‑användning, nyligen skapade användare och varje authorized_keys‑fil.
Kontrollera efter okända processer, cron-jobb och utgående anslutningar.
Om du inte kan utesluta en kompromiss, behandla servern som komprometterad: bygg om den från en ren bild och rotera varje lösenord, nyckel och token den hade.
Ladda inte ner proof-of-concept-exploits från GitHub för att testa dina servrar. Forskare varnar för att vissa är overifierade och kan innehålla skadlig kod.

Att hålla servrar uppdaterade är en stor del av webbsidans underhåll Jag gör det för kunder. Om du vill ha hjälp med att kontrollera din hosting, Docker-setup eller SSH-konfiguration, ta kontakt.

Vanliga frågor

Är Ubuntu eller Debian påverkade av sshole?

Nej. Debian, Ubuntu, Fedora och andra glibc-baserade system påverkas inte, liksom inte heller installationer som använder PAM för lösenords kontroller.

Skyddar nyckelbaserad SSH mig?

Ja. Med PasswordAuthentication satt till nej, accepterar servern inte lösenord, så bristen kan inte utnyttjas.

Utnyttjas CVE-2026-123158?

Ja. Säkerhetsintelligensföretaget Previdian såg det första försöket mindre än nio timmar efter att CVE publicerades, och en angripare fick root på en av dess honeypots som körde Alpine Linux.

Vilken OpenSSH-version åtgärdar det?

OpenSSH 10.6p2. På Alpine, installera det lappade openssh-paketet för din gren och starta om sshd.

Är Docker-containrar påverkade?

Containrar baserade på Alpine som kör sshd med aktiverade lösenordsinloggningar kan påverkas. Bygg om dem från en uppdaterad basbild och distribuera om.

Behöver jag starta om efter uppdatering?

Ja. Den körande sshd behåller den sårbara koden i minnet tills du startar om tjänsten.