OpenSSH認証バイパス“SSH hole”(CVE-2026-123158)｜musl+非PAMでrootの恐れ・10.6p2へ

OpenSSH に、通称 “SSH hole”（#sshhole） と呼ばれる認証バイパス脆弱性 CVE-2026-123158（GHSA-4fcc-vm97-gx3x・High・CVSS 8.1・2026-11-05 公開）が見つかり、OpenSSH 10.6p2 で修正された。条件はかなり限定的だが、はまると重い——Linux で musl libc（例: Alpine Linux）を PAM なしで使い、SSH パスワード認証が有効な構成では、256〜1024 文字のパスワードが一部のアカウント構成で通ってしまい、研究者の PoC では root（uid=0）取得が示された、と報じられている。しかもこの不具合は2016年から約10年潜んでいたとされる（発見 Pierre Arlais・bearstech 経由で紹介）。まずは関連ポストを置く。

OpenSSH 認証バイパス（#sshhole）

#sshhole（OpenSSH password authentication bypass）

土台の考え方は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説、直近の更新喚起は APT の深刻な脆弱性 CVE-2026-109518、AIアプリ側の話は ChatGPT ロックダウンモード回避 も参照。以下は GitHub Advisory（GHSA-4fcc-vm97-gx3x）を一次とした整理だ（解説サイト sshhole.com もある）。攻撃の再現手順・PoC は扱わない（防御が目的）。

何が起きたのか——パスワードが“ハッシュと誤解釈”される

GHSA の原文はこうだ——「10.6p2 より前の OpenSSH の sshd は、Linux で musl libc を PAM なしで使う場合、パスワード認証バイパスへの回避策を欠く（ある文字列がパスワードハッシュとして意図されているか否かの誤解釈に関連）。一部のアカウント構成では、256〜1024 文字のどのパスワードでも成功する。musl libc を PAM なしで使うプラットフォームの例が Alpine Linux」。

噛み砕くと、sshd がパスワードの正否を確かめる過程で、異常に長い入力文字列を「平文パスワード」ではなく別のもの（ハッシュ等）として扱ってしまう余地があり、その誤解釈により一部アカウント構成の判定がすり抜ける、ということだ。glibc や PAM を使う環境では回避策が効くが、musl ＋ PAM なしの組み合わせでその回避策が欠けていた。正規ユーザーが 256 文字のパスワードを打つ話ではなく、攻撃者が任意に長い文字列を送れる前提で読むべき脆弱性だ。ツイートでは PoC で root セッション取得（uid=0）が示されたと報じられているが、本記事では手口は扱わない。

なぜ PAM の有無で差が出るのか。PAM を使う構成では、認証は PAM モジュールに委ねられ、sshd 自身が生のパスワードハッシュ照合を主導しない。PAM を使わない構成では、sshd が libc の仕組みでパスワードを検証する。glibc と musl でその境界の扱いが異なり、musl ＋ PAM なしの経路で“回避策が欠けていた”——というのが今回の構図だ。だからこそ、同じ OpenSSH でも glibc や PAM 経由なら影響を外れる。なお「256〜1024」という範囲の理由は GHSA 本文に詳細がないが、要は通常ありえない長さの入力が引き金になる、ということだ。逆に言えば正規運用でこの範囲のパスワードを使うことはまずなく、検知の観点では“極端に長い認証試行”は疑わしい兆候になりうる。

影響する条件（と、しない構成）

「自分が対象か」は、次の4つが揃うかで切り分けられる。どれか欠ければ、原則この脆弱性の対象ではない。

まとめると、影響を受けるのは「OpenSSH 10.6p2 より前・musl libc・PAM 不使用・パスワード認証が有効」の4条件がそろう Linux（Alpine が代表例）だ。影響を受けるバージョンは「10.6p2 より前」で、修正は 10.6p2 以降（および各ディストロの配布パッケージ）に入る。

GHSA が明示するのは Alpine Linux（musl ＋ PAM なしの例）だ。GHSA が曖昧に書く「一部のアカウント構成（some configurations of accounts）」の正体は、研究者の告知（sshhole.com／*sshole、発見は Pierre Arlais・bearstech 経由）でより具体的だ——そもそもパスワードでログインできないはずのアカウント、すなわち root、鍵のみのデプロイユーザー、LDAP ユーザー、そして Alpine の AWS/Azure クラウドイメージの既定ユーザーなどが、256文字を超えるどんなパスワードでも受け入れてしまう、という。パスワードを設定していない（ロックされた）口ほど逆に通ってしまう点が不気味だ。対象は Alpine だけでなく、OpenWrt・buildroot・yocto、そして普段 pull している多くの Docker イメージに及ぶとされる。いずれにせよ、条件を厳密に詰めるより先に更新するのが安全側だ。

AWS/クラウドへの影響

結論から言うと、主要クラウドの既定構成では影響しにくい。だが「クラウドだから安全」ではなく、土台イメージ次第だ。

