CVE-2026-123158 OpenSSH｜musl 環境の認証回避と対策

はじめに

2026 年 11 月 5 日、OpenSSH 開発チームは Portable OpenSSH 10.6p2 を公開し、一部の Linux 環境で sshd のパスワード認証を回避できる問題への回避策を提供しました。同日、Alpine Linux も修正済みパッケージとセキュリティ告知を公開しています。この問題には CVE-2026-123158 が割り当てられています。

「OpenSSH の認証バイパス」と聞くと、すべての Linux サーバーや SSH 踏み台サーバーが対象に見えます。しかし実際に影響を受けるのは、musl libc を使い、PAM を介さずに sshd がパスワードを検証する環境で、さらにアカウントの状態など複数の条件が重なった場合に限られます。一方で、Alpine Linux の標準パッケージや公式クラウドイメージは条件に当てはまりやすく、パッケージを更新しただけでは稼働中の sshd に修正が反映されない点にも注意が必要です。

結論として、OpenSSH を使っていてもすべての環境が対象になるわけではありません。「musl libc」「PAM を使わないパスワード検証」「PasswordAuthentication yes」「パスワード欄が * のアカウントと、$5$ / $6$ 形式のハッシュを持つ別アカウントの共存」が重なった場合に成立します。該当する場合は、ディストリビューションの修正パッケージを適用し、sshd を再起動するところまでを 1 つの作業として実施してください。

CVE-2026-123158 の概要と認証バイパスの仕組み

CVE-2026-123158 は、musl libc を使う Linux 上の sshd が PAM を使わずにパスワードを検証する場合に、パスワードが設定されていないアカウントへログインできてしまう問題です。主な情報は次のとおりです。

なお、OpenSSH のリリースノートと Alpine Linux の初報には CVE 番号が記載されておらず、Alpine Linux の告知でも執筆時点では未割り当てと説明されています。CVE 番号で情報を探す場合は、両者の告知と CVE Record を突き合わせ、CVSS 値も CVE Record の最新の記載で確認してください。

musl の crypt() と PAM 無効の組み合わせで起きる仕組み

PAM を使わない sshd は、入力されたパスワードを C ライブラリの crypt() でハッシュ化し、/etc/shadow のパスワード欄と比較して認証します。パスワード欄が * のようにソルト（ハッシュの先頭に付くランダムな値）を含まない短い値の場合、sshd は別のアカウントのハッシュからソルトを借用して処理を続けます。これは、応答時間からユーザー名の存在を推測されないようにするため、2016 年に OpenSSH へ加えられた変更に由来します。

一方、musl の crypt() は、$5$（SHA-256）/ $6$（SHA-512）方式で 256 バイトを超えるパスワードを受け取ると、エラーを示す値として文字列 * を返します。この戻り値が、パスワード未設定アカウントの欄に保存されている * と一致するため、sshd が認証成功と判定してしまいます。

個々の動作はそれぞれの設計に沿ったものですが、組み合わさることで認証を回避できる状態になります。OpenSSH 10.6p2 に含まれる上流の修正コミットでは、パスワード認証の判定処理に、保存されているパスワード欄が 4 文字未満の場合は一致しても認証成功としない条件が追加されています。

参考: OpenSSH 10.6p2 リリースノート
“We consider the root cause of this bug to be outside sshd”
（このバグの根本原因は sshd の外にあると考えている）
https://www.openssh.org/txt/release-10.6p2

OpenSSH 開発チームは根本原因が sshd の外にあるとの見解を示しており、musl のメンテナーも musl の脆弱性ではないとの立場を示していると報じられています。本記事では根本原因の所在には立ち入らず、運用者が取るべき対応に焦点を当てます。

パスワード欄の「*」と「!」の違い

影響判定で最も取り違えやすいのが、/etc/shadow のパスワード欄の値です。

*（パスワード未設定）

パスワードが設定されていない状態です。鍵認証専用ユーザーや、Alpine 3.16 頃以降のベースイメージの root が該当します。今回の問題では、このアカウントが認証バイパスの対象になり得ます。

