OpenSSH の脆弱性 CVE-2026-123158（sshole）の影響確認と対処手順

2026年11月5日に OpenSSH 10.6p2 が公開された、sshd のパスワード認証バイパス「CVE-2026-123158」（通称 sshole）は、11月9日に米CISAの悪用確認済み脆弱性（KEV）カタログへ追加された。影響を受けるのは、musl libc 上で PAM なしに動く sshd、つまり Alpine Linux を代表とする環境である。Debian・Ubuntu・RHEL など glibc のディストリビューションは対象外と報じられている。

本記事は2026年11月10日時点の OpenSSH リリースノート、Alpine Linux の公式アドバイザリ、NVD／CVE レコード、CISA KEV、GitHub のコミットに基づく。確認できなかった点は「公式に明記なし」「公式参照」と書き、推測では埋めていない。初報の経緯は2026年11月6日の脆弱性まとめ、直近の動きは11月10日のまとめも参照。

- 何が起きたか: OpenSSH の sshd が、musl libc で PAM なしの Linux 上で、257〜1024 文字程度の長いパスワードを入れるだけで、パスワードが設定されていないアカウント（シャドウファイルの値が *）にログインできてしまう。CVSS 3.1 は 8.1（High、CNA の MITRE による評価）。11月9日に CISA KEV へ追加され、期限は11月12日。
- 誰が対象か: Alpine Linux（コンテナのベースではなく、sshd を動かしているホストや仮想マシン）、OpenWrt・Buildroot・Yocto など musl 系の組み込み Linux。glibc 系（Debian／Ubuntu／Fedora）、PAM を使う構成、Dropbear、OpenBSD は対象外とされる。
- 今日やること: ①自社に Alpine／musl 系で sshd を動かす機器がないか棚卸し、②あれば修正版へ更新して sshd を再起動（更新だけでは動作中のデーモンは入れ替わらない）、③すぐ更新できなければ PasswordAuthentication no にして再起動し、④ログに身に覚えのないパスワードログインがないか確認する。

Alpine の公式アドバイザリは、確認した全リリース（3.16〜3.24 と edge）が対象だとしている。ただし後述の「4つの条件」がそろわなければ悪用できない。

Alpine のパッケージ版は、上流の 10.6p2 ではなく各ブランチの版にバックポートされている。「10.6p2 でなければ未修正」と判断せず、上の表のパッケージ版以上かどうかで見ること。上流（OpenSSH 本体）の修正版は 10.6p2 で、NVD／CVE レコードでは 10.6p2 より前が対象とされている。

Linux では、パスワードのないアカウントは /etc/shadow のパスワード欄が * になっている。通常、* はどんなパスワードをハッシュしても一致しない「ログイン不可」の印として使われる。Alpine のベースイメージでは、鍵認証専用にするため root が * になっている（Alpine 3.16 以降）。LDAP などから来るユーザーが * になる例もある。

PAM なしの sshd は、入力されたパスワードを crypt() 関数でハッシュし、保存値と比べる。musl の crypt() は、失敗したときに * を返す作りになっている。さらに musl の SHA-512 方式は 256 バイトを超えるパスワードを受け付けず、失敗する。つまり 257 バイト以上の長いパスワードを入れると crypt() が * を返し、保存値が * のアカウントでは両者が一致して、認証が通ってしまう。以上は Alpine の公式アドバイザリと、発見者側のサイト（sshhole.com）の説明による。

なお sshd は、パスワード欄が短すぎてソルト（ハッシュの種）を取り出せないアカウントに対して、別のアカウントのソルトを借りる。このため、システム上に $5$ または $6$ 形式のハッシュを持つアカウントが1つ以上あることも悪用の条件になる（Alpine の公式アドバイザリ）。NVD の記述は「256〜1024 文字のパスワードが通る」、Alpine は「257〜1024 バイト」としており、境目の数字は資料によって1ずれている。

