De dreiging en patchvertraging rond OpenSSH is pijnlijk actueel: volgens waarnemingen uit de threat intelligence-scene werd een recent bekendgemaakte kwetsbaarheid al snel na publicatie geprobeerd te misbruiken. Het gaat om CVE-2026-123158, gecodeerd als SSHole, waarbij aanvallers kunnen inloggen op accounts die bewust zonder bruikbaar wachtwoord zijn ingericht.
In dit artikel zetten we de kern op een rij: hoe SSHole werkt, welke omgevingen extra kwetsbaar zijn, wat er in logs te zien kan zijn en welke concrete stappen je moet nemen om je systemen te beschermen.
Wat is OpenSSH SSHole (CVE-2026-123158)?
SSHole is een OpenSSH-kwetsbaarheid die invloed heeft op bepaalde Linux-systemen met OpenSSH in combinatie met de musl-C library én waarbij PAM is uitgeschakeld. Dat is niet zomaar een detail: het zorgt ervoor dat de kwetsbaarheid onder specifieke configuraties kan leiden tot onbedoelde authenticatie.
De kwetsbaarheid (CVSS-score 8.1) kan een aanvaller toegang geven tot accounts die bedoeld zijn om geen wachtwoordauthenticatie te accepteren. Cruciaal is dat de aanvaller hiervoor geen gestolen wachtwoorden of SSH-sleutels hoeft te hebben.
Hoe kunnen aanvallers inloggen zonder “bruikbaar wachtwoord”?
De kern van het probleem zit in de manier waarop OpenSSH omgaat met mislukte wachtwoord-hashbewerkingen. Onder bepaalde voorwaarden kan OpenSSH een mislukte hashingfase ten onrechte interpreteren als “geluk” door een tekenwaarde te gebruiken die ook wordt toegepast om “wachtwoord uitgeschakeld” aan te duiden.
Volgens de berichtgeving kan een aanvaller een oversized wachtwoord aanleveren (tussen 257 en 1.024 bytes). Daarmee wordt het hashingproces door een systeemfout niet zoals bedoeld afgerond, waarna OpenSSH terugvalt op een waarde die vervolgens overeenkomt met de speciale marker die in de accountdatabase staat voor wachtwoordloze accounts.
- Voor een succesvolle exploit is minstens één account nodig dat daadwerkelijk zo is ingericht dat het passwordveld een asterisk (*) gebruikt als aanduiding.
- Het is geen universele omzeiling: accounts met een normale, geldige wachtwoordhash kunnen niet op deze manier worden “overgeslagen”.
Wanneer de aanval slaagt, krijgt de aanvaller toegang met de bestaande machtigingen van het gecompromitteerde account. Dat kan in praktijk uiteenlopen van beperkte toegang tot echte escalatie, afhankelijk van hoe het account is ingericht.
Wie loopt risico en wie niet?
Niet iedere Linux-distributie of iedere SSH-configuratie is even kwetsbaar. De melding specificeert onder meer deze afbakening:
- Wel kwetsbaar: Linux-systemen die OpenSSH gebruiken met musl en met PAM uitgeschakeld. Ook de standaardconfiguratie van Alpine Linux valt hier (volgens de bron) onder.
- Niet kwetsbaar: Dropbear, omgevingen met glibc-gebaseerde distributies, niet-Linux systemen en systemen die via PAM controleren.
Dat betekent dat je niet alleen “draait er OpenSSH?” moet bekijken, maar juist de combinatie van platform en authenticatiemechanisme.
Snelle aanvallen: waarom de patchvertraging nu telt
De dreiging en patchvertraging zit hier vooral in de timing. Threat intelligence-onderzoekers gaven aan dat de eerste exploitpoging minder dan negen uur na publicatie is gezien. Daarbij werd ook succesvolle roottoegang gerapporteerd op een honeypot met Alpine Linux en OpenSSH.
Verder worden er acht exploitpogingen gelinkt aan één bron-IP, dat geolocatie naar Japan toont. In de berichtgeving staat dat de aanvaller oversized wachtwoorden gebruikte en daarna reconnaissance deed via niet-interactieve SSH-sessies (zoals het uitlezen van identiteit, kernelnaam en hostname).
Voor organisaties is dit een duidelijk signaal: als een kwetsbaarheid snel te misbruiken blijkt, kan zelfs een korte periode zonder update al schade opleveren.
Mogelijke impact: van ongeautoriseerde SSH tot laterale beweging
Direct effect is ongeautoriseerde SSH-toegang. Maar daarmee houdt het niet noodzakelijk op. Als een aanvaller eenmaal binnen is met de rechten van een “password-disabled” account, kan hij mogelijk verder:
- deployment credentials of applicatiegeheimen benaderen;
- toegang krijgen tot verbonden infrastructuur;
- laterale beweging (lateral movement) of verstoring van services mogelijk maken.
Of je impact groot is, hangt samen met de rol van het gecompromitteerde account: hoe krachtig zijn permissies, en of er secrets of beheerresources aan zijn gekoppeld.
Wat moet je nu doen? (praktische checklist)
De bron geeft een relatief simpele kernmaatregel: update en herstart. Maar maak het concreet met onderstaande stappen.
1) Update OpenSSH naar de gepatchte versie
OpenSSH heeft een fix doorgevoerd in OpenSSH 10.6p2. Installeer die versie of het overeenkomstige gepatchte pakket van je distributie. Daarna is een herstart van sshd nodig zodat de nieuwe code actief wordt.
2) Controleer logregels die op SSHole kunnen wijzen
Voor Alpine wordt geadviseerd specifiek te letten op entries rond “Accepted password for” bij accounts die eigenlijk geen wachtwoord zouden moeten accepteren. Richt je op sshd-regels die aangeven dat er een password-login is toegestaan terwijl het account bedoeld was als key-only of zonder wachtwoord.
Concreet advies uit de melding: bekijk onder andere /var/log/messages naar sshd-regels als Accepted password for … voor accounts die geen wachtwoord horen te hebben (bijvoorbeeld root of andere key-only gebruikers).
3) Onderzoek recent aangepaste accounts en configuratie
Neem bovendien de omgeving onder de loep: controleer recent aangemaakte gebruikers, instellingen voor doas, en de bestanden waarin authorized keys of toegangsgegevens staan. Als je niet met zekerheid kunt uitsluiten dat een login legitiem was, behandel de machine dan als mogelijk gecompromitteerd.
Wil je je aanpak breder koppelen aan het terugkerende thema rond patching en uitstel? Dan sluit dit goed aan op eerdere artikelen over de combinatie van dreiging en patchvertraging, zoals dreiging en patchvertraging: OpenSSH SSHole-bypass.
Hoe voorkom je dat dit soort incidenten opnieuw gebeurt?
SSHole laat zien hoe snel misbruik kan starten. Daarom is het verstandig om je proces rond updates en blootstelling te versnellen. Denk daarbij niet alleen aan “welke patch is er?”, maar ook aan “hoe snel detecteren we misbruik?”
- Houd een inventaris bij van systemen met OpenSSH in kwetsbare combinaties (musl + PAM uit).
- Automatiseer het detecteren van verdachte loginpatronen in sshd-logs.
- Test updateprocedures in een stagingomgeving, zodat productie niet vertraagt.
- Evalueer je exposure-management: kun je snel zien waar je netwerk nog open SSH endpoints heeft?
Als je wilt oefenen met blootstellingscontrole, biedt dit artikel mogelijk extra houvast: Exposure management: 5 tests om blootstelling te checken.
Conclusie
Dreiging en patchvertraging zijn bij OpenSSH SSHole letterlijk gekoppeld aan de tijd sinds publicatie. De kwetsbaarheid kan aanvallers in staat stellen om in te loggen op bepaalde password-disabled accounts, zonder gestolen wachtwoorden of SSH-sleutels. Omdat de impact afhankelijk is van de privileges van het gecompromitteerde account, is snelle actie belangrijk.
Update naar OpenSSH 10.6p2 (of een door jouw distributie gepatchte variant), herstart sshd en controleer de relevante sshd-logregels. Lukt uitsluiten niet, behandel de systemen dan alsof ze al zijn geraakt—dat is de veiligste route bij dit soort snelle exploits.
Bron: https://thehackernews.com/2026/11/hackers-exploited-openssh-sshole-flaw.html