!（ロック済み）

Alpine Linux の告知では、パスワード欄が ! のロック済みアカウントは影響を受けないと説明されています。ロック済みアカウントは、パスワードでも鍵でもログインできません。

$5$ / $6$ で始まる値

SHA-256 / SHA-512 方式のパスワードハッシュです。このハッシュを持つアカウントが 1 つでも存在すると、パスワード欄が * のアカウントすべてが対象になり得ます。

* と ! はどちらも「パスワードでログインできない」状態に見えますが、今回の問題での扱いは異なります。また、Alpine Linux の告知では、musl-nscd を経由してディレクトリサービスから提供されるユーザー（/etc/shadow に項目がないユーザー）も対象に含まれると説明されています。

影響を受ける環境と受けない環境

影響の有無は、OpenSSH を使っているかどうかではなく、「libc の種類」「PAM の使用」「認証設定」「アカウントの状態」「到達性」の組み合わせで決まります。

Alpine Linux で認証バイパスが成立する条件

Alpine Linux の告知では、次の 1〜4 のすべてに当てはまる場合に影響を受けるとしています。ここでは、攻撃者側の前提である 5 のネットワーク到達性も加えて整理します。

1. PAM を使わない openssh-server を使用している、または openssh-server-pam を UsePAM no で使用している。
2. PasswordAuthentication が yes になっている（OpenSSH の既定値）。
3. パスワード欄が * のアカウントが存在する。
4. 別のローカルアカウントに $5$ または $6$ 形式のパスワードハッシュが存在する。
5. 攻撃者が SSH ポートへネットワーク経由で接続できる。

攻撃者は対象アカウントの名前を知っている必要がありますが、root や alpine のように推測しやすい名前のアカウントも条件に当てはまり得ます。Alpine Linux の告知では、1 回の接続で毎回成立し、再試行も不要と説明されています。

root ログインの禁止だけでは防げない理由

OpenSSH の既定値 PermitRootLogin prohibit-password では、root へのパスワードログインは拒否されます。そのため、root そのものが狙われるのは PermitRootLogin yes を設定している場合に限られます。

ただし、root 以外のユーザーが侵入され、そのユーザーが doas などで root 権限を取得できる場合は、root のログイン制限は防御になりません。後述する tiny-cloud イメージの alpine ユーザーは、この典型例です。

OpenWrt の Dropbear と OpenSSH の区別

OpenWrt は標準の SSH サーバーとして Dropbear を使います。今回の問題は OpenSSH の sshd で成立するものであり、Dropbear へそのまま当てはめることはできません。Dropbear が影響を受けないことは、Alpine Linux のメンテナーや musl のメンテナーによる確認として報じられています。

一方、Dropbear を OpenSSH サーバーへ置き換えている場合は確認が必要です。OpenWrt のパッケージフィードには、PAM なしの openssh-server と PAM 対応の openssh-server-pam があります。OpenWrt は musl libc を採用しているため、openssh-server でパスワード認証を許可していれば、Alpine Linux と同じ条件を満たし得ます。

修正については、OpenWrt 公式の packages フィードに 2026 年 11 月 5 日付で次の修正コミットが取り込まれています。

ただし、これはソースコードへの修正の取り込みであり、各アーキテクチャ向けの修正済みパッケージがビルドされ、配布されたことまでは確認できていません。opkg などで更新できるパッケージのバージョンとリリース番号が、上記の修正を含むものかを確認できるまでは、後述するパスワード認証の無効化で対処することをおすすめします。また、報告者は musl を採用した Buildroot や Yocto ベースの機器も確認対象に挙げているため、該当する機器では機器ベンダーの告知を確認してください。

Alpine Linux の修正版とクラウドイメージへの影響

Alpine Linux は、サポート中の系列に加えて、通常サポートを終えた 3.16〜3.21 にも修正パッケージを公開しています。系列ごとの修正版は次のとおりです。表の版数以上であれば修正済みです。