OpenSSH 側の公式の説明は短い。10.6p2 のリリースノートは、これを sshd 内で回避できる「重大な回避策（critical security workaround）」と呼び、根本原因は sshd の外にあると見ている。GitHub のコミット「avoid password authn bypass」の差分からは、保存されたハッシュ文字列が最小の長さに満たない場合に一致を認めないチェックが加わったと読み取れる（コミットメッセージ自体には仕組みの詳細は書かれていない）。

Alpine の公式アドバイザリによれば、次の4つがすべて成り立つホストが対象である。1つでも崩れていれば、この経路では突破されない。

- sshd が PAM なしでビルドされている（Alpine の openssh-server の既定）、または openssh-server-pam を使っていても UsePAM no である
- PasswordAuthentication が yes である（OpenSSH の既定は yes）
- パスワード欄が * のアカウントが1つ以上ある（Alpine のベースイメージの root、鍵認証専用ユーザー、nslcd・winbind・sssd 由来のユーザーなど）
- $5$ または $6$ ハッシュを持つローカルアカウントが1つ以上ある

逆に、PasswordAuthentication no の環境、UsePAM yes の環境、アカウントが ! でロックされている環境、$ 形式のハッシュが1つもない環境、cloud-init イメージで PasswordAuthentication no が設定済みの環境は、Alpine の公式アドバイザリで「対象外」とされている。ただし、組み込み機器（Yocto 系）で「ロックしたサービスアカウント」がある標準構成でも再現できたという独立した報告（Medcrypt 社による oss-security への投稿）もあるため、「自分の機器は大丈夫なはず」と決めつけず、下の手順で確かめたい。

NVD の記録によれば、CISA は11月9日にこの脆弱性を KEV カタログへ追加した。登録名は「OpenBSD OpenSSH Unexpected Status Code or Return Value Vulnerability」、CWE は CWE-394、対応期限は11月12日である。CISA の SSVC 評価は「Exploitation: active（悪用確認）」「Automatable: no」「Technical Impact: total」となっている。

脅威インテリジェンス企業 Previdian は、CVE 公開から9時間足らずで最初の試行を観測し、本物の Alpine と OpenSSH を動かすハニーポットで root のアクセス成功を確認したと報じられた（Help Net Security、11月6日）。記録された8回の試行は日本のIPアドレス1つから、id・uname・hostname といった偵察コマンドを実行するものだった。GitHub には概念実証（PoC）も公開されているが、Previdian は未検証のコードにマルウェアが含まれる恐れがあると警告している。自社環境の検証には、後述の出典にある発見者のチェッカーを使うか、手元の隔離環境だけで試すこと。

確認はすべて、自社が管理するサーバーや機器の上で行う。外部のサーバーに対して長いパスワードを送るような試験は、不正アクセスにあたるので行わない。

まず、そのホストが musl かどうか、OpenSSH の版は何かを見る。Alpine は /etc/os-release に表示される。

ldd の出力に musl の名前が出れば musl 系である（glibc なら libc.so.6 が出る）。sshd の場所が違う機器では which sshd の結果に置き換える。Alpine で入っている OpenSSH のパッケージ版と、更新候補は次で確認できる。

次に、sshd の「実際に効いている」設定を見る。設定ファイルを読むより、sshd -T で実効値を出すほうが確実である（root 権限が必要）。

passwordauthentication no なら、この経路での突破はできない。yes の場合は、パスワード欄が * のアカウントと、$5$／$6$ ハッシュを持つアカウントがあるかを調べる。

1つ目に1件でも出て、2つ目にも1件でも出れば、4つの条件のうち残りの2つは成立している。そのうえで PasswordAuthentication が yes で PAM なしなら、パッチ前は対象と判断する。発見者の GitHub リポジトリ（oz9un/sshole）には、これらを一括で調べる check.sh が公開されている。実行前に中身を読み、管理下のホストでのみ使うこと。

