Er duikt een nieuwe poging tot accounttoegang op die is gebouwd rond een specifieke fout in OpenSSH. De SSHole-bypass in OpenSSH (CVE-2026-123158) is onlangs gepatcht, maar inmiddels rapporteren meerdere partijen dat aanvallers de kwetsbaarheid in het wild proberen te benutten. Voor beheerders is het belangrijkste: voorkom dat wachtwoordauthentificatie onbedoeld kan slagen, en werk OpenSSH zo snel mogelijk bij.
In dit artikel leggen we uit wat er misgaat, welke Linux-omgevingen extra aandacht verdienen en welke acties u vandaag al kunt nemen om de kans op ongeautoriseerde toegang te verkleinen.
Wat is de SSHole-bypass in OpenSSH?
De kwetsbaarheid is geregistreerd als CVE-2026-123158. De kern zit in een probleem met hoe sshd interpreteert of een string bedoeld is als wachtwoordhash. Daardoor kan het gebeuren dat sshd bepaalde wachtwoorden als correct behandelt, ook al zijn ze niet overeenkomend met de opgeslagen hash.
Concreet wordt toegang mogelijk wanneer een aanvaller een willekeurig wachtwoord aanlevert met een lengte tussen 257 en 1024 tekens. Als de exploit slaagt, kan de aanvaller inloggen op accounts die normaal gesproken geen wachtwoord zouden moeten accepteren.
Waarom kan dit zelfs “root” raken?
Een bijzonder risico zit in Linux-distributies waar de configuratie afwijkt van wat u wellicht verwacht. Op sommige systemen accepteert een account dat “slechts” als sleutelgebaseerd zou moeten werken toch een wachtwoord. Dat geldt onder meer voor distributies die gebruikmaken van musl libc met PAM uitgeschakeld, zoals Alpine, Buildroot, OpenWrt, Yocto en andere varianten.
De logica die sshd volgt is in grote lijnen als volgt: sshd controleert het aangeleverde wachtwoord door het te hashen en dat resultaat te vergelijken met de opgeslagen wachtwoordhash die hoort bij de gebruikersnaam. Als er voor een account geen wachtwoordhash is (bijvoorbeeld root op Alpine, waar die veldwaarde ‘*’ is), dan leent sshd een “salt” van een andere accounthash om toch een berekening uit te voeren.
Bij wachtwoorden langer dan 256 bytes loopt musl’s crypt() tegen een fout aan. In plaats van NULL terug te geven, retourneert de functie een waarde die de drempel overschrijdt en in de praktijk als ‘*’ uitkomt. Omdat die waarde overeenkomt met ‘*’ in het targetaccount, kan sshd het ingevoerde wachtwoord onterecht als correct behandelen.
Welke systemen lopen extra risico?
De melding is niet “alle Linux” in één keer, maar vooral omgevingen met de combinatie van voorwaarden. Let in elk geval op de volgende context:
- musl libc als C-bibliotheek
- PAM (Pluggable Authentication Modules) uitgeschakeld
- Accounts waarbij root-achtige gebruikers hun wachtwoordhash niet hebben (zoals ‘*’)
In de praktijk worden daarbij o.a. accounts genoemd zoals root, key-only gebruikers die zijn aangemaakt zonder wachtwoord (bijvoorbeeld via adduser), en gebruikers die terugkomen uit directory-achtige integraties die musl-nscd gebruiken.
Is uw omgeving gebaseerd op Alpine, OpenWrt of een vergelijkbare set-up? Dan is het verstandig om de patchstatus van OpenSSH direct te controleren.
Misbruik in het wild: wat zeggen waarnemers?
OpenSSH patches zijn inmiddels gehaast doorgevoerd, en leveranciers hebben gebruikers aangespoord om snel te updaten. Tegelijkertijd waarschuwen partijen dat aanvallers de techniek al toepassen.
WatchTowr en Previdian meldden dat de exploitpogingen al zichtbaar zijn. Volgens WatchTowr zijn tot op dat moment met name botnetten en crypto miners opgepikt die het proberen. Previdian rapporteerde onder meer het aantal waargenomen pogingen, unieke aanvaller-IP’s en geografische spreiding.
Ook andere onderzoeksplatformen hebben pogingen gezien. De exacte aantallen wisselen per rapport, maar het patroon is consistent: probeer- en testpogingen voor CVE-2026-123158 zijn inmiddels op gang gekomen.
Wat moet u nu doen? (update en mitigatie)
De meest effectieve maatregel is altijd dezelfde: zorg dat u de gepatchte versie draait. Voor deze kwetsbaarheid wordt geadviseerd om te updaten naar OpenSSH 10.6p2 (of later, als uw distributie dat aanbiedt).
Als u vandaag nog niet volledig kunt upgraden, zijn er daarnaast directe mitigaties die het aanvalsoppervlak verkleinen.
1) Zet wachtwoordauthentificatie uit
Wachtwoordauthentificatie is de route waarlangs de exploit werkt. OpenSSH heeft deze optie, afhankelijk van uw setup, standaard aan. Schakel deze uit door uw SSH-configuratie aan te passen zodat alleen sleutels worden geaccepteerd. Daarmee voorkomt u dat de kwetsbare pad “wachtwoord → verificatie” überhaupt wordt doorlopen.
2) Overweeg SSH tijdelijk uitschakelen
Wanneer uw situatie urgent is (bijvoorbeeld bij exposure naar het internet, of als u nog geen update kunt doorvoeren), kunt u tijdelijk overwegen SSH helemaal uit te zetten. Dit is een zwaardere maatregel, maar het stopt de aanvalsvector direct.
3) Controleer serverlogs op ongebruikelijke pogingen
Zoek in logs naar patronen die passen bij exploitpogingen. Denk aan loginrequests die op een hoog volume of met verdachte wachtwoordlengtes binnenkomen. Door vroegtijdig te detecteren voorkomt u dat een succesvolle poging onopgemerkt blijft.
Tip: combineer logging met een proces voor snelle rollback of herstel. Daarmee blijft uw beveiligingsstap ook operationeel haalbaar.
Gerelateerde risico’s: authentication bypasses elders
SSH is niet de enige plek waar authentication bypasses in de praktijk voor problemen zorgen. In recente berichten zijn ook VPN- en appliance-contexten genoemd waarin patches zijn uitgebracht nadat een zwakte in authenticatie of sessieafhandeling werd gevonden.
Als u wilt vergelijken met andere patterns, lees dan ook Bron: https://www.securityweek.com/hackers-exploiting-sshole-authentication-bypass-in-openssh/
