Kritisk sårbarhet i OpenSSH och musl låter angripare in på Alpine Linux

En allvarlig säkerhetsbrist i kombinationen av OpenSSH och biblioteket musl libc gör det möjligt för angripare att kringgå autentisering på Linux-system, särskilt Alpine Linux. Genom att ange ett godtyckligt lösenord som är längre än 256 tecken kan en attackerare logga in på konton som normalt är låsta eller saknar lösenord 1.

Vad som hände

Sårbarheten, identifierad med numret CVE-2026-123158 och döpt till "sshole" av upptäckaren Özgün Kültekin, drabbar system som använder musl libc (till exempel Alpine Linux, OpenWRT, Buildroot) och kör OpenSSH utan PAM-stöd. Problemet uppstår när en angripare försöker logga in på ett konto där lösenordsfältet i /etc/shadow innehåller ett asterisktecken (*). Detta tecken används vanligtvis för att markera konton som inte ska ha lösenordsåtkomst.

Enligt tekniska detaljer returnerar musl libc:s crypt()-funktion strängen "" vid misslyckad hashning, vilket inkluderar fall då inmatat lösenord överstiger 256 byte. OpenSSH använder sedan detta felaktiga resultat för att jämföra med det lagrade värdet i /etc/shadow. Eftersom båda värdena blir "", godkänns inloggningen. För att utnyttja luckan krävs ett lösenord mellan 257 och 1024 tecken Research.

Upptäckaren rapporterar att han använde AI-agenter för att testa cirka 17 600 autentiseringsförsök över olika konfigurationer innan sårbarheten bekräftades. Både OpenSSH-projektet och musl-författaren Rich Felker har publicerat varningar och åtgärder, även om parterna initialt pekade på varandra som orsaken till felet 1.

Påverkan och åtgärder

Alpine Linux är den drabbade distribution som väcker störst oro, då den är standardval i många Docker-containrar, Kubernetes-kluster och virtuella maskiner. Alpine har levererat akuta uppdateringar till alla stödda grenar, inklusive äldre versioner från 3.16 och uppåt, via paketet openssh version 10.6p2 eller senare Research.

För administratörer som inte omedelbart kan patcha systemen rekommenderas att inaktivera lösenordsautentiseringen genom att sätta PasswordAuthentication no i OpenSSH-konfigurationsfilen (sshd_config) och starta om tjänsten. System som använder glibc istället för musl, eller där PAM är aktiverat (UsePAM yes), påverkas inte av denna specifika sårbarhet Research.

analys: vad det betyder för infrastrukturen

Att sårbarheten kräver att lösenordsautentisering är aktiverad minskar risken för exponerade internet-tjänster där nyckelbaserad autentisering är standard. Däremot utgör den en betydande risk i interna nätverk, molnmiljöer och VPN:er där angripare redan har delvis åtkomst eller kan exploatera andra vägar till systemen. En angripare med en giltig användaridentitet kan snabbt eskalera sina rättigheter till root-nivå på drabbade Alpine-system, särskilt om standardkontot alpine finns tillgängligt utan lösenord men med doas-privilegier Research.

Det är viktigt att notera att detta inte är ett problem med själva lösenordsstyrkan eller krypteringen i sig, utan ett implementeringsfel i hur felhantering och jämförelse av hashvärden sker mellan två komponenter. Genom att uppdatera till OpenSSH 10.6p2 eller senare elimineras risken för denna specifika attackvektor.