Karen IT Security Response Center (KSRC) Advisory

Advisory ID: KSRC-2026-11061 | Publication Date: 06 November 2026

Password Authentication Bypass in OpenSSH on musl-based Linux
CVE-2026-123158 (sshole)

Summary

A high-severity authentication bypass vulnerability has been identified in OpenSSH that allows an unauthenticated remote attacker to log in to certain accounts by supplying an oversized password. The vulnerability is tracked as CVE-2026-123158 (also known as sshole) and has been assigned a CVSS v3.1 score of 8.1 (High).

The issue affects OpenSSH versions prior to 10.6p2 when running on Linux systems that use the musl libc and do not use PAM. The most common affected platform is Alpine Linux. Exploitation in the wild has been observed within hours of public disclosure.

Technical Overview

The vulnerability stems from incorrect handling of password verification in sshd when musl’s crypt() implementation is used without PAM. For certain account configurations (particularly those whose shadow password field is exactly *), any password between approximately 256 and 1024 characters is incorrectly treated as a valid password hash and accepted.

An attacker who can reach the SSH service needs only the username of a suitable account and a long random string as the password. No knowledge of the real password, private key, or other credentials is required. On many Alpine-based systems this can lead to immediate shell access and, in common configurations, subsequent privilege escalation to root.

Systems using glibc (Debian, Ubuntu, RHEL, Fedora, Amazon Linux, etc.) are not affected. The vulnerability is limited to musl-based environments without PAM.

Affected Systems

  • OpenSSH prior to 10.6p2
  • Running on Linux with musl libc
  • PAM disabled or not compiled in (UsePAM no or equivalent)
  • Password authentication enabled (the default in many configurations)

Fixed version: OpenSSH 10.6p2 (released 5 November 2026). Alpine Linux and other musl-based distributions have also released patched packages for their supported branches.

Commonly affected environments include Alpine Linux containers, certain embedded systems, and OpenWrt in specific configurations.

Exploitation Status

  • Public disclosure and patch release on 5 November 2026.
  • Active exploitation observed less than 9 hours after disclosure.
  • Confirmed successful root-level access on Alpine Linux honeypots.
  • Public proof-of-concept material and reproduction labs are available.
  • Not yet listed in the CISA KEV catalog as of this advisory’s publication.

Recommendations

  1. Immediate Action: Upgrade OpenSSH to version 10.6p2 or later, or apply the security update provided by your distribution (especially important for Alpine Linux and other musl-based systems).
  2. Restart the sshd service after the update to ensure the patched binary is running.
  3. If an immediate upgrade is not possible, disable password authentication by setting PasswordAuthentication no in sshd_config and relying on key-based authentication, or enable PAM if feasible.
  4. Review SSH logs for successful logins that used unusually long passwords or that originated from unexpected source addresses around and after 5 November 2026.
  5. Audit accounts whose password field is * and ensure they do not allow interactive login if not required.
  6. For container environments, rebuild and redeploy images that contain vulnerable OpenSSH packages.
  7. If compromise is suspected, treat the system as compromised: rotate credentials, review process and file integrity, and investigate for further activity.

Although the vulnerability is limited to specific configurations, Alpine Linux and musl-based containers are widely used in cloud and DevOps environments. Organizations running such systems should treat this as a high-priority patch.

Support from KSRC

KSRC (Karen IT Security Response Center) is fully prepared to assist organizations with any questions, technical guidance, or incident-related issues arising from this vulnerability.

Whether you require help with impact assessment, mitigation planning, forensic guidance, or response coordination, our team is available.


Karen IT
We make the Internet harder to abuse.