Docker イメージについては、そのイメージ内で sshd を動かしているかが分かれ目になる。次のようにイメージの中身を確認できる（IMAGE は調べたいイメージ名）。

sshd が入っておらず、コンテナ内で動かしてもいなければ、このCVEの対象ではない。sshd を同梱するイメージ（SSH で入る踏み台や SFTP 用のイメージなど）は、ベースが Alpine かどうかを必ず確認する。

Alpine の公式アドバイザリの手順は、更新して sshd を再起動することである。更新だけでは動作中の sshd が古いまま残る点に注意したい。

更新後は apk info -v openssh-server で、前掲の表のパッケージ版以上になっていることを確認する。3.16〜3.20 のような通常サポートの終わったブランチにも修正パッケージは出ているが、これを機にサポート中のブランチへ移行したほうがよい。AWS や Azure で Alpine の公式クラウドイメージを使っている場合、既定の alpine ユーザーがパスワードなしで doas（sudo 相当）を使えるため、突破されると root まで到達し得る。修正版を含む 3.21.10／3.22.8／3.23.8／3.24.4 以降のイメージで作り直すか、稼働中のインスタンスは上のコマンドで更新する。

sshd を動かしていないコンテナは、公式アドバイザリで「対象外」とされている。sshd を同梱するイメージは、ベースイメージを更新して再ビルドし、デプロイし直す。Dockerfile の側では、sshd を入れる行の前にパッケージを更新し、アプリが使えるなら PasswordAuthentication no を焼き込むのが安全である。

ベースの alpine:3.24 などのタグが、修正版（3.24.4 など）を含むかどうかは、公式イメージのレジストリ側の公開状況に依存する。確認が取れていないため、ビルド後に apk info -v openssh-server で表の版以上になっているかを必ず見ること。サードパーティの sshd 入りイメージ（panubo/docker-sshd など）は、この記事を書いた時点で GitHub のイシュー（#93）が閉じておらず、修正済みかを確認できなかった。利用中ならメンテナの情報を確認し、直るまでは PasswordAuthentication no を設定する。

これらは musl を使うため、発見者側のサイトは対象としている。ただし OpenWrt の修正パッケージの版番号は、公式の情報で確認できなかった。各プロジェクトのセキュリティ告知とパッケージフィードを確認してほしい。機器メーカー提供のファームウェアでは、メーカーの告知を待つことになる。待つ間は、後述の緩和策（パスワードログインの無効化と SSH 到達範囲の限定）を取る。Yocto 系では、パスワード欄が * の「ロック済みサービスアカウント」と $6$ ハッシュを持つアカウントが同居する標準構成でも再現できた、という報告がある。

上流の修正は OpenSSH 10.6p2 に入っている。10.6p2 以降へ更新するか、GitHub のコミット 4353fdc（avoid password authn bypass）を取り込む。発見者のリポジトリには、より古い版向けに上流の修正をそのまま移植したパッチが置かれ、README は 7.3p1 以降に当てられると述べている。社内のビルドを再配布している場合は、配布先も含めて更新する。

すぐに更新できないときの対処は、パスワードでのログインを止めることである。Alpine の公式アドバイザリは、設定のドロップインを使う次の手順を示している（root で実行）。作業中に自分が締め出されないよう、既存の SSH セッションは開いたままにして、別のセッションで鍵ログインを試すこと。

最後の行が passwordauthentication no を表示すれば設定は効いている。発見者側のサイトも、これで問題の入口をふさげるとしている。この設定は鍵認証でのログインに影響しない。ただしパスワードで入る運用の人は、先に公開鍵を登録しておくこと。

補助的な対策として、次を併用する。いずれも修正の代わりにはならない。

