sshole (CVE-2026-123158): Het OpenSSH-fout die Alpine Linux treft en hoe je deze kunt oplossen

Door Eoin Villarin, 2026-11-07

- Een OpenSSH-fout genaamd sshole stelt aanvallers in staat om in te loggen op wachtwoordloze accounts op Alpine Linux en andere op musl gebaseerde systemen, en het wordt al misbruikt. Wie wordt getroffen, hoe je je servers kunt controleren en hoe je het kunt oplossen.

Een nieuw ontdekte OpenSSH-fout genaamd sshole, getraceerd als CVE-2026-123158, laat aanvallers toe om in te loggen op bepaalde Linux-accounts die niet zijn bedoeld om wachtwoorden te accepteren. Het beïnvloedt OpenSSH op musl-gebaseerde systemen zoals Alpine Linux, het werd op 5 november 2026 opgelost, en aanvallers begonnen het te gebruiken binnen minder dan negen uur nadat het werd gepubliceerd. Als je Alpine-servers, Alpine-gebaseerde Docker-images met SSH, of kleine apparaten op OpenWrt uitvoert, controleer ze dan vandaag.

Wat is de sshole OpenSSH-fout?

Op musl-gebaseerde systemen retourneert de C-bibliotheekfunctie crypt() een enkele asterisk (*) wanneer het niet lukt om een wachtwoord te hashen, bijvoorbeeld wanneer het wachtwoord langer is dan de 256-byte limiet. Veel Linux-systemen gebruiken ook een enkele * in het wachtwoordveld om aan te geven "dit account heeft geen wachtwoord." OpenSSH vergeleek de twee, zag *, en behandelde het als een overeenkomst. Het sturen van een te groot wachtwoord was voldoende om in te loggen op een account zonder wachtwoord.

Het gedrag gaat terug tot een wijziging in 2016 in de wachtwoordafhandeling van OpenSSH. Onderzoeker Özgün Kültekin vond het met AI-agenten die ongeveer 17.600 authenticatietests uitvoerden. De CVE heeft een CVSS 3.1-score van 8.1, die als hoog wordt beoordeeld, en de fix werd geleverd in OpenSSH 10.6p2.

Ben ik beïnvloed?

Een server loopt risico als al het volgende waar is:

• Het draait OpenSSH ouder dan 10.6p2 op een musl-gebaseerd systeem, zoals Alpine Linux, OpenWrt, Buildroot of Yocto.
• sshd gebruikt geen PAM. Dit is de standaardinstelling voor Alpine's openssh-server package.
• SSH-wachtwoordlogins zijn ingeschakeld, wat de OpenSSH-default is.
• Ten minste één account heeft alleen * in zijn wachtwoordveld, zoals een gebruiker met alleen een sleutel, naast een ander account met een echte wachtwoordhash.

De officiële AWS- en Azure-cloudimages van Alpine van 3.18.11 tot 3.24.3 zijn een ernstig geval: ze bevatten een standaard alpine-gebruiker zonder wachtwoord en wachtwoordloos doas, wat betekent dat een succesvolle inlog kan leiden tot root.

Niet beïnvloed: glibc-gebaseerde systemen zoals Debian, Ubuntu en Fedora, setups die wachtwoorden controleren via PAM, Dropbear en OpenBSD. Accounts met een echte wachtwoordhash kunnen op deze manier niet worden omzeild.

Hoe je servers te controleren

Voer deze uit als root op elke Alpine-server of container die sshd uitvoert:

1. Controleer de SSH-instellingen: sshd -T | grep -i -E 'passwordauthentication|usepam'. Als wachtwoordverificatie is uitgeschakeld of PAM is ingeschakeld, kan deze fout niet worden gebruikt.
2. Controleer het geïnstalleerde pakket: apk list --installed | grep openssh, en vergelijk het met de vaste versies hieronder.
3. List accounts zonder wachtwoord: awk -F: '$2=="*" {print $1}' /etc/shadow.
4. Zoek naar logins naar die accounts: grep "Accepted password" /var/log/messages. Een inloggen met een wachtwoord met * in het wachtwoordveld betekent dat de server waarschijnlijk is aangevallen.

