← Back to All News & Security Advisories
*sshole CVE-2026-123158: OpenSSH and musl Authentication Bypass on Alpine Linux
脆弱性「*sshole」（CVE-2026-123158）：Alpine LinuxとOpenSSHの認証バイパス解説
| Critical Security Advisory
Technical analysis of CVE-2026-123158 ('*sshole'), a critical authentication bypass affecting OpenSSH on musl libc distributions like Alpine Linux. By supplying any password between 257 and 1,024 characters, remote attackers force musl's crypt() to return a literal asterisk ('*'), matching locked or SSH key-only shadow entries and granting immediate unauthenticated shell access.
Alpine Linux等のmusl libc環境で稼働するOpenSSHにおいて、257〜1,024文字の任意の長いパスワードを送信するだけで公開鍵専用アカウントやロック済みアカウントへ不正ログインが可能となる重大な認証バイパス脆弱性「*sshole」（CVE-2026-123158）のメカニズムと緊急対策を解説します。
1. Executive Overview: The Anatomy of a Trivial Authentication Bypass
On November 5, 2026, a severe authentication bypass vulnerability tracked as CVE-2026-123158 and dubbed '*sshole' was disclosed affecting OpenSSH running on systems powered by the musl C standard library (musl libc). Unlike complex memory corruption vulnerabilities that require precise heap grooming or KASLR leaks, *sshole is devastatingly simple to exploit: a remote attacker can log into password-disabled or SSH key-only accounts simply by entering any random string between 257 and 1,024 characters at the SSH password prompt.
While traditional enterprise distributions based on GNU glibc (such as Red Hat Enterprise Linux, Ubuntu, and Debian) are not vulnerable at the host OS layer, Alpine Linux and musl libc form the backbone of modern lightweight Docker containers, Kubernetes utility sidecars, SFTP jump boxes, and OpenWrt/Yocto edge appliances. Any exposed container or appliance running default OpenSSH on musl faces immediate, unauthenticated takeover.
2. Deep Technical Breakdown: How '*' == '*' Breaks SSH Key-Only Accounts
The vulnerability arises from an unexpected interaction between Unix shadow file conventions, OpenSSH anti-enumeration timing defenses, and musl libc's error handling inside crypt():
• The '/etc/shadow' Asterisk Convention: On Linux systems, accounts configured exclusively for SSH public-key login (as well as locked or system accounts) store a literal asterisk ('*') or exclamation mark ('!') in the password hash column of /etc/shadow. Because no standard cryptographic hashing algorithm ever outputs a single asterisk, password authentication for that account is supposed to be impossible.
• OpenSSH's Timing-Attack Mitigation: To prevent remote attackers from enumerating valid usernames by measuring CPU response times (a defense introduced after CVE-2016-6210), OpenSSH performs a dummy password hashing calculation even when the target account's shadow entry is '*' or locked.
• The musl libc crypt() Failure Return: In GNU glibc, when crypt() is called with an invalid salt or an oversized password input, it fails safely by returning NULL. In musl libc, however, passing a password longer than 256 bytes (specifically 257 to 1,024 bytes, bounded by OpenSSH's MAX_PASSWORD_LEN) causes musl's crypt() function to abort and return a static failure token: the literal string '*'.
• The Fatal strcmp('*', '*') Collision: When OpenSSH runs without Pluggable Authentication Modules (PAM, which is disabled by default on Alpine Linux), sys_auth_passwd() takes the '*' returned by the failed musl crypt() call and compares it via strcmp() against the '*' stored in /etc/shadow. Because '*' equals '*', OpenSSH mistakes the hashing error for a valid password match and grants the attacker immediate shell access.
3. Impact Matrix: Why Container Bastions & Cloud Images Face Instant Root Takeover
Understanding which layers of enterprise infrastructure are exposed requires examining all four prerequisites required for exploitation:
1. The system uses musl libc (Alpine Linux, OpenWrt, Buildroot, Void Linux musl, or Yocto embedded builds).
2. OpenSSH (sshd) runs without PAM enabled (the default package behavior in Alpine's openssh-server).
3. PasswordAuthentication is set to 'yes' (also enabled by default unless explicitly hardened in sshd_config).
4. The target user has '*' in /etc/shadow (typical for SSH key-only administrative users or service accounts) and at least one account on the system has a valid password hash so OpenSSH selects a valid hashing algorithm for its dummy salt.
On cloud virtual machine images and container bastions built on Alpine Linux, the default administrative user is routinely configured with '*' in /etc/shadow (for SSH key login) alongside passwordless privilege escalation via 'doas' or 'sudo'. Once an attacker bypasses SSH authentication using a 257-character password, executing 'doas su -' immediately yields full root control.
- Exposed Docker & Kubernetes SSH Sidecars: Lightweight SFTP containers, Git servers (such as Gitea/GitLab Alpine images), and CI/CD build agents exposing port 22 or high-numbered SSH ports.
- Cloud-Init & Virtual Machine Appliances: Alpine-based cloud instances where administrators assumed adding an SSH public key automatically disabled password login.
- Network Edge & IoT Gateways: OpenWrt and custom embedded Linux routers utilizing OpenSSH (rather than Dropbear) compiled against musl libc.
4. Immediate Remediation, Workarounds & Enterprise Hardening
Infrastructure teams should execute the following remediation steps immediately across all container registries, cloud accounts, and edge networks:
• Upgrade to OpenSSH 10.6p2 Immediately: The OpenSSH project released version 10.6p2 (and Alpine Linux backported patches across Alpine 3.16 through 3.21) adding explicit guards in sys_auth_passwd() that reject any shadow password field starting with '*' or '!' or measuring fewer than 13 characters before comparing hashes. Run 'apk update && apk upgrade openssh' across all Alpine instances and rebuild container images.
• Enforce 'PasswordAuthentication no' Globally: Never rely solely on locked shadow entries ('*') to block password logins. Explicitly set 'PasswordAuthentication no' and 'KbdInteractiveAuthentication no' in /etc/ssh/sshd_config on all servers and containers using public-key authentication.
• Audit Hidden Container SSH Daemons: Scan internal and external IP ranges as well as Kubernetes service manifests for container workloads exposing SSH daemons built on Alpine base images.
• 24x7 SSH Telemetry with Entinux NMS: Entinux provides comprehensive security auditing, container image hardening, and 24x7 network monitoring across Hong Kong and Japan. Entinux NMS continuously tracks SSH daemon logs, anomalous authentication attempts, and unauthorized container sessions to stop perimeter breaches before lateral movement occurs.
1. 脆弱性の概要：わずか257文字の入力で突破される重大な認証バイパス
2026年11月5日、軽量C標準ライブラリである「musl libc」を採用したLinux環境で稼働するOpenSSHにおいて、極めて深刻な認証バイパス脆弱性「CVE-2026-123158」（通称：*sshole）が公表されました。高度なメモリ操作や競合状態の誘発を必要とするカーネル脆弱性とは異なり、本脆弱性は「SSHのパスワード入力欄に257文字から1,024文字の任意の文字列を入力するだけ」という極めて単純な手順で悪用可能です。
Red Hat Enterprise Linux（RHEL）やUbuntu、Debianなど、GNU glibcとPAMを標準採用している一般的なエンタープライズLinuxのホストOS自体は直接の影響を受けません。しかし、DockerコンテナやKubernetesのサイドカー、SFTP踏み台コンテナ、CI/CDエージェント、さらにはOpenWrtやYoctoなどのエッジ機器で広く使われている「Alpine Linux」はmusl libcを基盤としており、デフォルト設定のままSSHを公開している環境では認証なしで即座に侵入される危険があります。
2. 深層技術解説：なぜ『* == *』で公開鍵専用アカウントが突破されるのか
この脆弱性は、Linuxのシャドウファイル仕様、OpenSSHのタイミング攻撃対策、そしてmusl libcにおけるcrypt()関数のエラー返り値という3つの要素が連鎖することで発生します。
• /etc/shadowにおける「*」の意味：Linuxシステムでは、SSH公開鍵認証のみを許可しパスワードログインを禁止したアカウント（またはロックされたシステムアカウント）の/etc/shadow第2フィールド（パスワードハッシュ欄）には、慣例としてアスタリスク「*」または感嘆号「!」が記録されます。通常のハッシュ関数が1文字の「*」を出力することはあり得ないため、本来であればどのようなパスワードを入力しても一致しないはずの仕組みです。
• OpenSSHのユーザー名列挙防止（ダミーハッシュ処理）：OpenSSHは過去のタイミング攻撃脆弱性（CVE-2016-6210）への対策として、対象アカウントのハッシュ欄が「*」であっても、応答時間の差からアカウントの存在を推測されないよう、入力されたパスワードをダミーのソルトとともにCライブラリのcrypt()関数へ渡して計算を行わせる設計になっています。
• musl libcのcrypt()が返すエラー文字列「*」：GNU glibcのcrypt()は、不正な入力やエラー発生時に「NULL」を返します。ところがmusl libcのcrypt()実装では、256バイトを超える長さのパスワード（OpenSSHの上限である1,024バイトまでの257〜1,024文字）が渡されると、処理を中断してエラーを示す固定文字列「*」を返却する仕様となっていました。
• 致命的な文字列比較（strcmp('*', '*') == 0）：Alpine Linuxの標準構成のようにPAMを介さず動作するOpenSSH（sys_auth_passwd関数）は、muslのcrypt()が返したエラー記号「*」を受け取り、そのまま/etc/shadow内の「*」とstrcmp()で比較してしまいます。結果として「'*' と '*' が一致した（正しいパスワードが入力された）」と誤判定され、パスワードを知らない攻撃者に即座にログインを許可してしまいます。
3. 影響範囲の整理：コンテナ踏み台やクラウドイメージが直面するRoot奪取リスク
本脆弱性（*sshole）が成立するためには、以下の4つの条件が同時に満たされている必要があります。
1. OSまたはコンテナが「musl libc」を使用していること（Alpine Linux、OpenWrt、Buildroot等）。
2. OpenSSH（sshd）がPAM無効（UsePAM no、またはPAM非対応ビルド）で稼働していること（Alpine標準パッケージのデフォルト挙動）。
3. sshd_configにてパスワード認証が有効（PasswordAuthentication yes）になっていること（明示的に無効化していない場合のデフォルト）。
4. 標的アカウントの/etc/shadowハッシュ欄が「*」であり、かつシステム内の少なくとも1つのアカウントに有効なパスワードハッシュが設定されていること（ダミーソルト生成アルゴリズムの選択に利用されるため）。
特にクラウド上のAlpine Linuxイメージや自動化コンテナ環境では、初期管理ユーザー（alpine等）に対して「SSH公開鍵のみを登録（shadowは*）」した上で、doasやsudoによるパスワードなしの管理者権限昇格（nopass）を許可しているケースが多々あります。この場合、257文字の適当なパスワードでログインされた直後に、そのままホストやコンテナの完全なRoot権限を奪取されます。
- Docker・Kubernetes内のSSH公開コンテナ：ファイル転送用SFTPコンテナ、Gitサーバー（AlpineベースのGitea/GitLabイメージ等）、デバッグ用踏み台Pod。
- クラウドインスタンスおよび軽量VM：SSH鍵を登録したことでパスワードログインも自動的に無効化されたと思い込んでいるAlpine Linuxサーバー。
- エッジルーターおよびIoTゲートウェイ：DropbearではなくmuslビルドのOpenSSHを有効化しているOpenWrt機器や産業用ゲートウェイ。
4. 緊急対策、設定変更（ワークアラウンド）、およびインフラ総点検
影響を受ける可能性のある環境を運用している組織は、直ちに以下の対策を実施してください。
• OpenSSH 10.6p2以降への即時アップデート：OpenSSHプロジェクトから修正版「10.6p2」が緊急リリースされ、Alpine Linuxの各ブランチ（3.16〜3.21およびedge）にも修正パッケージが配信されています。修正版では、/etc/shadow側の文字列が「*」や「!」で始まる場合や有効なハッシュ長に満たない場合、crypt()の結果にかかわらず無条件で認証を拒否するガードが追加されています。「apk update && apk upgrade openssh」を実行し、コンテナイメージを再ビルドしてください。
• PasswordAuthentication no の明示的徹底：公開鍵認証のみを使用するサーバーやコンテナでは、シャドウファイルの「*」だけに頼らず、必ず /etc/ssh/sshd_config に「PasswordAuthentication no」および「KbdInteractiveAuthentication no」を明記してsshdを再読み込みしてください。
• 隠れたAlpineコンテナ・踏み台の棚卸し：ホストOSがRHELやUbuntuであっても、その上で稼働するDockerコンテナが別ポートでAlpineのsshdを公開していないか、全ポートおよびコンテナイメージの棚卸しを実施してください。
• Entinux NMSによる24時間365日のSSH監視とセキュリティ診断：Entinuxは香港および日本（京都）の拠点から、エンタープライズLinuxおよびコンテナ基盤のセキュリティ監査、構成ハードニング、24時間365日のリアルタイム監視（Entinux NMS）を提供しています。不審なSSH認証試行や異常なセッション確立を即座に検知し、企業のインフラ境界を保護します。