OpenSSHの脆弱性：KEV入りしたCVE-2026-123158の該当判定と対処

OpenSSHの脆弱性CVE-2026-123158（通称sshole）は、2026年11月9日に米CISAの悪用確認済みカタログへ載りました。対象はmusl libcでPAMを使わないsshdで、代表例はAlpine Linuxです。パスワードを持たないはずのアカウントに、長い文字列を送るだけでログインされます。この記事では11月10日時点の一次情報をもとに、該当するサーバーの見分け方、修正版、侵害の確かめ方、過去の主要な脆弱性の対象版までを実装者向けに整理します。

まとめ：Alpineのsshdは本日中に更新、glibc環境は配布元の修正状況で判断

Alpineでsshdを外部に開けているなら、今日のうちに修正パッケージへ更新し、sshdを再起動してください。すぐに更新できない場合はPasswordAuthentication noを先に入れます。公開から約40時間で最初の悪用が観測されており、様子を見る段階は過ぎました。

DebianやUbuntu、RHEL系の標準パッケージはglibcで動くため、この脆弱性の成立条件から外れます。スキャナに検出されても、今回の番号を理由に緊急メンテナンスを組む必要はありません。ただし2024年のregreSSHionなど別の脆弱性は、版番号ではなく配布元の修正状況で確かめます。

鍵認証だけで運用しているつもりのサーバーほど危険です。sshdのパスワード認証が既定の有効のままなら、鍵しか持たないアカウントが標的になります。台数が多く仕分けに手が回らないときは、脆弱性診断・セキュリティ診断で外部から届くsshdの棚卸しを先に済ませる方法もあります。

CVE-2026-123158（sshole）の成立条件と悪用を確認した観測データ

影響範囲は狭い一方、当てはまる環境では認証そのものが無効になります。まず条件を確定します。

muslとPAMなしのsshdで「*」のアカウントが通る6つの成立条件

Alpineの公式告知と発見者の解説ページを合わせると、次の6つがすべてそろったときに成立します。

1. sshdがmusl libc上で動いている（Alpine、OpenWrt、Buildroot、Yoctoなど）
2. PAMを使っていない（Alpineのopenssh-serverは既定でPAMなし）
3. PasswordAuthenticationがyesである（既定値）
4. パスワード欄が*のアカウントがある
5. 別のアカウントに$5$か$6$のハッシュが設定されている
6. パッケージが修正前である（上流では10.6p2より前）

4番目に当たるのは、鍵認証専用の利用者、LDAPなどディレクトリ由来の利用者、Alpine 3.16以降のrootです。!で始まるロック済みのアカウントは対象になりません。Dropbearで動かしている機器も対象外です。

深刻度はNVDの登録情報でCVSS 3.1の8.1（High）、攻撃条件の複雑さはHighと評価されています。この評価は6条件を前提にしたものなので、Alpineで条件がそろった環境では、より緊急に扱うのが実態に合います。

2026年11月9日のKEV掲載とGreyNoiseが捉えた最初の悪用時刻

11月6日頃までの日本語の解説には「悪用の報告なし」と書かれたものが残っています。現在は違います。CISAのKEVカタログは11月9日にこのCVEを追加し、対応期限を11月12日としました。この3日という期限の意味はBOD 26-04の解説で整理しています。

GreyNoiseの観測ページ（11月9日21時40分UTC更新）の時系列は次のとおりです。

修正の公開から攻撃コードの登場まで4時間16分、悪用の観測までは約40時間です。観測された攻撃元のIPは6個でした。ページ内の件数には段階の間で整合しない部分があるため、規模の根拠には使えません。読み取れるのは、悪用が始まったという事実と時刻までです。攻撃コードの公開と悪用の違いを踏まえても、更新の猶予はほとんど残っていません。

muslのcrypt失敗値とsshdのソルト選択が噛み合う原因コードの読解

単独では無害な3つの実装が重なって起きた問題です。仕組みが分かると、自社の別の認証処理を見直す材料にもなります。

256バイト超の鍵で「*」を返すmuslのcrypt_sha512の実装

muslのcrypt_sha512.cは、KEY_MAXを256と定め、それより長い鍵の処理を拒否します。拒否したときの戻り値が問題でした。

#define KEY_MAX 256

/* reject large keys */
for (i = 0; i <= KEY_MAX && key[i]; i++);
if (i > KEY_MAX)
	return 0;

内部の失敗は呼び出し元の__crypt_sha512で文字列"*"に変わります。NULLを返さないのはクラッシュを防ぐ配慮でしたが、*はパスワードを持たないアカウントの印と同じ値です。

長さの範囲については、NVDの説明は「256〜1024文字」、発見者は「257〜1024文字」と書いています。コード上は257バイトから拒否され、上限はauth-passwd.cのMAX_PASSWORD_LEN（1024）で決まるため、発見者の表記が実装と一致します。