Hoe CVE-2026-123158 op Alpine Linux te repareren

Alpine heeft gepatchte pakketten geleverd voor elke branch van 3.16 tot edge op dezelfde dag als de bekendmaking. Update en herstart sshd, omdat het installeren van de update het lopende proces niet herstart:

apk upgrade -U -a en daarna rc-service sshd restart

Voor Docker, bouw elk image dat openssh bevat opnieuw vanuit een schoon basisimage en implementeer het opnieuw. Merk op dat sommige SSH-images op Docker Hub, zoals linuxserver's openssh-server, wachtwoordlogins standaard uitschakelen maar worden blootgesteld wanneer PASSWORD_ACCESS=true wordt ingesteld.

Alpine-releases ouder dan 3.16 krijgen geen vast pakket. Upgrade ze naar een ondersteunde release, of gebruik de workaround hieronder.

Snel werk rond: schakel SSH-wachtwoordlogins uit

Als je niet meteen kunt updaten, zet dan PasswordAuthentication no in /etc/ssh/sshd_config, herstart sshd en voer de sshd -T check opnieuw uit. Zorg ervoor dat je SSH-sleutel login werkt voordat je dit doet, anders kun je jezelf buitensluiten. Sleutel-only SSH is sowieso een goede standaard voor elke server.

Wat te doen als je denkt dat je bent getroffen

• Beoordeel doas-gebruik, recentelijk gemaakte gebruikers en elk authorized_keys-bestand.
• Controleer op onbekende processen, cron-taken en uitgaande verbindingen.
• Als je een compromis niet kunt uitsluiten, behandel de server dan als gecompromitteerd: bouw het opnieuw op vanuit een schoon image en roteer elk wachtwoord, sleutel en token dat het hield.
• Download geen proof-of-concept-exploits van GitHub om je servers te testen. Onderzoekers waarschuwen dat sommige niet zijn geverifieerd en malware kunnen bevatten.

Servers up-to-date houden is een groot deel van de website onderhoud Ik doe dit voor klanten. Als je hulp nodig hebt bij het controleren van je hosting, Docker-installatie of SSH-configuratie, Neem contact op.

Veelgestelde vragen

Wordt Ubuntu of Debian getroffen door sshole?

Nee. Debian, Ubuntu, Fedora en andere op glibc gebaseerde systemen zijn niet getroffen, evenals configuraties die PAM gebruiken voor wachtwoordcontroles.

Biedt SSH-sleutel-only mij bescherming?

Ja. Met PasswordAuthentication ingesteld op nee, accepteert de server geen wachtwoorden, dus kan de fout niet worden gebruikt.

Wordt CVE-2026-123158 misbruikt?

Ja. Threat intelligence-firma Previdian zag de eerste poging minder dan negen uur nadat de CVE werd gepubliceerd, en een aanvaller kreeg root op een van zijn honeypots die Alpine Linux uitvoerden.

Welke OpenSSH-versie lost het op?

OpenSSH 10.6p2. Installeer op Alpine het gepatchte openssh-pakket voor je branch en start sshd opnieuw.

Zijn Docker-containers getroffen?

Containers op basis van Alpine die sshd uitvoeren met ingeschakelde wachtwoordaanmeldingen kunnen worden getroffen. Bouw ze opnieuw vanuit een bijgewerkt basisbeeld en implementeer opnieuw.

Moet ik opnieuw opstarten na het bijwerken?

Ja. De lopende sshd houdt de kwetsbare code in het geheugen totdat je de service opnieuw start.

Bronnen

• BleepingComputer: OpenSSH-fout laat aanvallers inloggen op Linux-accounts zonder wachtwoord
• Help Net Security: OpenSSH-fout misbruikt in het wild binnen enkele uren na openbaarmaking
• Cycode: sshole OpenSSH-wachtwoordbypass op Alpine Linux
• Orca Security: sshole authenticatiebypass op Alpine Linux