sshole (CVE-2026-123158): OpenSSH-sikkerhetsflauen som rammer Alpine Linux og hvordan fikse den

Av Eoin Villarin, 2026-11-07

- En OpenSSH-sårbarhet kalt sshole lar angripere logge inn på passordløse kontoer på Alpine Linux og andre musl-baserte systemer, og den blir allerede utnyttet. Hvem er berørt, hvordan du sjekker serverne dine og hvordan du fikser det.

Er jeg påvirket av sshole OpenSSH-feilen?

Du er i risiko hvis en server kjører OpenSSH eldre enn 10.6p2 på et musl-basert system som Alpine Linux uten PAM, tillater SSH-passordinnlogging og har en konto hvis passordfelt bare er et asterisk neste til en annen konto med en reell passordhash. Debian, Ubuntu, Fedora og oppsett som bruker PAM er ikke berørt.

Viktige hovedpunkter

  • CVE-2026-123158, kalt sshole, lar angripere logge inn på passordløse kontoer på musl-baserte Linux ved å sende et oversized passord.
  • Alpine Linuxs standard openssh-server-pakke er påvirket, mens glibc-systemer som Ubuntu og oppsett som bruker PAM ikke er det.
  • Angripere utnyttet det mindre enn ni timer etter at det ble publisert og fikk root på en honeypot.
  • Fixen er OpenSSH 10.6p2 eller Alpinens oppdaterte pakke for din gren, etterfulgt av en omstart av sshd.
  • Hvis du foreløpig ikke kan oppdatere, sett PasswordAuthentication til no og bruk SSH‑nøkler.

En nylig avslørt OpenSSH-feil kalt sshole, sporet som CVE-2026-123158, lar angripere logge inn på visse Linux-kontoer som ikke skal godta passord i det hele tatt. Den påvirker OpenSSH på musl-baserte systemer som Alpine Linux, den ble fikset den 5. november 2026, og angripere begynte å bruke den mindre enn ni timer etter at den ble publisert. Hvis du kjører Alpine-servere, Alpine-baserte Docker-bilder med SSH, eller små enheter på OpenWrt, sjekk dem i dag.

Hva er sshole‑sårbarheten i OpenSSH?

På musl‑baserte systemer returnerer C‑bibliotekets crypt()‑funksjon en enkelt stjerne (*) når den feiler i å hashe et passord, for eksempel når passordet er lengre enn grensen på 256 byte. Mange Linux‑systemer bruker også en enkelt * i passordfeltet for å bety «denne kontoen har ingen passord». OpenSSH sammenlignet de to, så * og behandlet det som et treff. Å sende et overdimensjonert passord var nok til å logge inn på en konto uten passord.

Oppførselen stammer fra en endring i OpenSSHs passordhåndtering i 2016. Sikkerhetsforsker Özgün Kültekin oppdaget den ved hjelp av AI‑agenter som utførte omkring 17 600 autentiseringstester. CVE‑en har en CVSS 3.1‑score på 8,1, som klassifiseres som høy, og fixen ble levert i OpenSSH 10.6p2.

Er jeg påvirket?

En server er i fare når alle disse er sanne:

  • Den kjører en eldre OpenSSH enn 10.6p2 på et musl‑basert system, som Alpine Linux, OpenWrt, Buildroot eller Yocto.
  • sshd bruker ikke PAM. Dette er standarden for Alpinens openssh-server-pakke.
  • SSH‑passordinlogging er aktivert, som er standard for OpenSSH.
  • Minst en konto har bare * i passordfeltet, slik som en nøkkel-only-bruker, neste til en annen konto med en ekte passordhash.

Alpines offisielle AWS- og Azure-skybilder fra 3.18.11 til 3.24.3 er et alvorlig tilfelle: de inkluderer en standard alpine-bruker uten passord og passordløs doas, noe som betyr at en vellykket innlogging kan bli root.

Ikke påvirket: glibc-baserte systemer som Debian, Ubuntu og Fedora, oppsett som sjekker passord gjennom PAM, Dropbear og OpenBSD. Kontoer med en ekte passordhash kan ikke omgås på denne måten.

Hvordan sjekke serverne dine