別アカウントのハッシュを塩に使うpick_saltと2016年の修正

パスワード欄が*の1文字だと、sshdはそれをソルトに使えません。そこでxcrypt.cのpick_saltが、システム内で最初に見つかった$形式のハッシュからソルトを借ります。これは存在しない利用者でも処理時間を揃えるための仕組みで、発見者の解説によると2016年のユーザー列挙対策（CVE-2016-6210）に由来します。

ここで5番目の条件が効いてきます。借りたソルトが$5$か$6$のとき、長いパスワードはmuslの上限に当たって"*"になり、保存値の*と一致します。別のアカウントに実際のパスワードがない場合、ソルトは既定の"xx"のままなので、この経路は開きません。

Alpine側の事情も重なりました。発見者の年表では、2022年の3.16でrootのロック表記が!から*へ変わっています。鍵認証を通すための変更が、結果として標的を増やした形です。

10.6p2のMIN_PASSWORD_HASH_LENで4文字未満を拒否する修正

修正コミットは、比較の前に保存値の長さを確かめる条件を足しました。

#define MIN_PASSWORD_HASH_LEN 4

ret = encrypted_password != NULL &&
    strlen(pw_password) >= MIN_PASSWORD_HASH_LEN &&
    strcmp(encrypted_password, pw_password) == 0;

コミットの説明は、根本原因はOpenSSHの外にあるが回避できる立場にある、という趣旨です。自社のコードでcrypt()の結果を文字列比較している箇所があれば、同じ型の不具合になります。失敗の値が正規の値と重ならないかを確認してください。

該当するホストとDockerコンテナを仕分けるシェルスクリプトの実行手順

ここでのコマンドは公式の告知とソースコードをもとに組み立てたもので、筆者の環境では実行していません。検証環境で動きを確かめてから本番に流してください。

1台のAlpineで認証を試さず6条件を確かめるスクリプトの実行

rootで実行すると、ログインを試さずに設定とアカウントの形だけを確かめます。出力に個々のパスワードハッシュは含みません。

#!/bin/sh
# sshole-triage.sh（rootで実行。認証は試さない）
cfg=$(sshd -T 2>/dev/null)
[ -n "$cfg" ] || { echo "sshd -T に失敗。設定を確認する"; exit 1; }

ldd "$(command -v sshd)" | grep -q musl && libc=musl || libc=other
printf '%s\n' "$cfg" | grep -qi '^usepam yes' && pam=yes || pam=no
printf '%s\n' "$cfg" | grep -qi '^passwordauthentication yes' && pw=yes || pw=no
star=$(awk -F: '$2 == "*" { print $1 }' /etc/shadow | tr '\n' ' ')
sha=$(awk -F: '$2 ~ /^\$[56]\$/ { n++ } END { print n+0 }' /etc/shadow)

echo "libc=$libc usepam=$pam passwordauth=$pw star=[$star] sha_accounts=$sha"
if [ "$libc" = musl ] && [ "$pam" = no ] && [ "$pw" = yes ] \
   && [ -n "$star" ] && [ "$sha" -gt 0 ]; then
  echo "RESULT: 条件が一致。次の版を修正版と照合する"
  apk list -I 'openssh*'
else
  echo "RESULT: いずれかの条件が不一致"
fi

sshd -Tは接続条件を指定しないとMatch節の上書きを反映しません。Matchで特定の接続元だけパスワード認証を許している環境は、後述の-C付きの確認も行います。

動作中のDockerコンテナからsshd入りAlpineを抽出する手順

Alpineの告知のとおり、コンテナでsshdを動かしていなければ対象外です。ベースイメージがAlpineかどうかではなく、sshdが入っているかで絞り込みます。

docker ps --format '{{.ID}} {{.Image}}' | while read -r id image; do
  if docker exec "$id" sh -c 'test -f /etc/alpine-release && command -v sshd' >/dev/null 2>&1; then
    echo "== $image ($id)"
    docker exec "$id" apk list -I 'openssh*'
  fi
done

コンテナの中で更新しても、作り直せば元に戻ります。見つかったイメージは、Dockerfileのベースを上げたうえでの再ビルドが必要です。継続して検出するなら、TrivyのイメージスキャンをCIに組み込んでおくと、次の同種の問題にも間に合います。

tiny-cloud版の公式イメージで確認する既定のalpineユーザー

クラウドで使う公式イメージには別の注意点があります。Alpineの告知によると、3.18.11から3.24.3までのtiny-cloudイメージには、パスワードなしのalpineユーザーが存在し、doasをパスワードなしで実行できます。

コンソール用のパスワードやユーザーデータで$6$のハッシュが設定されると、5番目の条件が満たされて悪用できる状態になります。発見者が「実質的にroot」と書いているのはこの経路です。修正済みのイメージを使うには、3.21.10、3.22.8、3.23.8、3.24.4以降を選んでください。起動済みのインスタンスは、イメージの版にかかわらずパッケージの更新が必要です。