同日に公開されたポイントリリース 3.21.10、3.22.8、3.23.8、3.24.4 には、修正済みパッケージが含まれています（Alpine Linux のリリース告知）。通常サポートの期限は Alpine Linux のリリース一覧で確認できます。

OpenSSH 10.6p2 未満でも修正済みになるケース

OpenSSH 10.6p2 へ更新しなければ対処できない、という意味ではありません。Alpine Linux の安定版系列は、元の OpenSSH バージョンを維持したまま、同じ問題への修正をバックポートしています。たとえば 3.24 の修正版は 10.3_p1-r2 であり、OpenSSH としての表示バージョンは 10.3p1 のままです。

そのため、sshd -V の表示だけでは修正済みかどうかを判断できません。パッケージの提供元、OS のリリース系列、パッケージリビジョン（-r に続く数字）まで確認し、上の表と比較してください。反対に、自前でビルドした OpenSSH や、ディストリビューション以外から入手したバイナリは、10.6p2 以降であるか、または当該の修正コミットが取り込まれていることを確認して判断します。

また、sshd -V が示すのは、そのコマンドで実行したディスク上のバイナリの情報です。複数の sshd が導入されている場合や、更新後に再起動していない場合は、サービスとして稼働している sshd と一致するとは限りません。稼働中のプロセスの確認方法は、後述の確認手順 2 で説明します。

サポート終了系列への修正提供の扱い

3.16〜3.21 への修正提供は今回の問題に限った対応であり、該当系列の通常サポートが延長されたことを意味しません。修正パッケージを適用したうえで、サポート中の系列への移行計画を進めることをおすすめします。また、3.15 以前の系列は、Alpine Linux の告知の修正版一覧に掲載されていません。これらの系列で修正済みパッケージが提供されているかは個別に確認し、確認できない場合は、パスワード認証の無効化と系列の移行を検討してください。

tiny-cloud イメージで注意すべき点

Alpine Linux 公式の tiny-cloud イメージ（qcow2、VHD、AMI）のうち 3.18.11〜3.24.3 では、パスワード欄が * の alpine ユーザーが作成され、パスワードなしの doas が許可されています。

初回起動の時点では $6$ 形式のハッシュを持つアカウントが存在しないため、この状態だけでは攻撃は成立しません。しかし、管理者がコンソール用にパスワードを設定した場合や、ユーザーデータで hashed_passwd を持つユーザーを追加した場合など、$6$ 形式のハッシュが 1 つでも作成されると条件を満たします。この場合、攻撃者は alpine ユーザーとしてログインし、doas で root 権限を取得できます。

誤解: 公式クラウドイメージだから安全

tiny-cloud イメージの 3.18.11〜3.24.3 は、運用中の変更次第で条件を満たします。公式イメージであることは、影響がないことの根拠になりません。

誤解: 初回起動時に問題がなければ以後も安全

後からいずれかのアカウントにパスワードを設定すると、その時点でパスワード欄が * のアカウントが対象になり得ます。

誤解: 新しいイメージに切り替えれば既存インスタンスも直る

3.21.10、3.22.8、3.23.8、3.24.4 以降から作成したイメージには修正済みパッケージが含まれます。それ以前のイメージから起動した稼働中のインスタンスは、個別に openssh を更新するか、パスワード認証を無効にする必要があります。

コンテナでの考え方

コンテナ内で sshd が動いていなければ、今回の sshd 経由の攻撃対象にはなりません。Alpine Linux ベースのイメージを使っていること自体は、影響の有無を決める条件ではありません。

一方、コンテナ内で sshd を動かしている場合は、仮想マシンと同じ条件で判定します。修正済みパッケージを含めてイメージを再ビルドし、稼働中のコンテナを置き換えてください。稼働中のコンテナ内で apk upgrade を実行しても、元のイメージは更新されないため、コンテナを再作成すると修正前の状態に戻ります。

自分の環境が影響を受けるか確認する方法