Kjør disse som root på hver Alpine‑server eller -container som kjører sshd:

  1. Sjekk SSH-innstillingene: sshd -T | grep -i -E 'passwordauthentication|usepam'. Hvis passordautentisering er av eller PAM er på, kan denne feilen ikke brukes.
  2. Sjekk den installerte pakken: apk list --installed | grep openssh, og sammenlign det med de faste versjonene nedenfor.
  3. List opp kontoer uten passord: awk -F: '$2=="*" {print $1}' /etc/shadow.
  4. Se etter pålogginger til disse kontoene: grep "Accepted password" /var/log/messages. Et passordlogg inn på en konto med * i passordfeltet betyr at serveren sannsynligvis ble angrepet.

Hvordan fikse CVE‑2026‑123158 på Alpine Linux

Alpine leverte oppdaterte pakker for hver gren fra 3.16 til edge på samme dag som avsløringen. Oppdater og restart sshd, fordi installasjon av oppdateringen ikke restart prosessen:

apk upgrade -U -a og så rc-service sshd restart

Alpine grenFikset OpenSSH‑versjon
kant10.6_p2-r0
3.2410.3_p1-r2
3.2310.2_p1-r1
3.2210.0_p1-r11
3.219.9_p2-r1
3.209.7_p1-r6
3.199.6_p1-r3
3.189.3_p2-r4
3.179.1_p1-r7
3.169.0_p1-r6

For Docker, bygg alle bilder som inneholder OpenSSH på nytt fra et rent basisbilde og distribuer dem på nytt. Merk at noen SSH‑bilder på Docker Hub, som linuxserver‑s openssh‑server, har passordinlogging deaktivert som standard, men blir eksponert når PASSWORD_ACCESS=true er satt.

Alpine-utgivelser eldre enn 3.16 får ingen fast pakke. Oppgrader dem til en støttet utgave, eller bruk løsningen nedenfor.

Rask løsning: slå av SSH‑passordinlogging

Hvis du ikke kan oppdatere umiddelbart, sett PasswordAuthentication no i /etc/ssh/sshd_config, restart sshd og kjøre sshd -T-sjekken igjen. Sørg for at SSH-nøkkelinnlogging fungerer før du gjør dette, ellers kan du låse deg selv ute. Bare-nøkkel SSH er et godt standard for enhver server uansett.

Hva du bør gjøre hvis du tror du ble rammet

  • Gå gjennom bruk av doas, nylig opprettede brukere og hver authorized_keys‑fil.
  • Sjekk for ukjente prosesser, cron-jobber og utgående forbindelser.
  • Hvis du ikke kan utelukke at den er kompromittert, behandle serveren som kompromittert: bygg den på nytt fra et rent bilde og roter alle passord, nøkler og token den hadde.
  • Last ikke ned proof‑of‑concept‑utnyttelser fra GitHub for å teste serverne dine. Forskere advarer om at noen er uverifiserte og kan inneholde skadelig programvare.

Å holde servere oppdatert er en viktig del av vedlikehold av nettside Jeg gjør det for kunder. Hvis du ønsker hjelp til å sjekke hosting, Docker‑oppsett eller SSH‑konfigurasjon, ta kontakt.

Ofte stilte spørsmål

Er Ubuntu eller Debian berørt av sshole?

Nei. Debian, Ubuntu, Fedora og andre glibc-baserte systemer er ikke berørt, og heller ikke oppsett som bruker PAM for passordkontroller.

Beskytter nøkkel-only SSH meg?

Ja. Med PasswordAuthentication satt til nei, godtar ikke serveren passord, så sårbarheten kan ikke brukes.

Blir CVE-2026-123158 utnyttet?

Ja. Trusselintelligensfirmaet Previdian så det første forsøket mindre enn ni timer etter CVE var publisert, og en angriper fikk root på en av dens honeypots som kjørte Alpine Linux.

Hvilken OpenSSH-versjon fikser det?

OpenSSH 10.6p2. På Alpine, installer den oppdaterte openssh-pakken for din gren og start sshd på nytt.

Er Docker-kontainer berørt?

Kontainer basert på Alpine som kjører sshd med passordinnlogging aktivert kan være berørt. Bygg dem om fra et oppdatert basisbilde og redeploy.

Må jeg starte på nytt etter å ha oppdatert?

Ja. Den kjørende sshd beholder den sårbare koden i minnet til du starter tjenesten på nytt.

Sources

Relatert lesning