修正パッケージへの更新とPasswordAuthentication無効化の適用順

更新できるなら更新を優先します。回避策は、停止の調整が付くまでのつなぎです。

サポート中のAlpine 3.21〜3.24とedgeの修正版と再起動

Alpineは新しい番号に上げず、手元の版へ修正を移植しています。ssh -Vの数字が10.6p2でなくても修正済みの場合があるので、次のパッケージ版と照合します。

apk update
apk upgrade
sshd -t && rc-service sshd restart

更新だけでは動作中のsshdは置き換わりません。再起動までが作業です。サポートが終わった3.16から3.20の修正版、ソースからの更新、Windowsやほかのディストリの手順はOpenSSHの最新バージョンの確認方法とアップデート手順にまとめています。

更新できないsshdでMatch節まで確かめる回避策の適用確認

oss-securityの告知が示す回避策は、パスワード認証の停止です。先に別の端末から鍵でログインできることを確かめ、確認が終わるまで今のセッションは閉じないでください。

echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i '^passwordauthentication'
sshd -T -C user=alpine,host=bastion,addr=203.0.113.10 | grep -i '^passwordauthentication'

Alpineの告知によると、sshd_config.dを既定で読み込むのは3.19以降です。それより古い環境ではsshd_config本体を書き換えます。最後の行は、Match節があるときに接続元ごとの実効値を見るものです。利用者名と接続元の値は自社の環境に置き換えます。

侵害の有無を判断するログ照合と痕跡を否定できないときの初動手順

Alpineでは、rootの表記が変わった2022年の3.16以降、この穴が開いたままでした。更新で塞いでも、過去に入られていないことの証明にはなりません。

Accepted passwordと「*」のアカウントを突き合わせる照合

パスワードを持たないアカウントにパスワード認証の成功記録があれば、それ自体が異常です。Alpineの告知は/var/log/messagesの確認を挙げています。

awk -F: '$2 == "*" { print $1 }' /etc/shadow > /tmp/star.txt
grep 'Accepted password for' /var/log/messages | grep -F -w -f /tmp/star.txt
find /root /home -name authorized_keys -mtime -10 -exec ls -l {} \;

ヒットがあった場合は、doasの使用履歴、新規ユーザー、authorized_keysの変更も確かめます。ログの追い方全般は不正アクセスの調べ方にコマンド例があります。

ログが残らないコンテナと痕跡を否定できない場合に選ぶ再構築の判断

コンテナでは/var/log/messages自体が無いことが多く、ヒットがゼロでも安全の根拠になりません。ログの保持期間より前の接続も判断できません。Alpineの告知は、侵害を否定できなければ侵害されたものとして扱うよう勧めています。

具体的には、次の順で進めます。修正済みのイメージからサーバーを作り直す。サーバーに置いていた秘密鍵やAPIトークンを交換する。接続先のシステムの操作ログを確認する。個人データに触れる権限があったサーバーなら、個人情報保護委員会への報告義務の期限が動き出すかどうかも同時に判断します。奪われた認証情報がAPI経由で使われる場合の備えはAPI不正アクセス対策の実装手順が参考になります。

sshole以外のOpenSSH脆弱性を2023年以降の対象版で照合する一覧

「OpenSSH 脆弱性」で調べる場合、スキャナの結果を手にしていることも多いはずです。今回の番号以外も、対象版と確認の仕方を押さえておきます。

OpenSSH公式の履歴とリリースノートで確かめた対象版と修正版の対応表

公式のセキュリティ履歴とリリースノートから、サーバー側を中心に主なものを抜き出しました。

優先度が高いのはregreSSHion（CVE-2024-6387）です。Qualysの報告によると、glibcのLinuxで認証なしにrootでコードを実行される可能性がある競合状態で、検証環境の32ビット機では成功まで平均6〜8時間を要しました。公式の履歴は2025年4月が最新の項目だったため、10.4以降の修正はリリースノートで確かめます。

スキャナが版番号で出す検出とDebian・Ubuntuの判定の読み方

バナーの版番号で判定するスキャナは、配布元が修正を移植した版を未修正と誤って報告します。逆に、番号が新しくても設定次第では条件を満たす場合があるため、確認が必要です。CVEごとに、配布元の判定で裏を取ります。

今回の番号は判定の読み違いが起きやすい例です。Debianのトラッカーはbookwormとtrixieをvulnerableと表示しながら、緊急度はunimportantです。Ubuntuのページは優先度High、状態はNeeds evaluationですが、Notesにはmuslを既定で使っていないため影響しないはずとあります。優先度の理由はKEV掲載で、自社の環境に当たるという意味ではありません。

