Exploited vulnerabilities · Briefing
OpenSSH SSHole bypass: attacks reported against an Alpine Linux honeypot
Reported honeypot exploitation raises the urgency of checking affected SSH configurations. Defenders need to verify account settings, deploy the fix and restart the service.
Kinwilder research desk · · AI-assisted analysis
What is established
An OpenSSH authentication bypass has drawn reported attacks against a monitored decoy. In reporting published November 6, 2026, Help Net Security says Previdian recorded eight attempts at one sensor and confirmed root access to its Alpine Linux honeypot. Previdian placed its first observation less than nine hours after CVE publication.
CERT-FR’s alert was published November 5; its text includes a November 6 update identifying CVE-2026-123158. It dates OpenSSH’s security advisory to November 5 and lists versions before 10.6p2 as affected, subject to configuration conditions.
SOCRadar’s November 6 report describes those conditions: Linux using musl, OpenSSH without active PAM authentication, password login enabled, an account marked with *, and another account holding a suitable password hash. Alpine’s default server package uses the relevant musl/non-PAM combination. Its distribution fixes include backports, so an older upstream version number alone does not establish exposure.
Who is behind it
Attribution is not established. Help Net Security reports a source address located in Japan; that describes infrastructure geography, not the operator’s location or nationality. No supplied report identifies a named activity cluster, ransomware affiliate, state association, motive or targeted sector. The reported compromised system was a honeypot, not an identified production victim.
Our analysis
Analysis: The failed boundary separates an authentication calculation from an authorization decision. The Hacker News explains that musl can return an asterisk when password hashing fails; OpenSSH can compare that result with the same marker in a password-disabled account and accept the login. An error representation becomes apparent evidence of identity.
From an attacker’s perspective, the opportunity is an exposed login path whose implementation mistakes failure for success. From a defender’s perspective, the dangerous assumption is that a disabled account password automatically disables every password-authentication route. The basic principle is to reject invalid authentication state before comparing results.
Exposure assessment therefore needs to connect several layers: the running service, its authentication backend, effective configuration and account state. A distribution name or scanner banner cannot answer all those questions. Prioritising reachable administrative services is reasonable; assuming every installation of the same distribution is exploitable is not supported.
Analysis — possible AI applications: An attacker could use AI to accelerate interpretation of public technical descriptions. Defenders could use it to reconcile inventories, review configuration differences and organise suspicious-login timelines. These are possible applications, not evidence that AI powered the reported attacks. Any generated conclusion should remain traceable to configuration or telemetry that an analyst can check.
Defensive actions
First, establish whether the service meets the affected conditions. CERT-FR requires restarting sshd after either patching or changing configuration. If patching is unavailable, it recommends disabling password authentication or, failing that, stopping the service. Use the fixed upstream release named above or the appropriate distribution backport.
Next, investigate access. The Hacker News, relaying Alpine’s guidance, recommends reviewing /var/log/messages for successful password logins involving accounts that should reject them, then examining privilege elevation through doas, account creation and changes to authorised SSH keys. It also relays advice to treat unresolved possible logins as compromise.
Analysis — practical verification exercise: On an authorised test host, document the intended authentication policy for a representative key-only account. Confirm the effective service configuration, validate it, restart safely and check that legitimate key access still works while an ordinary password login fails. Keep recovery access available. This checks the intended boundary without reproducing the exploit; Kinwilder has not performed this exercise.
Analysis: Harden the surrounding permissions too. Ask whether a service account can obtain administrative privileges without another approval boundary, whether authentication logs reach central storage, and whether rebuilt images inherit the corrected package and configuration.
Key concepts
- musl: The C library involved in the reported password-hashing behaviour.
- PAM: A framework through which systems can handle authentication; its use changes this flaw’s applicability.
- Honeypot: A monitored decoy used to observe hostile activity.
- Backport: A security correction applied to an older maintained software version.
Limits
SOCRadar reported no known attacks as of November 6; the two press reports published that day carry Previdian’s exploitation account. Those reports share one telemetry provider and do not independently corroborate it. The packet establishes neither wider production compromise nor campaign scale. Kinwilder did not reproduce the vulnerability or inspect the underlying telemetry.
Kinwilder briefing: AI-written analysis of public reporting, checked in a separate AI review against the linked sources. No human expert review or independent reproduction is implied.
Sources
- CERT-FR: [MàJ] Vulnérabilité dans OpenSSH
- SOCRadar: sshole: OpenSSH Fixes Password Bypass on Alpine Linux
- The Hacker News: Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot
- Help Net Security: OpenSSH flaw exploited in the wild just hours after disclosure (CVE-2026-123158)