• 既定では影響しにくい：Amazon Linux 2/2023・Ubuntu などの主要 AMI は glibc を使い、sshd は PAM 経由（UsePAM yes）が既定、EC2 は既定でパスワード認証オフ＝鍵認証。この3点のどれもが本脆弱性の条件を外すので、既定の EC2 の多くは対象外になりやすい。
• 危険になりうる：Alpine ベースの自作イメージ/コンテナで sshd を動かし、パスワード認証を有効化している場合。コンテナは通常 sshd を持たないが、踏み台（bastion）・CI ランナー・アプライアンスを Alpine で作って sshd を入れているケースは実在する。OpenWrt 等の musl 機器も同様だ。ECS/EKS/Fargate でも、動かしているコンテナが上記に当てはまれば対象になりうる。とりわけ研究者の告知では、Alpine の AWS/Azure 公式イメージの“既定ユーザー”が名指しで挙げられている。クラウドで Alpine イメージをそのまま使っているなら、既定ユーザーのパスワード経路が開いていないかを特に確認したい（本来は鍵のみのはずのユーザーでも、256文字超のパスワードで通りうるのが怖い点だ）。

要は、「クラウドの既定 AMI」か「自分で組んだ Alpine/musl イメージ」かで明暗が分かれる。後者を使っているなら、イメージの OpenSSH 版・libc・PAM・パスワード認証設定を確認してほしい。コンテナで確かめるなら中身を見るのが早い——docker run --rm <image> sh -lc 'ldd --version 2>&1 | head -1; command -v sshd && apk info -v 2>/dev/null | grep -i openssh' のように、libc が musl か・sshd が入っているか・OpenSSH パッケージの版はいくつか、を一度に確認できる。そもそも本番コンテナに sshd を同梱しない設計（入っているのは例外）なら、この脆弱性の面はほぼ閉じる。なお本節の AWS 既定（glibc・PAM・鍵認証）は一般に知られた構成に基づく整理で、ベンダーの公式見解そのものではない。

対策と、自分のサーバーの確認

対処は「更新」が本筋。更新できないときの緩和として「パスワード認証の無効化」がある。

まず、自分の環境が条件に当てはまるかを確認する。

# OpenSSH の版（10.6p2 より前か）
#   狙いは sshd（サーバ）側。ssh -V はクライアント版だが、ssh と sshd は
#   通常同じパッケージ＝同じ版。確実なのはパッケージ照会。配布版はバックポート
#   修正で版番号が据え置きのことがあるので、番号だけで安全とは判断しない。
ssh -V
apk info -v 2>/dev/null | grep -i openssh      # Alpine
# dpkg-query -W openssh-server                  # Debian / Ubuntu
# rpm -q openssh-server                          # RHEL系 / Amazon Linux

# libc が musl か glibc か（"musl" と出れば該当 libc）
ldd --version 2>&1 | head -1

# PAM とパスワード認証の「実効」設定
#   sshd_config を直接 grep すると Include・Match・既定値を取りこぼすので、
#   sshd -T で実際に効いている値を見る。
sudo sshd -T 2>/dev/null | grep -Ei 'usepam|passwordauthentication|permitrootlogin'

更新・緩和はこうだ。

# Alpine なら更新（修正を含むパッケージへ）
apk update && apk upgrade openssh

# すぐ更新できないときの暫定緩和：パスワード認証を無効化
#   /etc/ssh/sshd_config に PasswordAuthentication no を設定し、sshd を再起動
#   （これは更新の代替であって根本対処ではない）

ただし、この結果だけでは安全とは言えない。表示される版や設定は「条件に当てはまりうるか」を示すだけで、すでに攻撃を受けたかどうかを判定するものではないし、修正が効いているかは更新の結果で別途確かめる必要がある。迷うなら、条件の精査より先に更新を当て、鍵認証へ寄せるのが安全側である。

根本的には、パスワード認証そのものをやめて公開鍵認証に一本化するのが最も強い。今回のように「パスワード検証のどこかにバグ」があっても、パスワードの口が閉じていれば入口から断てる。PasswordAuthentication no、PermitRootLogin prohibit-password（または no）、公開鍵のみ——これを既定にしておけば、この種の“パスワード経路の脆弱性”全般に強くなる。root の直接ログインを許していないかも、この機会に見直したい。

参照ソース

• GHSA-4fcc-vm97-gx3x（GitHub Advisory・CVE-2026-123158）（High・CVSS 8.1・2026-11-05 公開。影響条件の一次記述）
• CVE-2026-123158（NVD）（CVE 詳細）
• Alpine Linux の告知（2026-11-05）（Alpine 向けの対処。最新は公式で確認）
• OpenSSH リリースノート 10.6p2（公式）（修正の一次。最新は公式で確認）
• 報道ポスト：@openhack ／ @intcyberdigest