OpenSSH は 11 月 5 日に 10.6p2 を公開し、パスワード認証を迂回できる脆弱性 CVE-2026-123158（発見者は sshole と呼んでおり、CVSS は 8.1）を修正しました。11 月 9 日には、米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が、実際に悪用されている証拠があるとして、これを「既知の悪用された脆弱性」（KEV）カタログに追加しました。影響を受けるのは、C ライブラリに musl を使い PAM を使わない Linux システムだけで、Alpine がその代表例です。Ubuntu のセキュリティページは openssh をすべてのリリースで「Not affected」（影響なし）とし、Debian は緊急度を unimportant（重要でない）と評価しているため、Ubuntu や Debian で動いている VPS は、この脆弱性について何もする必要はありません。確認が必要なのは、Alpine のシステムと、Alpine コンテナの中に自分でインストールした sshd です。OpenSSH の前回の変更については、10 月の記事を参照してください。
4 つの条件がすべてそろった場合にのみ成立
- PAM なしでビルドされている Alpine の openssh-server パッケージを使っているか、openssh-server-pam を
UsePAM noで使っていること。 PasswordAuthenticationが yes であること。これは OpenSSH の既定値なので、変更していなければ有効になっています。- パスワード欄が
*のアカウント、つまりパスワードを持たず鍵だけでログインする想定のアカウントがマシンにあること。Alpine のベースイメージは 3.16 ごろから root をroot:*として出荷しており、公式の tiny-cloud イメージの alpine ユーザーも同じで、しかもパスワードなしの doas で root になれます。root 自体は既定のPermitRootLogin prohibit-passwordで守られていますが、別のアカウントが root になれるのであれば、それだけでは不十分です。 - マシン上の別のアカウントの少なくとも 1 つが、
$5$または$6$で始まる本物のパスワードハッシュを持っていること。4 つがすべてそろうと、アカウント名を知っている攻撃者は 257〜1024 バイトの非常に長いパスワード（NVD の表現では 256〜1024 文字）を送るだけで、最初の接続でログインできてしまいます。原因は、パスワードが 256 バイトを超えると musl の crypt() がエラーの目印として*を返すことにあります。*はまさにそれらのアカウントに保存されている値なので、sshd は一致したと判断してしまいます。
影響を受けないもの
- sshd を動かしていないコンテナ。Docker コンテナの大多数がこれに当たります。
- すでに
PasswordAuthentication noを設定しているシステム。cloud-init で構成されるクラウドイメージは、この行を書き込みます。openssh-server-pam をUsePAM yesで使っているシステムも影響を受けません。 - 発見者は musl ベースのシステムとして OpenWrt、Buildroot、Yocto も挙げています。これらが問題になるのは OpenSSH の sshd をインストールしている場合だけで、修正は各プロジェクト自身の更新で提供されます。
修正方法
- アップグレードしてから sshd を再起動します。
apk upgrade -U -aを実行し、続けてrc-service sshd restartを実行してください。パッケージをアップグレードしても、動作中の sshd は再起動されません。修正済みパッケージは Alpine 3.21.10、3.22.8、3.23.8、3.24.4 に含まれています。パッケージのバージョンは、3.24 が10.3_p1-r2、3.23 が10.2_p1-r1、3.22 が10.0_p1-r11、3.21 が9.9_p2-r1、edge が10.6_p2-r0で、3.16 までさかのぼる古いブランチにも修正が公開されています。 - まだアップグレードできない場合は、パスワードログインを無効にします。sshd の設定で
PasswordAuthentication noを設定して sshd を再起動し、sshd -T | grep -i passwordauthenticationの出力が no であることを確認してください。その前に鍵でのログインができることを確かめ、現在のセッションは開いたままにしておきましょう。 - Alpine イメージに openssh-server をインストールする Dockerfile を書いている場合は、新しいベースイメージを取得して再ビルドし、コンテナを再起動してください。ホスト側をアップグレードしても、コンテナには何の効果もありません。
誰かにログインされたかどうかの見分け方
Alpine は、/var/log/messages で Accepted password for と書かれた sshd の行を探すよう案内しています。パスワードを持たないアカウント（alpine、root、鍵のみのユーザー）でパスワードログインが成功していれば、この脆弱性が使われたことを意味します。そのうえで doas の使用状況、新しく作られたユーザー、authorized_keys を確認し、ログインされた可能性を否定できない場合は、マシンが侵害されたものとして扱い、侵入チェックと強化のガイドに従ってください。BleepingComputer は 11 月 9 日、GreyNoise が最初の悪用成功を 11 月 7 日 00:46 UTC に記録したと報じました。修正の公開から約 40 時間後のことです。侵入後、攻撃者はシステムとコンテナの偵察を行い、クラウドのメタデータサービスに問い合わせ、パスワードハッシュと root の SSH 鍵を読み取ろうとし、アクセスを維持するために authorized_keys を書き換えていました。コンテナの基本はDocker 入門を参照してください。どのディストリビューションでも、SSH を鍵のみのログインにしておくことが最も手間を省ける設定で、これはufw ファイアウォールと SSH 鍵ログインで説明しています。