packages

OpenSSHの「長いパスワードで入れる」脆弱性、Alpineなどmusl環境のどこが影響を受けるか 11月5日の深夜、「Alpine Linux で257〜1024文字（告知の単位ではバイト）の何かを打てば root が取れる」という投稿が流れてきて、私も一瞬手が止まりました。 ただ、条件を読んでいくと、当てはまる環境はかなり絞られます。 一方で、当てはまる環境では、パスワードを知らなくても1回の接続で入られます。 Alpine は、コンテナ、クラウドの VM、小さな物理機器と、使われる場所が幅広いディストリビューションです。 また、影響は Alpine に限らず、同じ musl libc を使う OpenWrt などにも及びえます。 当初は自前の環境を確かめるために AI を使用し整理したのですが、少し加工すれば記事になりそうだったので、Alpine の使われ方と Alpine 以外の環境に分けて、どこに当てはまるのかを一次情報の範囲で確認したものを共有します。 ! 2026年11月6日時点で、Alpine Linux の告知とダウンロードページ、クラウドイメージのページ、OpenSSH 10.6p2 のリリースノート、oss-security への投稿、Docker Hub、sshd_config(5)、発見者のページ（sshhole.com）、Threat Landscape、Cycode、Check Point、Detectify の解説、NVD、musl のメーリングリスト、sshd(8)、各ディストリビューションの OpenSSH のパッケージ定義と配布フィードを確認した範囲の情報です。 CVE 番号は、Alpine の告知の時点では振られていませんでしたが、その後 CVE-2026-123158 が割り当てられ、NVD が11月5日（UTC）に公開しています（CVSS 3.1 の基本値は 8.1）。 「私の見立てでは」と書いた箇所は、出典のない私の推測です。 ＊マサカリは歓迎します^^;コメントで教えてください。 話題になった投稿 発端の投稿は、2026年11月5日 23:48（日本時間）の International Cyber Digest のものです。 x.com On Alpine Linux, type 257 to 1024 characters of anything and you get root. （Alpine Linux で、257〜1024文字の何かを打つと root が取れる。） 同じ日に Alpine Linux が出した告知を読むと、成り立つにはいくつもの条件が要り、「Alpine を使っていれば誰でも root を取られる」わけではありません。 何が起きるのか（概要） musl libc の crypt() は、256バイトを超えるパスワードを受け取ると、エラーの印として * という文字列を返します。 - は、パスワードを設定していないアカウントの /etc/shadow のパスワード欄に入りうる値と同じです。 PAM を通さない sshd は、パスワードを持たないアカウントでも、別のアカウントのハッシュの先頭（方式とソルト）を借りて crypt() を呼び、結果をパスワード欄と比べます。 そのため、crypt() の結果とパスワード欄が一致したと判断し、ログインを通します。 長さの範囲は、Alpine の告知では257〜1024バイト、NVD の説明では256〜1024文字と書かれています。 OpenSSH は 10.6p2 で sshd の側に回避策を入れ、Alpine は各リリースに修正済みのパッケージを出しています。 musl の側は、musl の不具合ではなく呼び出し側の誤った使い方だという立場です。 Alpine の告知は、影響を受ける条件を次の4つとしています。 PAM を通さない sshd：Alpine の openssh-server パッケージ（PAM なしでビルド）、または openssh-server-pam を UsePAM no で使っている パスワード認証が有効：PasswordAuthentication が yes（OpenSSH の既定値） パスワード欄が * のアカウント：鍵だけで使うアカウントなど、パスワードを設定していないアカウントがある（musl-nscd 経由のディレクトリサービスのユーザーも含む） パスワードを持つ別のアカウント：$5$ か $6$ のハッシュを持つアカウントが1つ以上ある 告知はさらに、攻撃者が SSH のポートに届くことと、パスワード欄が * のアカウントの名前を知っていることを前提にしています。 ! で「ロック」されたアカウントは対象外です。 Check Point は自社の検証で、sshd がソルトを借りる先のアカウントはハッシュを持つだけでは足りず、有効なアカウントである必要があったとしています。 確かめる側は、告知どおり $5$ か $6$ のハッシュがあれば当てはまるものとして扱うのが安全です。 狙われるのは、公開鍵認証方式だけで使っているアカウントです。 「このユーザーはkeyでしか入らないから安全」と考えていても、他ユーザ向けの sshd パスワード認証が有効なままなら、そのアカウントが入口になります。 以下の節では、Alpine の告知を正として、条件を次の3点にまとめて使われ方ごとに当てはめます。 PAM を通さない sshd が動いているか パスワード認証が有効か - のアカウントと、パスワードを持つアカウントが同居しているか（3つ目と4つ目の条件） Alpine が使われている場所 Alpine のダウンロードページでは、用途ごとに複数の版が配られています。 主なものは次のとおりです。 版 ダウンロードページの説明 主な使われ方 Mini root filesystem For use in containers and minimal chroots. コンテナのベースイメージ Standard Alpine as it was intended. Just enough to get you started. 物理サーバー、手で構築する機械 Extended Most common used packages included. Suitable for routers and servers. Runs from RAM. ルーター、自宅や社内の小さなサーバー Virtual Optimized for virtual systems. 手で構築する VM Raspberry Pi First generation Pis including Zero/W (armhf). Pi 2 to Pi 3+ generations (armv7). Pi 3 to Pi 5 generations (aarch64). シングルボードコンピューター Generic U-Boot Includes the U-Boot bootloader. U-Boot で起動する ARM の機器 Xen Use for Xen Dom0. Xen のホスト このほか、クラウド向けのイメージ（AWS、Azure、GCP、Oracle Cloud、NoCloud ほか）が別のページで配られています。 クラウドイメージの初期設定の仕組みは、Tiny Cloud と cloud-init の2種類です。 Docker Hub の公式の alpine イメージは、「only 5 MB in size」をうたう最小のイメージです。 Alpine の使われ方ごとの影響 使われ方ごとに条件を当てはめると、次のようになります。 使われ方 PAM なしの sshd パスワード認証 - とパスワードの同居 判断 公式の Docker イメージを使うコンテナ 入っていない 該当なし 該当なし 影響なし sshd を足したコンテナ（CI ランナー、開発用コンテナ、踏み台） 動いている イメージの作り方次第 イメージの作り方次第 条件がそろえば影響あり クラウドイメージ（cloud-init） 動いている 既定は no パスワード認証が no のため判断に関係しない 既定のままなら影響なし クラウドイメージ（Tiny Cloud、3.18.11〜3.24.3。11月6日時点で配られている公式イメージはすべてこの範囲） 動いている 有効 パスワードを1つ設定すると同居する 運用の途中で影響ありになる 手で構築した VM、物理サーバー、Raspberry Pi 入れていれば動いている 既定は有効 鍵だけのユーザーをどう作ったか次第 条件がそろえば影響あり 行ごとの補足と、Alpine を土台にしたイメージの扱いは次のとおりです。 公式の Docker イメージを使うコンテナ 公式の alpine イメージには sshd が入っていません。 アプリケーションを動かすためのベースイメージとして使っている限り、Alpine の告知の「Docker and other container users that do not run sshd in the container（コンテナ内で sshd を動かさない Docker などの利用者）」に当たり、影響を受けません。 sshd を足したコンテナ CI ランナー、開発用のコンテナ、踏み台のように、Alpine のイメージに openssh-server を足して SSH で入れるようにしたコンテナは、条件がそろう可能性があります。 こうしたイメージは製作者ごとに作り方が違います。 影響があるかどうかは、パスワード認証を残しているかと、鍵だけのユーザーとパスワードを持つユーザーが同居しているかで決まります。 Threat Landscape は、Alpine などを土台にしたコンテナイメージや CI ランナーに、パスワード欄が * の root やサービス用のアカウントが残っていて、sshd ではパスワード認証が有効なままの構成が多いとしています（組み込み機器やエッジの機器も挙げています）。 一方で、Cycode は、SSH サーバーを動かす公開のイメージを調べ、Gitea、Gogs、Jenkins の SSH エージェント、linuxserver の openssh-server（PASSWORD_ACCESS=true にしない限り）などの広く使われるイメージは、パスワードでのログインを止めているとしています。 どの程度の割合が当てはまるかを示す数字は、私が確認した範囲にはありません。 自分で作ったイメージや、外から取ってきた SSH 付きのイメージは、1つずつ確かめる必要があります。 クラウドイメージ Alpine のクラウドイメージは、ログインするユーザーが alpine に決まっていて、クラウドに登録した SSH の公開鍵がこのユーザーに入ります。 初期設定の仕組みによって、影響が分かれます。 cloud-init のイメージは、Alpine の告知によれば、cloud-init が PasswordAuthentication no を書き込むため影響を受けません。 私の見立てでは、user-data や後からの変更でパスワード認証を有効に戻していれば、この限りではありません。 Tiny Cloud のイメージを使う場合は、私の見立てでは、出典で確かめられる中で最も条件がそろいやすくなります。 Alpine の告知によれば、3.18.11 から 3.24.3 までの Tiny Cloud のイメージ（qcow2、VHD、AMI の形式）は、パスワード欄が * で、パスワードなしの doas を許可した alpine ユーザーが入った状態で配布されています。 初回起動の時点では安全です。 管理者がコンソール用のパスワードを設定したり、user-data でパスワード付きのユーザーを足したりして、パスワードを持つアカウントが1つでもできた時点で条件がそろいます。 攻撃者は、名前の決まった alpine ユーザーとして入り、doas で root になれます。 パスワードを設定した人は、別のアカウントに穴を開けたとは普通思いません... 公式の告知では、3.21.10、3.22.8、3.23.8、3.24.4 以降から作ったイメージには修正済みのパッケージが入るとしています。 ただし、11月6日時点でクラウドイメージのページに載っている版は 3.24.3、3.23.7、3.22.7、3.21.9 の4つで、修正済みの版から作った公式イメージはまだ配られていません。 起動済みのインスタンスに加えて、これから起動するインスタンスも、起動した直後に、apk upgrade -U -a と sshd の再起動か、パスワード認証の停止が要ります。 どちらのイメージかは、インスタンスの中で apk info -e tiny-cloud cloud-init を実行すると分かります。 tiny-cloud と出れば Tiny Cloud のイメージです。 分からないときは、Tiny Cloud のイメージとして扱って検証してください。 自前で構築した VM、物理サーバー、Raspberry Pi Standard や Extended、Virtual、Raspberry Pi の版から手で構築した機械は、影響を受けるかどうかが管理者の作り方で決まります。 Alpine の告知は、パスワードなしで adduser したユーザーや、usermod -p '*' でパスワード欄を * にした鍵だけのユーザーを、対象のアカウントに挙げています。 ただし、Alpine の adduser を担う busybox のソースを読むと、adduser -D はパスワード欄に * ではなく !（ロック）を書きます。 告知によれば ! のアカウントは鍵でも入れないため、鍵で使えている鍵だけのユーザーは、作った後に欄が書き換えられています。 - に書き換えたユーザーと、パスワードを設定したユーザーが同じ機械にいて、パスワード認証が有効なら当てはまります。 自分の機械のアカウントが * かどうかは、「まず確かめること」の節の awk で確かめてください。 導入の途中で root にパスワードを設定した機械では、root がパスワードを持つアカウントになります。 私の見立てでは、この機械にパスワード欄が * の鍵だけのユーザーを1人足すと、それだけで条件がそろいます。 root そのものの扱いは、どこから作った環境かで分かれます。 Alpine の告知によれば、3.16 ごろから基本のイメージで root のパスワード欄が * になっています。 rootfs を作るスクリプト（genrootfs.sh）が root の欄を * に書き換えているため、少なくともコンテナ向けの最小の rootfs はこれに当たります。 この場合も、OpenSSH の PermitRootLogin の既定値は prohibit-password なので、PermitRootLogin yes を設定していない限り、root にパスワードでは入られません。 ISO から手で入れた機械では、root のパスワード欄は空で作られ、導入の途中でパスワードを設定していればハッシュになります。 ISO から入れた機械では、どちらの場合も root は * ではないので、root そのものは入口になりません。 root に直接入られなくても、doas や sudo で root になれるユーザーに入られれば同じことになります。 逆に、入られたユーザーに doas や sudo の権限が無ければ、攻撃者ができることは、そのユーザーの権限の範囲にとどまります。 Extended の版は、ダウンロードページで「ルーターとサーバー向け」とされています。 私の見立てでは、社内や自宅のネットワークに置いた小さなルーターや機器は、確かめる対象から漏れやすい機器です。 Alpine を土台にしたコンテナイメージ Alpine を土台にして作られたイメージ（言語やミドルウェアのイメージの alpine の版など）は、中身が Alpine なので、ここまでの行と同じ扱いです。 sshd を足していなければ影響を受けず、足していれば「sshd を足したコンテナ」の行に当たります。 Alpine 以外の環境 条件の土台は「musl libc」と「PAM を通さない OpenSSH」の組み合わせで、Alpine に固有のものではありません。 発見者のページは、musl を使う例として Alpine のほかに OpenWrt、Buildroot、Yocto を挙げています。 一方で、glibc のディストリビューション（Debian、Ubuntu、Fedora など）、PAM を通す構成、Dropbear、OpenBSD は影響を受けないとしています。 musl を使うディストリビューションでも、OpenSSH を PAM 付きで出していれば、既定のままなら当てはまりません。 各ディストリビューションの OpenSSH のパッケージ定義を確かめた結果は次のとおりです。 環境 OpenSSH のパッケージ 判断 OpenWrt openssh-server は PAM なしで、パスワード認証は既定の yes のまま。openssh-server-pam は UsePAM yes と PasswordAuthentication no を設定する 既定の Dropbear のままなら影響なし。openssh-server に入れ替え、24.10 以降で root にパスワードを設定していれば条件がそろう（表の後の OpenWrt の段落） Buildroot、Yocto で作った機器 musl を使うか、PAM を使うかがビルドの構成で決まる 構成を確かめるまで分からない Void Linux（musl の版） PAM 付きでビルドし、既定の sshd_config を UsePAM yes にしている 既定のままなら影響なし。UsePAM no に変えていれば当てはまりうる。パッケージ定義は 10.6p2 に更新済み Gentoo（musl のプロファイル） pam の USE フラグ（Linux のプロファイルの既定で有効）が有効なら、UsePAM yes と PasswordAuthentication no を設定する 既定のままなら影響なし。pam を外してビルドしていれば当てはまりうる。10.6p2 の ebuild あり Chimera Linux PAM 付きでビルドし、UsePAM の既定値を yes に変えている 既定のままなら影響なし。パッケージ定義は 10.6p2 に更新済み postmarketOS Alpine のパッケージを使う Alpine と同じ手順で確かめる Debian、Ubuntu、Fedora などの glibc の系統 該当なし 影響なし 表の OpenWrt、Void Linux、Gentoo、Chimera Linux の行は、出典の記事ではなく、私が各ディストリビューションのパッケージ定義を読んで確かめた内容です。 postmarketOS の行と、OpenWrt の既定の SSH サーバーが Dropbear であることは、私の補足で、パッケージ定義では確かめていません。 OpenWrt は、OpenSSH に入れ替えた機器で条件がそろいやすい構成です。 OpenWrt のリリース版（23.05〜25.12）の出荷時の /etc/shadow には、パスワード欄が * の daemon、ftp、network、nobody のアカウントがあります。 また、24.10 以降の busybox はパスワードを SHA-256（$5$）で保存する設定のため、利用者が root にパスワードを設定すると、パスワードを持つアカウントの条件も満たします。 23.05 の busybox は MD5（$1$）で保存する設定で、MD5 のハッシュは告知の条件（$5$ か $6$）に当たりません。 ただし、23.05 から 24.10 以降に設定を引き継いで更新した機器では、パスワードを変えた時点で $5$ になります。 機器の上で、次のコマンドでハッシュの先頭を確かめてください。 パスワードを持つアカウントと、ハッシュの先頭3文字（$1$ は MD5、$5$ は SHA-256、$6$ は SHA-512） awk -F: '$2 ~ /^\$/ { print $1, substr($2, 1, 3) }' /etc/shadow 告知の4つ目の条件に照らすと、$5$ か $6$ が出れば当たり、$1$ だけなら当たりません。 4つのアカウントのシェルは /bin/false なので、入られてもシェルは取られません。 ただし、OpenWrt の openssh-server は sshd_config のポート転送の設定を書き換えておらず、OpenSSH の既定の許可のままです。 私の見立てでは、ログインが通ること自体が、SSH のポート転送でルーターの内側のサービスに届く足がかりになりえます。 OpenWrt の修正は、11月6日時点のパッケージ定義で確かめると、master と 25.12 のブランチが OpenSSH 10.6p2 に上がっています。 24.10 と 23.05 のブランチは、版の番号を 9.9p2 と 9.8p1 に据え置いています。 2026年11月5日（UTC）に 10.6p2 の修正を移植したパッチが入り、リリース番号が 1 から 2 に上がりました。 機器で表示される修正済みの版は、25.12 が 10.6_p2-r1、24.10 が 9.9_p2-r2、23.05 が 9.8p1-2 以降です。 版は opkg list-installed | grep openssh-server（25.12 は apk list -I 'openssh-server*'）で確かめられます。 ただし、11月6日時点のリリース用の配布フィード（x86_64 で確認）には、修正済みの版がまだ入っていません。 23.05 は 9.8p1-1、24.10 は 9.9_p2-r1、25.12 は 10.6_p1-r2 のままです。 openssh-server（PAM なし）を使っている OpenWrt の機器は、いまのところ更新では塞げないため、PasswordAuthentication no を設定し、/etc/init.d/sshd restart で再起動して塞いでください。 root にパスワードでログインしている機器では、設定の前に鍵で入れることを確かめてください（「塞ぎ方」の節の締め出しの項）。 入られたかどうかは、OpenWrt では logread | grep 'Accepted password for' で確かめます。 私の見立てでは、OpenWrt の既定のログは機器のメモリに置かれ、再起動で消えるため、記録が無いことは入られていない根拠になりません。 私の見立てでは、Alpine 以外でいちばん気にすべきなのは、OpenWrt や Buildroot、Yocto で作られたルーターや組み込み機器です。 こうした機器は、作った会社や人しか構成を知らず、利用者が中で何が動いているかを確かめにくいためです。 PasswordAuthentication no を設定できる機器なら、提供元の更新を待たずに塞げます。 自分で構成を確かめられない機器は、提供元にこの脆弱性への対応状況を問い合わせてください。 優先して棚卸しする環境 ここまでをまとめると、私の見立てでは、先に確かめる価値が高いのは次の4つです。 外から SSH で入れる Alpine の機械：攻撃者がポートに届く。名前の決まったユーザー（クラウドイメージの alpine など）や鍵だけのデプロイ用ユーザーが入口になる Tiny Cloud の Alpine のインスタンス：運用の途中でパスワードを1つ設定しただけで条件がそろい、doas で root まで届く musl の小さな機器（OpenWrt のルーター、Buildroot や Yocto の組み込み機器）：利用者が構成を確かめにくい 自分で Alpine を入れた小さな機械（Raspberry Pi、自宅や社内のルーター）：作った本人も存在を忘れやすく、棚卸しから漏れやすい 逆に、公式の Docker イメージをアプリケーションの土台に使っているだけのコンテナ、cloud-init のイメージを既定のまま使っている VM、glibc のディストリビューションのサーバーは、優先度を下げてかまいません。 まず確かめること Alpine の機械で該当するかどうかを確かめる手順は、公開されている条件の順番と同じです。 次のコマンドで確認してください。 どのコマンドも設定と状態を読むだけです（-T の実行と /etc/shadow の読み取りには root の権限が要ります）。 sshd が動いているか、どのバイナリか openssh-server-pam は /usr/sbin/sshd.pam、openssh-server-krb5 は /usr/sbin/sshd.krb5（どちらも PAM 付き。判断は UsePAM の値による） ps -o pid,args | grep '[s]shd' 入っている sshd のパッケージと版 apk list -I 'openssh-server*' PAM、パスワード認証、root のログインの設定 上で出たバイナリのパスで実行する。-f が付いていれば同じ -f を付ける /usr/sbin/sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) ' パスワード欄が * のアカウントの有無を確認 awk -F: '$2 == "*" { print $1 }' /etc/shadow パスワードを持つアカウントと、ハッシュの種類を特定（先頭3文字が $5$ か $6$ なら4つ目の条件に当たる） awk -F: '$2 ~ /^\$/ { print $1, substr($2, 1, 3) }' /etc/shadow 次の3つがすべて当てはまれば、影響があるものとして扱ってください。 PAM を通さない：-T の結果に usepam の行が出ない（PAM なしのビルド）か、usepam no が出る パスワード認証が有効：passwordauthentication yes が出る アカウントの同居：* のアカウントと、パスワードを持つアカウントがどちらも1つ以上ある 入っている版が修正済みでも、更新の後に sshd を再起動していなければ、動いている sshd は古いままです。 修正済みの版は「塞ぎ方」の節に並べています。 -T が読むのは設定ファイルで、動いている sshd の状態ではない点にも注意が要ります。 -T が何も出さないときは、実行自体が失敗しています。 awk で root が * と出ても、root にパスワードで入れるのは -T の結果が permitrootlogin yes のときだけです（root の扱いは「自前で構築した VM、物理サーバー、Raspberry Pi」の節）。 sshd_config に Match ブロックがある環境や、ディレクトリサービスのユーザーがいる環境では、上のコマンドだけで判断しないでください。 塞ぎ方 Alpine の告知が示す塞ぎ方は2つで、どちらか一方で穴は塞がります。 パッケージを更新して sshd を再起動する：apk upgrade -U -a の後に rc-service sshd restart。パッケージを更新しただけでは、動いている sshd は入れ替わらない パスワード認証を止める：PasswordAuthentication no を設定し、sshd を再起動する 修正済みのパッケージは、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.21 は2026年11月1日にサポートが切れましたが、Alpine は 3.16 までの各リリースにも修正済みのパッケージを出しています（版の番号は告知の表にあります）。 3.16 より前のリリースには、修正済みのパッケージがありません。 Cycode は、3.16 より前の Alpine のイメージは同社のラボで悪用できたとしており、こうしたイメージで塞ぐ手段はパスワード認証を止めることだけです。 sshd を足したコンテナは、更新したパッケージでイメージを再構築し、コンテナを作り直してください。 パスワード認証を止めるときは、次の点に注意が要ります。 書き足す位置：sshd の設定は、同じ項目なら最初に読まれた値が使われる。既存の PasswordAuthentication yes の後ろに no を書き足しても効かない。告知に、Match ブロックの中まで書き換える手順が載っている 締め出し：パスワードでしかログインしていないアカウントは入れなくなる。作業前に自分のアカウントが鍵で入れることを確かめ、新しいログインを試し終えるまで作業中の接続を切らない コンソールのパスワード：シリアルコンソールに入るためにパスワードを設定すると、Tiny Cloud のイメージでは条件がそろう。コンソール用のパスワードは、更新かパスワード認証の停止が効いたことを確かめた後に設定する 確かめ方：変えた後に、動いている sshd のバイナリで（-f が付いていれば同じ -f を付けて）-T | grep -i passwordauthentication を実行し、passwordauthentication no が出ることを確かめる。-T は Match ブロックの中を評価しないので、Match がある環境は sshd -T -C user=<ユーザー名>,host=<ホスト名>,addr=<接続元のアドレス> で条件ごとに確かめる 入られたかどうか 発見者のページは「as far as anyone knows, nobody noticed（知られている限り、誰も気づかなかった）」と書いています。 同じページによれば、問題は2016年から存在していました。 11月5日 15:30（CET）時点で、Detectify は悪用の公開報告を把握していないとしています。 NVD に載った CISA の評価（SSVC）では、悪用の状況は「poc」（概念実証がある段階）です。 残念ながら、誰も気づいていないからといって、誰も使っていないとは言えません。 Alpine の告知は、/var/log/messages で、パスワードを持たないアカウント（alpine、root、鍵だけのユーザー）に対する Accepted password for の行を探すよう案内しています。 ここでの root は、パスワード欄が * の場合に限ります。 「まず確かめること」の節の awk でパスワード欄が * と出たアカウントが、探す対象です。 私の見立てでは、コンテナの場合、sshd を -e 付きで動かしていれば docker logs などコンテナの出力に記録が出ます。 syslog も -e も無い構成では記録が残らないため、ログからは入られていないとは言えません。 告知はあわせて、外部に公開しているサーバーでは doas の利用、最近作られたユーザーとファイル、authorized_keys を見直すよう求めています。 ログインがあったことを否定できなければ、侵害されたものとして扱うことも求めています。 出典 Security advisory: openssh-server password authentication bypass（Alpine Linux、2026-11-05） Downloads（Alpine Linux） Cloud Images（Alpine Linux） alpine（Docker Hub の公式イメージ） OpenSSH Release Notes（OpenSSH 10.6p2、2026-11-05） "sshole": password authentication bypass: OpenSSH + musl libc（oss-security、2026-11-05） sshhole（発見者 Özgün Kültekin 氏のページ） sshhole: OpenSSH musl Password Bypass on Alpine and OpenWrt（Threat Landscape、2026-11-05） CVE-2026-123158（NVD） Advisory for OpenSSH+musl users（musl のメーリングリスト、2026-11-05） sshole (CVE-2026-123158): OpenSSH Auth Bypass on Alpine（Cycode） A Critical SSH Password Bypass Hits musl-Based Linux（Check Point） Critical vulnerability: OpenSSH authentication bypass on Alpine Linux（Detectify） sshd_config(5)（OpenBSD manual pages） sshd(8)（OpenBSD manual pages、-T と -C） OpenWrt packages の net/openssh/Makefile（master、openwrt-25.12、openwrt-24.10、openwrt-23.05 の各ブランチ） OpenWrt packages の openwrt-24.10 の net/openssh/patches（0001-avoid-password-authn-bypass.patch） OpenWrt packages の openwrt-23.05 の net/openssh/patches（0001-avoid-password-authn-bypass.patch） void-packages の srcpkgs/openssh（template と patches/sshd_config.patch） Gentoo の net-misc/openssh の ebuild Gentoo の profiles/default/linux/make.defaults Chimera Linux cports の main/openssh OpenWrt の package/base-files/files/etc/shadow（23.05、24.10、25.12 の各ブランチ） OpenWrt の include/package-defaults.mk（版の表記） OpenWrt のリリース用の配布フィード（packages-23.05、packages-24.10、packages-25.12 の x86_64） OpenWrt 24.10 の package/utils/busybox/Config-defaults.in OpenWrt 25.12 の package/utils/busybox/Config-defaults.in OpenWrt 23.05 の package/utils/busybox/Config-defaults.in OpenWrt 25.12 の config/Config-build.in（USE_APK の既定値） OpenWrt packages の openwrt-24.10 のコミット 4d71f28247（backport security mitigation from 10.6p2） OpenWrt packages の openwrt-23.05 のコミット f36055baca（backport security mitigation from 10.6p2） busybox の loginutils/adduser.c（adduser -D が書くパスワード欄） Alpine aports の scripts/genrootfs.sh と main/alpine-baselayout Alpine のパッケージ一覧（tiny-cloud） International Cyber Digest の投稿（2026-11-05）

@cemaxecuter ♥️ OpenWrt One. Just wish it supported devicetree overlays. packages#26832