ISSコラム

公表から9時間未満で、攻撃が始まりました。OpenSSHの認証回避の脆弱性「SSHole」（CVE-2026-123158、CVSS 8.1）は、2026年11月5日に公表されています。その約2時間後にはPoCが公開され、翌6日には実際の攻撃の試行が観測されました。

狙われるのは、musl libcを使い、PAMを使わずに動くsshdです。代表例はAlpine Linuxの標準構成で、コンテナイメージや組込み機器で広く使われています。「うちはUbuntuだから関係ない」と判断している組織ほど、見落としやすい脆弱性です。

本コラムでは、仕組み、影響範囲、2026年11月9日時点の最新動向、実務で取るべき対応をまとめます。

脆弱性の仕組み：「失敗」と「ロック中」が同じ文字になる

原因は、OpenSSHとmuslそれぞれの「正しい仕様」の組み合わせです。どちらか一方だけでは問題になりません。

1. musl側： muslのcrypt()は、256バイトを超えるパスワードのSHA-256/SHA-512ハッシュ化を拒否します。失敗するとNULLではなく「*」を返します。2012年からの動作です。
2. OpenSSH側： 2016年のCVE-2016-6210（ユーザー名列挙）対策で、sshdは使えるハッシュを持たないアカウントでも、他のアカウントのソルトを借りてハッシュ計算するようになりました。応答時間の差からユーザーの有無を推測させないためです。
3. 結果： 鍵認証専用やロック中のアカウントは、shadowのパスワード欄が「*」です。257～1024バイトのパスワードを送るとcrypt()が失敗して「*」を返し、保存値と一致してログインが通ります。

つまり、「パスワードでは入れないはずのアカウント」に、任意の長いパスワードで入れてしまいます。攻撃は接続1回で成立し、特別な技術もいりません。発見者のOzgun Kultekin氏は、AIエージェントを使って多数のsshdビルドに約17,600通りの異常なログインを試し、この組み合わせを見つけたと説明しています。

影響範囲：4つの条件がすべてそろうと悪用できる

悪用できるのは、次の4条件がすべてそろった場合です。

• 影響を受ける： Alpine Linux 3.16～3.24とedgeのopenssh-server。UsePAM noにしたopenssh-server-pamも含みます。
• 影響を受ける可能性がある： OpenWrt、Buildroot、Yoctoなどmuslベースの組込み環境。sshdを入れたコンテナイメージ。
• クラウドイメージ： AlpineのAWS・Azure向けtiny-cloudイメージ（3.18.11～3.24.3）は、既定のalpineユーザーがパスワードなしでdoasを使えます。侵入されると、そのままrootになれます。
• 影響を受けない： glibcベース（Debian、Ubuntu、RHEL系など）、PAMでパスワードを確認する構成、Dropbear、OpenBSDなどLinux以外のOS、パスワード認証を無効にした構成。

rootへの直接ログインは、PermitRootLoginの既定値で封じられています。ただし、設定を変えている環境や、鍵専用の管理ユーザーがパスワードなしでsudoやdoasを使える環境では、rootを取られたも同然です。

最新動向：公表から9時間未満で攻撃、KEVは未登録（11月9日時点）

公表後の動きは非常に速く、修正版、PoC、攻撃の試行がほぼ同時に出そろいました。時刻は主に协定世界時（UTC）です。

攻撃者は侵入後、非対話型のSSHセッションでid、uname、hostnameといった偵察コマンドを実行していました。どれが侵入できた環境かを確かめる、大規模スキャンの初期段階に典型的な動きです。

注意点が2つあります。ハニーポットでのroot取得は報道ベースの情報で、Previdianの公開ページ自体は「試行の観測」としています。また、KEVに未登録でも、悪用の試行はすでに確認されています。KEVの登録を待たずに対応してください。最新の登録状況はCISA KEVカタログで確認できます。

実務者が今すぐやるべきこと

対応は「探す、塞ぐ、調べる」の順に進めます。

☐ 対象を探す： サーバーだけでなく、コンテナイメージ、クラウドのAlpineイメージ、ルーターやIoT等の組込み機器も洗い出す。SBOMやイメージスキャナーで、muslとopenssh-serverの組み合わせを検索する。
☐ 外から見えているか確かめる： インターネットに公開されたSSHポート（デフォルト以外のポートも含む）を、外部からの攻撃面調査で確認する。公開中のものを最優先にする。
☐ 更新して、必ず再起動する： OpenSSH 10.6p2、またはAlpineの修正版（3.21.10、3.22.8、3.23.8、3.24.4以降、edgeは10.6_p2-r0）を適用する。パッケージを更新しても動作中のsshdは古いままなので、再起動する。コンテナはイメージを再ビルドして入れ替える。
☐ すぐ更新できなければ回避する： PasswordAuthentication noを設定してsshdを再起動する。事前に公開鍵でログインできることを確認し、別のセッションで接続できると確かめるまで管理セッションを閉じない。
☐ 侵入されていないか調べる： 認証ログ（Alpineは/var/log/messages）で、パスワードを持たないアカウントの「Accepted password for」を検索する。あわせて、doas/sudoの利用履歴、新しいユーザー、authorized_keysの変更も確認する。
☐ 疑わしければ侵害とみなす： 該当するログがあるか、侵入がなかったと言い切れない場合は、侵害されたものとして保全・調査し、鍵や認証情報を更新する。コンテナなら修正済みイメージで作り直す。
☐ 公開PoCを不用意に実行しない： GitHub上のPoCは未検証で、マルウェアを含む恐れがあると指摘されています。検証は隔離した環境で、信頼できる手順で行う。

中長期的には、「インターネットに公開するSSHではパスワード認証を無効にする」ことを標準設定にしてください。今回の脆弱性は、この1行の設定で影響を受けなくなります。

まとめ

SSHoleは、悪用が簡単で、公表後すぐに攻撃が始まった脆弱性です。一方で影響範囲は限られ、更新と再起動、またはパスワード認証の無効化で封じられます。難しいのは、「自社のどこにmuslのsshdがあるか」を把握することです。コンテナ、クラウドイメージ、組込み機器は、資産台帳から漏れやすい領域です。

インターネットセキュアサービス株式会社（ISSKK）では、外部から見えるSSHの洗い出し、コンテナや組込み機器を含む脆弱性診断・ペネトレーションテスト、侵害の痕跡調査、ISMSにおける脆弱性管理の仕組みづくりを支援しています。対象があるか分からないという方も、お気軽にご相談ください。

※本記事は2026年11月9日時点の公開情報に基づいています。悪用状況やKEVの登録状況は変わる可能性があります。

出典

• Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot（The Hacker News、11月6日、8日更新）
• OpenSSH flaw exploited in the wild just hours after disclosure（Help Net Security、11月6日）
• CVE-2026-123158 Exploitation Attempts Observed（Previdian、11月9日更新）
• *sshole: OpenSSH Authentication Bypass Gives Attackers Root on Alpine Linux（Orca Security）
• OpenSSHのパスワード認証回避の脆弱性 CVE-2026-123158 についてまとめてみた（piyolog、11月6日）
• musl libc環境のsshdで認証回避の脆弱性 ─ OpenSSH 10.6p2などで対策（Think IT、11月7日）
• CISA Known Exploited Vulnerabilities Catalog