要点
- 特定の Linux では、SSH（サーバーに遠くからログインする仕組み）で、正しいパスワードを知らなくてもログインできてしまう欠陥が見つかった。
- 当たるのは主に Alpine Linux のように「musl」という部品で作られ、PAM（ログインの確認をまとめて受け持つ仕組み）を使わない環境で、ふつうの Ubuntu や Red Hat 系のサーバーは対象外とされる。
- OpenSSH 10.6p2 と Alpine の更新で直っている。悪用されたかどうかは一次情報に書かれていないが、当たる環境では管理者の権限まで取られうる。
何が起きたか
OpenSSH の開発チームは 2026年11月5日、OpenSSH 10.6p2 を公開した。リリースノートによると、この版は、パスワードの確認を飛ばせてしまう欠陥を避けるためのものだ。当たるのは、PAM を外して作り、そのまま動かしている一部の Linux である。
リリースノートには、報告者として Wakefield の Özgün Kültekin 氏の名前が載っている。この欠陥には「*sshole」という名前の解説ページもあり、こちらも 10.6p2 で直ると書いている。
Alpine の advisory（安全についてのお知らせ）と解説ページは、2つの動きが重なって起きると説明している。1つは musl の側だ。musl は 256 バイトを超える長いパスワードを処理できないとき、失敗の印として「」という1文字を返す。ところが Linux では、パスワードでのログインを許さないアカウントの欄にも、同じ「」が書かれている。もう1つは sshd（SSH のサーバー側のプログラム）の側だ。解説ページによると、sshd は本物のパスワードを持たないアカウントでも、ほかのアカウントの「salt」（パスワードを暗号のような形に変えるときの材料）を借りて確認の計算をする。この2つが重なると、「*」のアカウントに長いパスワードを送ったとき、確認を通ってしまう。
10.6p2 は、sshd の側でこの穴をふさぐ版だ。リリースノートは、根の原因を「outside sshd」（sshd の外）と見ている。
Alpine の advisory によると、当たるには条件がいくつも重なる必要がある。sshd がパスワードでのログインを受け付けていて、その確認に PAM を通していないこと。そのうえで、同じ機械に、パスワード欄が「*」のアカウントと、本物のパスワードを持つアカウントが両方あることだ。
advisory がとくに注意を促しているのは、Alpine の公式のクラウド用イメージ（仮想マシンを作るための型）のうち、3.18.11〜3.24.3 の版だ。これらには初めから「alpine」というユーザーが入っている。このユーザーは、パスワードを聞かれないまま管理者の操作ができる設定だ。しかも、そのパスワード欄は「*」になっている。advisory は、こうした機械で条件がそろうと、管理者の権限まで奪われうるとしている。
CVE（欠陥の通し番号）は、advisory を書いた時点でまだ付いていない。実際に悪用されたかどうかは、どの一次情報にも書かれていない。
日本の利用者への影響
報告者の解説ページは、Debian、Ubuntu、Fedora のような glibc という部品で作られた Linux、PAM を通す環境、それに OpenBSD では、この欠陥は起きないとしている。ふつうの Linux サーバーがそのまま当たる、という話ではない。
気をつけたいのは Alpine Linux だ。解説ページは、多くの Docker のイメージ（アプリを小分けに動かす箱の元になる型）も musl の Linux だと書いている。ただし advisory は、sshd を動かさずにコンテナとして使うだけなら当たらないとしている。危ないのは、Alpine をクラウドの仮想マシンや小さな機器で動かし、SSH を外に開けている場合だ。解説ページは、ほかに musl を使う組み込み機器向けの OS（OpenWrt、Buildroot、Yocto）も挙げている。ただし、それらの対応の状況は書かれていない。日本の組織への被害について、一次情報は触れていない。
今すぐやること
- 自分の部署のサーバーや機器に、Alpine Linux など musl で作られたものがあり、SSH を開けていないかを、担当の人に確かめてもらう。
- 当たるなら、Alpine の advisory が勧めるとおり openssh を更新する。advisory は、更新のあとに sshd を立ち上げ直す必要があるとしている。ここを忘れると、古い sshd が動いたままになる。
- 担当の人にログインの記録も見てもらう。パスワードを持たないはずのアカウントで、パスワードでのログインが成功していたら要注意だ。Alpine は、入られた可能性を消せない機械は乗っ取られたものとして扱うよう勧めている。
- 更新がすぐにできない機械では、Alpine の勧めに沿って、パスワードでのログインを止める。止める前に、鍵でログインできることを確かめておく。
背景
根にあるのは、2つの部品が「」という同じ1文字を、別の意味で使っていたことだ。musl にとっては「処理に失敗した」という印で、アカウントの欄では「パスワードでは入れない」という印になる。解説ページによると、musl の「」を返す作りと長いパスワードを断る作りは、どちらも2012年からある。sshd がほかのアカウントの salt を使う作りは2016年に入った。つまり、穴は10年ほど開いたままだったことになる。
当たる範囲が狭いのは、ログインの確認を PAM に任せている環境では、この食い違いが表に出ないからだ（解説ページ）。ところが Alpine の openssh-server は、初めの設定で PAM を使わない。このため Alpine が主に当たることになった。
Alpine では2019年にも、Docker 用の公式イメージで root のパスワードが空になっていた問題（CVE-2019-5021）があった。小さくて便利な土台は、ふつうの Linux と少し違う作りをしていることがあり、こうした食い違いが欠陥につながることがある。
技術者向けの詳細
- 修正: OpenSSH 10.6p2（2026-11-05）。リリースノートでは「musl libc で PAM 無効」の Linux 向けの重要な回避策としている。報告は Özgün Kültekin 氏（Wakefield）、修正は Damien Miller 氏と Darren Tucker 氏。
- 当たらない（解説ページによる）: glibc の Linux（Debian、Ubuntu、Fedora など）、パスワード認証に PAM を使う環境、Dropbear、OpenBSD。
- Alpine の条件:
PasswordAuthentication yesが有効で、PAM を通さない構成（PAM なしで作られたopenssh-server、またはopenssh-server-pamでUsePAM no）。そのうえで、$5$か$6$のハッシュを持つローカルのアカウントと、パスワード欄が*のアカウントが両方ある（!でロックしたアカウントは当たらない）。 - Alpine の修正版（
openssh）:- edge: 10.6_p2-r0
- 3.24: 10.3_p1-r2 / 3.23: 10.2_p1-r1 / 3.22: 10.0_p1-r11
- 3.21: 9.9_p2-r1 / 3.20: 9.7_p1-r6 / 3.19: 9.6_p1-r3
- 3.18: 9.3_p2-r4 / 3.17: 9.1_p1-r7 / 3.16: 9.0_p1-r6
- 確かめ方:
apk info -v openssh openssh-server openssh-server-pam 2>/dev/null
sshd -T | grep -Ei '^(usepam|passwordauthentication) '
awk -F: '$2=="*"{print $1}' /etc/shadow
- 更新:
apk upgrade -U -aのあとrc-service sshd restart。 - 当座の回避:
sshd_config.dの下にPasswordAuthentication noを置いて再起動する。いまのセッションは閉じずに、鍵でログインできるかを試す。バックアップとsshd -Tでの確認を含む手順は、Alpine の advisory にある。 - 調べること:
authorized_keysに覚えのない鍵が増えていないか、新しく作られたユーザーやファイル、doasの使われ方。ログは/var/log/messagesで、パスワードの無いはずのアカウントに「Accepted password for」が出ていないかを見る。 - クラウド用の型: tiny-cloud の qcow2・VHD・AMI のうち 3.18.11〜3.24.3 では、
alpineユーザーの欄が*で、doasにパスワードが要らない。修正済みのパッケージで作り直した型は対象外（advisory）。 - CVE: advisory の時点では未採番。悪用の有無は一次情報に書かれていない。