次の 8 段階で確認します。コマンドは Alpine Linux を前提とし、root で実行します。アカウントの確認では、/etc/shadow のパスワードハッシュを画面に表示しない方法を使います。

本記事のコマンドは、Alpine Linux の告知と OpenSSH のマニュアルなどの公式資料に基づいて記載したもので、筆者の環境での実行検証は行っていません。本番環境で実行する前に、検証環境で出力を確認することをおすすめします。

ps | grep -E '[s]shd|[d]ropbear'

sshd -V
command -v sshd
apk info -v | grep '^openssh'

ls -l /proc/$(cat /var/run/sshd.pid)/exe

cat /etc/os-release
ldd "$(command -v sshd)"

apk info -e openssh-server openssh-server-pam

sshd -T | grep -i usepam

sshd -T | grep -i passwordauthentication

sshd -T -C user=alpine,host=client.example.com,addr=203.0.113.10 | grep -i passwordauthentication

awk -F: '$2=="*"{print $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

sshd -T | grep -iE '^(port|listenaddress) '

確認結果に応じた判断の目安は次のとおりです。

安全な更新と暫定対策

更新作業では、管理経路を失わないことを優先します。また、Alpine Linux の告知が強調しているとおり、パッケージを更新しただけでは稼働中の sshd は置き換わりません。

参考: Alpine Linux Security advisory
“Upgrading the package alone does not replace the running daemon.”
（パッケージの更新だけでは、稼働中のデーモンは置き換わらない）
https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/

Alpine Linux で修正パッケージを適用する手順

ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no admin@server.example.com

cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +%Y%m%d)
cp -a /etc/ssh/sshd_config.d /etc/ssh/sshd_config.d.$(date +%Y%m%d)

apk upgrade -U -a

sshd -t

rc-service sshd restart

rc-service sshd status
sshd -T | grep -i passwordauthentication
grep sshd /var/log/messages | tail -n 20

更新できない場合の暫定対策

修正パッケージをすぐに適用できない場合は、鍵認証へ移行したうえで PasswordAuthentication no を設定します。Alpine Linux の告知と OpenSSH 開発チームは、いずれもこの設定で今回の問題を回避できると説明しています。

鍵認証でログインできることを確認する前にパスワード認証を停止すると、管理者自身がログインできなくなるおそれがあります。前節の手順 1〜4 を先に済ませてください。

設定の前に、読み込み規則を確認しておきます。sshd_config(5) では、各キーワードについて最初に得られた値が使われます。そのため、ファイルの後半に PasswordAuthentication no を追記しても、前半に yes があれば反映されません。また、Match ブロック内の PasswordAuthentication yes は、条件に該当する接続に適用されます。まず、関連する行を洗い出します。

grep -n -iE '^[[:space:]]*(include|match|passwordauthentication)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

Alpine Linux 3.19 以降の標準の sshd_config は、/etc/ssh/sshd_config.d/ 配下の drop-in ファイルを読み込みます。この場合は、次のように drop-in ファイルを作成します。

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf

3.19 より前の系列の標準設定は、このディレクトリを読み込みません。drop-in ファイルを作成しても反映されないため、/etc/ssh/sshd_config を直接編集し、既存の PasswordAuthentication 行をすべて no に変更します。該当行がない場合は、ファイルの先頭付近に PasswordAuthentication no を追加します。どの系列でも、Match ブロック内に PasswordAuthentication yes がある場合は、その行も no に変更してください。Alpine Linux の告知には、Match ブロック内の行も含めて一括で変更するコマンドが掲載されています。

設定後は検証してから再起動し、実効値を確認します。

sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

passwordauthentication no が表示されることを確認し、Match を使っている場合は前章の -C による確認も行ってください。元に戻す場合は、作成した drop-in ファイルを削除するか、バックアップした設定ファイルを戻して sshd を再起動します。