検出結果を報告書に載せるときは、番号、配布元の状態、6条件のどれが欠けているかの3点を書き添えます。後から監査で問われても説明がつくからです。

sshdのパスワード認証を残してよい条件と今回は緊急対応を見送る環境

限られた時間で動くために、対応の線引きを先に決めます。

当日に更新を実行するAlpine環境と再起動を待てない踏み台の扱い

インターネットから到達できるAlpineのsshdで6条件がそろうなら、当日に更新します。例外は設けません。定例のメンテナンス枠まで待つ判断は、KEV掲載後の現在は成り立たないと考えます。

再起動できない踏み台サーバーには、回避策を先に入れて接続元を絞ります。sshdの再起動は既存のセッションを切らないのが通常の動きですが、切れた場合に備えて別の経路を確保してから作業してください。

glibc環境で今回のCVEを理由に緊急メンテナンスを組まない判断

Debian、Ubuntu、RHEL系の標準パッケージだけで構成しているなら、今回の番号での緊急対応は見送ります。条件の1番目で外れるからです。通常のパッチ適用の周期で更新すれば足ります。

見送ってはいけないのは、同じ社内にAlpineベースのコンテナや組み込み機器が混ざっている場合です。サーバーのOS台帳だけで「当社は対象なし」と結論づけるのが、もっともありがちな失敗です。前述の抽出手順でコンテナまで確かめてから判断します。更新の優先度づけを定例化するなら、パッチ管理の手順が使えます。

鍵認証へ一本化した後も残るsshdのインターネット公開の見直し条件

今回の件は、パスワードでのログインが不要な環境にPasswordAuthentication yesが残っていたことが攻撃面になりました。利用者がすべて鍵で入っているなら、更新後もnoのままにします。パスワード認証を残してよいのは、閉じたネットワーク内で、鍵の配布手段がなく、かつglibcとPAMで動く環境に限られます。

sshdをインターネットへ直接公開し続ける理由がないなら、接続元の制限か踏み台への集約まで進めます。SSHの安全な運用設定と併せて見直してください。外部からの診断で穴を洗い出したい場合は、上記の脆弱性診断の対象にsshdの設定確認も含められます。

OpenSSHの脆弱性についてよくある質問と該当判定の迷いどころ

2026年11月10日時点の一次情報で答えられる範囲をまとめました。

Ubuntuのsshdはsshole（CVE-2026-123158）の対象ですか？

標準パッケージのsshdは条件から外れます。Ubuntuの公式ページのNotesにもあるのは、muslを既定で使っていないため影響しないはずという記載です。ページ上の状態はNeeds evaluationのままなので、スキャナの検出が消えないことがあります。Ubuntu上でも、Alpineベースのコンテナの中でsshdを動かしていれば、そちらは対象になり得ます。

ssh -Vの番号が10.6p2未満なら未修正ですか？

未修正とは限りません。Alpineは手元の版へ修正を移植しているため、3.24の修正版は10.3_p1-r2です。apk list -I 'openssh*'で出るリビジョンまで含めて修正版と照合してください。上流のソースから自分でビルドしたsshdだけは、10.6p2以上かどうかで判断できます。

鍵認証だけで運用していれば影響はありませんか？

利用者が鍵で入っていることと、sshdがパスワード認証を拒否することは別の話です。PasswordAuthenticationが既定のyesのままで、鍵しか持たないアカウントのパスワード欄が*なら、そのアカウントがまさに標的になります。sshd -Tの実効値がnoになっていれば対象外です。

Fail2banで今回の攻撃は防げますか？

防げません。NVDの説明のとおり、条件がそろえば長さの範囲内の任意のパスワードで認証が通るため、総当たりのように何度も失敗する必要がないからです。Fail2banが遮断の根拠にする認証失敗の記録が、ほとんど発生しないまま侵入されます。総当たり対策としての価値は別にあるので、更新とは切り分けて考えます。

公開された検証コードで自社のサーバーを試してよいですか？

本番では実行しないでください。公開された検証コードの中身は保証されていません。悪意のある処理が混ざっていても、気づくのは実行した後です。判定はこの記事のスクリプトのように、設定とアカウントの形を見る方法で十分に行えます。動作の確認が必要なら、外部から隔離した検証環境に限り、中身を読んでから扱います。

関連記事

• OpenSSHとは？最新バージョン10.6p2の確認方法とアップデート手順【2026年11月】：版の確認と各OSでの更新手順はこちらで詳しく扱っています。
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：サーバーから漏れた認証情報の失効を組むときの手順です。
• SSH接続とは？仕組み・公開鍵認証・ポート22から安全な運用設定まで実装者向けに解説：鍵認証への移行と設定の基本を確認できます。
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順：KEVを使った更新の優先度づけを定例化する方法です。
• 不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例：sshd以外のログまで調査を広げるときに使えます。