OpenSSHの認証回避「SSHole」、長すぎるパスワードで入れないはずのアカウントが開く。対象はAlpine等のmusl構成

まず初めに

「パスワードを設定していないアカウントには、パスワードでは入れない」。これは金庫に鍵穴が付いていないのと同じで、疑う余地のない大前提のはずだった。ところが鍵穴のない扉に、やたらと長い鍵を差し込むと開いてしまう、というのが今回の話である。壊れた部品は1つではない。2つのソフトウェアの「正しいはずの仕様」が、重なった場所でだけ噛み合ってしまった。条件が重ならなければ何も起きない代わりに、重なった環境では合言葉いらずで扉が開く。

※個人の感想です

何が起きたのか

OpenSSHは、サーバへ安全に遠隔ログインするための仕組み（SSH）の代表的な実装で、そのサーバ側プログラムがsshdです。OpenSSHプロジェクトは2026年11月5日付の10.6p2リリースノートで、この版に「重大なセキュリティ上の回避策」が含まれるとし、musl libcを使いPAMを無効にしたLinuxシステムに影響する、パスワード認証の回避を避ける変更を行ったと説明しました。同ノートは、根本原因はsshdの外側にあるとプロジェクトは考えているものの、sshd経由で悪用でき、sshd側で回避できるとしています。報告者はWakefieldのÖzgün Kültekin氏です。

欠陥の詳しい仕組みは、発見者自身の公開資料と、その後の技術分析で説明されています。Linuxの認証情報ファイル（/etc/shadow）では、パスワードでログインさせないアカウントのパスワード欄に「」を置くのが慣例です。一方、musl libcのパスワード照合関数crypt()は、照合に失敗したときに「」という文字列を返す仕様で、入力が256バイトを超えると照合が失敗扱いになります。sshdは、タイミングの差から利用者名を推測される問題（2016年のCVE-2016-6210）への対策として、パスワード欄が「」のアカウントでも、他のアカウントのソルト（照合用の値）を使って照合処理を回すようになっていました。この3つが重なると、256バイトを超えるパスワードを送ったときにcrypt()が返した「」と、保存されている「*」が一致してしまい、認証が通ります。発見者の資料は、対象を「256文字を超えるパスワードを受け付ける」と表現し、Alpine Linux側の分析などは257から1,024バイトの範囲としています。

本サイトで昼刊に伝えたLinuxカーネルの脆弱性CVE-2026-98276とは別の欠陥です。あちらはカーネル内部の競合、こちらは利用者認証の入口の話になります。

成立条件——全部そろった環境だけが対象

技術分析各社の整理では、影響を受けるのは次の条件がすべてそろう環境です。

• musl libcを使うLinux（Alpine Linuxのほか、OpenWrt、Buildroot、Yoctoなどで組んだ環境が例示されています）
• sshdがPAMを使わずにパスワード照合をしている（Alpineの通常のopenssh-serverパッケージはこの構成です。PAM版を使いUsePAM yesの場合は対象外とされています）
• パスワード認証が有効（PasswordAuthentication yes。OpenSSHの既定）である
• パスワード欄が「*」のアカウントが存在する（Alpineではrootがこの形で出荷されるほか、鍵専用に作った利用者や、クラウドイメージの初期利用者などが該当し得ます）
• ソルトを借りる先として、SHA-256／SHA-512形式のパスワードハッシュを持つアカウントが別に存在する

逆に、glibcを使うDebianやUbuntu、Fedoraなど、PAMで認証する構成、OpenBSDは対象外とされています。対象版は、こうした構成で動く10.6p2より前のOpenSSHです。Alpine Linuxは2026年11月5日に、3.16からedgeまでの各系列向けに修正済みパッケージを公開し、3.21.10、3.22.8、3.23.8、3.24.4などのポイントリリースにも修正が含まれるとしています。

悪用の報告——9時間足らずで試行、11月8日には20件

The Hacker Newsによると、脅威インテリジェンス企業のPrevidianは、CVEが公開されてから9時間足らずで最初の悪用試行を観測しました。同社のハニーポット（Alpine LinuxとOpenSSHを稼働）では、実際にroot権限の取得まで成功したことが確認されたといいます。当初の試行は、日本に位置付けられる単一のIPアドレスから8件で、長いパスワードで認証を回避したあと、id、uname、hostnameといった偵察用のコマンドが実行されたとされています。

同記事の2026年11月8日付の更新では、試行は20件に増え、発信元はデンマーク、イラン、日本、オランダ、ノルウェー、シンガポール、スウェーデン、スイス、米国の13のIPアドレスに広がったとされています。これらはPrevidianの観測としてThe Hacker Newsが報じた内容であり、本記事ではその帰属を分けて記載しています。なお、執筆時点でこの脆弱性は米CISAの「悪用が確認された脆弱性」一覧（KEV）には載っていません。検証コードは発見者により公開されています。

対策——更新と「再起動」までが1組

対策の本筋は、OpenSSH 10.6p2、または各ディストリビューションの修正済みパッケージへの更新です。Alpine Linuxであればopensshパッケージの更新が該当します。ここで重要なのは、パッケージを更新しても、起動中のsshdプロセスは旧いまま残る点です。再起動するまで、脆弱なプロセスが接続を受け付け続けます。「更新したのに刺さる」を避けるため、更新とsshdの再起動を1組として扱ってください。

すぐに更新できない場合の回避策は、sshdの設定でパスワード認証そのものを無効にする（PasswordAuthentication no）ことです。鍵認証のみの運用に切り替える形になります。あわせて、自社のAlpineやmusl系の環境について、sshdがPAMなしで動いていないか、パスワード欄が「*」のアカウントに不審な「Accepted password（パスワード認証の成功）」の記録が残っていないかを確認することが推奨されます。本来パスワードで入れるはずのないアカウントへのパスワード認証成功は、そのまま侵害の兆候です。

IT Postの見方

IT Postでは、この件の教訓は「安全のための仕様同士が衝突すると、誰も嘘をついていないのに扉が開く」という点だと考えます。「*」を返すmuslの判断にも、タイミング攻撃を消すためにソルトを借りたOpenSSHの判断にも、それぞれ理由がありました。欠陥は部品ではなく、部品の「重なり」に住んでいた。2016年から約10年、誰にも気づかれずに残っていたのは、その重なりがAlpineの既定構成という、あまりにも日常的な場所にあったからでもあります。コンテナの土台としてAlpineを使う現場は多く、「特殊な構成の話」と片付けるには対象が身近すぎます。

もう1つは速さです。公表から9時間足らずで試行が始まり、3日で発信元が13に広がったという観測は、修正版の公開と攻撃者の出足がほぼ同時であることを示します。OpenSSHプロジェクト自身、10.6p2のノートで「AIツールが見つけた欠陥は、別の研究者に独立に再発見されることがある」とし、当面はリリース頻度を上げて修正を早く届けると宣言しました。発見者の調査にもAIエージェントが使われたと報じられています。IT Postでは、見つかる速さと突かれる速さの両方が上がった以上、「更新して再起動まで」を自動化しておくことが、この種の欠陥への実質的な答えだと考えます。

今後どうなりそうか

今後の確認点は、CISAのKEVへの追加の有無、Alpine以外のmusl系環境（組み込み機器を含む）での影響範囲の公表、そして悪用試行の規模の変化です。条件がそろう環境は限られますが、そろった環境では認証そのものが崩れるため、対象の棚卸しが先決です。

IT Postでは、新しい公式情報が確認できれば、本記事を更新します。