あわせて、SSH ポートへの接続元をファイアウォールやセキュリティグループで管理用ネットワークに限定すると、攻撃を受ける範囲を狭められます。OpenSSH 開発チームは、対応できるまで該当システムの SSH を停止することも選択肢として挙げています。

自前でビルドした OpenSSH を使っている場合は、10.6p2 以降でビルドし直すか、同じ暫定対策を適用してください。ディストリビューションのパッケージと自前ビルドが混在していないか、command -v sshd の結果とあわせて確認しておくと、更新漏れを防げます。

侵害の兆候と確認ポイント

影響条件を満たしていた期間がある場合は、修正後に侵害の有無も確認します。Alpine Linux の告知では、パスワードが設定されていないアカウントに対する Accepted password for のログを確認するよう案内しています。

grep 'Accepted password for' /var/log/messages

ユーザー名が表示された場合は、そのアカウントのパスワード欄が * かどうかを、ハッシュを表示せずに確認します。alpine の部分は、確認したいユーザー名に置き換えてください。

awk -F: '$1=="alpine"{print ($2=="*") ? "password-field: *" : "password-field: other"}' /etc/shadow

パスワード欄が * のアカウントでパスワード認証が成功している場合、本来は起こらないログインです。次の点もあわせて確認します。

• 鍵認証専用ユーザー、root、alpine などに対するパスワード認証の成功
• 想定していないユーザー名や接続元 IP アドレスからのログイン
• doas の使用履歴（syslog に記録される構成の場合）
• /etc/passwd や /etc/group への不審なユーザー・グループの追加
• 各ユーザーの ~/.ssh/authorized_keys の追加・変更
• 一時ディレクトリや各ユーザーのホームディレクトリに作成された不審なファイル

authorized_keys の変更は、たとえば最近 14 日以内に更新されたファイルを次のように洗い出せます。期間は、影響条件を満たしていた期間に合わせて調整してください。

find /root /home -name authorized_keys -mtime -14 -exec ls -l {} \;

ログが見つからないことは、侵害がなかったことの証明にはなりません。古いログがローテーションで削除されている場合や、侵入者がログを改ざんした場合は、痕跡が残らない可能性があります。ログを外部へ転送している場合は、転送先のログもあわせて確認してください。

反対に、Accepted password for のログがあるだけで侵害と断定することもできません。正規にパスワードを設定しているユーザーのログインも同じ形式で記録されるためです。アカウントの状態と照合し、ログインを否定できない場合は、Alpine Linux の告知のとおり侵害されたものとして扱い、認証情報の更新やシステムの再構築を検討してください。

実悪用の有無は、2026 年 11 月 6 日時点で公式情報からは確認できていません。OpenSSH のリリースノートと Alpine Linux の告知（いずれも 2026 年 11 月 5 日公開）には実悪用に関する記載がなく、CISA の KEV カタログへの登録状況も確認できていません。参考として、The Hacker News の 2026 年 11 月 5 日付の記事では、攻撃は報告されていないと伝えられています。一方で、再現環境が公開されていることも報じられているため、最新の状況は CISA の KEV カタログや各ベンダーの告知で確認してください。

まとめ

CVE-2026-123158 は、OpenSSH 全般の問題ではなく、musl libc と PAM を使わないパスワード検証の組み合わせで成立する認証バイパスです。影響判定ではアカウントの状態まで確認し、該当する場合は修正パッケージの適用と sshd の再起動を一続きの作業として実施することが重要です。

• 対象は musl libc かつ PAM なしでパスワードを検証する sshd です。
• glibc 系ディストリビューションや PAM 有効の環境は対象外です。
• パスワード欄が * のアカウントと $5$ / $6$ のハッシュの共存が条件です。
• ! でロックしたアカウントは Alpine の告知で対象外とされています。
• 修正判定はバージョン表示ではなくパッケージのリビジョンで行います。
• Alpine ではパッケージ更新後に sshd の再起動が必要です。
• 更新できない場合は鍵認証を確認してからパスワード認証を無効にします。

以上、最後までお読みいただきありがとうございました。