- SSH の到達範囲を絞る: ファイアウォールやセキュリティグループで、22番ポートを自社の固定IP・VPN・踏み台だけに許可する。インターネット全体に開けない
- 鍵認証に一本化する: 公開鍵が登録済みであることを確認してから、パスワード認証を止める
- アカウントを整理する: 使っていないアカウントの削除、サービスアカウントのロックを見直す。ただし Alpine の公式アドバイザリは、! でロックされたアカウントは対象外としているものの、パスワード欄を * から ! に変える手順そのものは示していない。変更する場合は、鍵ログインが使えなくなる副作用（Alpine は過去に root を ! にして鍵ログインを壊した経緯がある）を事前に確認する
- PermitEmptyPasswords について: PermitEmptyPasswords no がこの経路を防ぐかどうかは、Alpine のアドバイザリにも OpenSSH のリリースノートにも書かれていない。緩和策としては頼らない

なお発見者は Wakefield 社の Özgün Kültekin 氏で、OpenSSH のリリースノートにも報告者として記されている。

更新や緩和の前に、すでにログインされていないかを確認する。Alpine の公式アドバイザリは、/var/log/messages の sshd のログに、パスワードのないアカウントへの「Accepted password for」がないかを探すよう案内している。あわせて doas の使用履歴、見覚えのないユーザーやファイル、authorized_keys の追加も見る。

パスワードを使わない運用のホストで「Accepted password for」が1件でも出ていれば、不正ログインの疑いがある。ログの保存先は構成により /var/log/auth.log や syslog の転送先など異なる。見つかった場合は、そのホストを隔離し、認証情報と鍵の総入れ替えを含めて調査する。外部サービスへの到達情報や、他システムへの横展開の有無も確認する。

- 自社で sshd を動かしている Alpine／OpenWrt／Buildroot／Yocto 系の機器・仮想マシン・コンテナを洗い出す
- 各ホストで sshd -T を実行し、passwordauthentication と usepam を確認する
- /etc/shadow でパスワード欄が * のアカウントと、$5$／$6$ ハッシュのアカウントを確認する
- 該当ホストは apk upgrade -U -a のうえ rc-service sshd restart（Alpine）。版が表の値以上かを確認する
- 更新できないホストは PasswordAuthentication no にして sshd を再起動する
- 22番ポートの到達元を、VPN・固定IP・踏み台に限定する
- /var/log/messages 等で「Accepted password for」を探し、侵害の有無を確認する
- Alpine ベースで sshd を同梱するイメージを再ビルドし、デプロイし直す
- OpenWrt・組み込み機器は、各プロジェクト／メーカーの告知を確認し、修正までは緩和策を維持する
- 更新漏れを防ぐ体制は、中小企業のパッチ・アップデート管理ガイドも参考にする

SSH／SFTP サーバーの構成そのものを見直すときは、Google Cloud での FTP／SFTP サーバー構築ガイドも、公開範囲と認証方式の考え方の参考になる。

- OpenSSH 10.6p2 リリースノート: https://www.openssh.org/releasenotes.html#10.6p2
- Alpine Linux 公式アドバイザリ（2026-11-05）: https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
- GitHub コミット 4353fdc（avoid password authn bypass）: https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482
- NVD CVE-2026-123158（CVSS 3.1 8.1、CWE-394、KEV 追加日 2026-11-09）: https://nvd.nist.gov/vuln/detail/CVE-2026-123158
- CVE レコード: https://www.cve.org/CVERecord?id=CVE-2026-123158
- CISA 既知の悪用された脆弱性カタログ: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-123158
- 発見者の解説サイト sshole: https://sshhole.com/
- 発見者のチェッカー・PoC・パッチ（実行前に内容を確認すること）: https://github.com/oz9un/sshole
- Help Net Security（Previdian による悪用観測、2026-11-06）: https://www.helpnetsecurity.com/2026/11/06/openssh-sshole-cve-2026-123158-exploitation/
- oss-security（Medcrypt 社による再現報告、2026-11-09）: http://www.openwall.com/lists/oss-security/2026/11/09/27