サーバーの遠隔管理に使うOpenSSHで、特定のLinux環境ではパスワードを知らない第三者がログインできる脆弱性「CVE-2026-123158」が公表されました。OpenSSHは2026年11月5日に対策を含む10.6p2を公開し、Alpine Linuxも修正を提供しています。OpenSSHのリリース案内

翌6日には、セキュリティ企業Previdianが、この脆弱性を狙う攻撃の試行を観測しました。Webサイトの運営者は、サイトの管理画面だけでなく、サーバーに接続するためのOpenSSHが対象かを、開発会社や保守会社に確認したい状況です。Previdianの観測情報

攻撃の試行を観測。一般企業の被害件数とは区別する

Previdianの公開情報では、11月6日0時5分（UTC）に最初の試行を観測。11月7日に確認したページには、1つの送信元IPアドレスから8回の試行が記録されていました。同社は、センサーの観測件数だけでは、攻撃が成功したことや、特定の組織が侵害されたことを示さないと説明しています。観測記録とその読み方

今回確認できるのは、問題が公開され、修正が提供されただけでなく、攻撃者側の試行も始まっているという点です。「全OpenSSHサーバーが侵入される」「8社が被害を受けた」と受け取るべき情報ではありません。

対象は、muslとPAM無効などの条件が重なるサーバー

OpenSSHの案内は、Linuxの基礎部品である「musl libc」を使い、認証処理の仕組み「PAM」を無効にした環境を対象としています。OpenSSHが入っているというだけでは、今回の脆弱性に該当するとは限りません。OpenSSHの対象条件

発見者とAlpine Linuxの公式案内を基に、修正前の環境で確認したい条件を整理すると、次のようになります。発見者による説明

  • SSHサーバーが動作し、接続できる：接続を受け付けるプログラム「sshd」が稼働している。
  • PAMを使わない構成である：標準のopenssh-server、またはopenssh-server-pamでUsePAM noを設定した構成。
  • パスワード認証が有効である：PasswordAuthentication yesになっている。
  • アカウントの条件が重なる：パスワード欄が「*」の対象アカウントがあり、同じマシンに「$5$」または「$6$」形式のパスワードハッシュを持つローカルアカウントがある。

最後の条件は、普段はSSH鍵で接続するアカウントにも関係します。「いつも鍵でログインしている」と「サーバーがパスワード認証を受け付けない」は別なので、運用方法だけで対象外と判断せず、実際の設定を確認してもらいましょう。Alpineの詳しい対象条件

Alpineを使うコンテナーでも、内部でsshdを動かしていなければ、この経路の対象にはなりません。PasswordAuthentication noの環境や、PAM対応パッケージでUsePAM yesの環境も、Alpineは対象外としています。

Red Hatは、自社のOpenSSHが別の基礎部品「glibc」を使い、標準でPAMも利用するため、同社製品は影響を受けないと説明しています。Amazon Linux 2、2023、2027 Previewも影響なしと案内されています。ただし、AWS上で自分たちが動かすAlpineサーバーまで対象外になる、という意味ではありません。Red Hatの案内、Amazon Linuxの案内

サイトの改ざんやデータへのアクセスにつながる可能性

認証を回避されると、攻撃者は対象アカウントの権限でサーバーにアクセスできます。その権限でサイトのファイルを書き換えたり、設定やデータを読んだりできる構成なら、Web事業にも影響が及ぶ可能性があります。これは権限に応じたリスクであり、今回の観測から個別のサイト被害が確認されたという意味ではありません。認証回避による影響の説明

管理者権限のrootに直接ログインできるかは設定次第です。OpenSSHの標準設定ではrootのパスワード認証が禁止されています。ただし、別のアカウントへの侵入後に管理者権限へ移れる構成には注意が必要です。OpenSSHのrootログイン設定

Alpineの一部のtiny-cloudイメージについては、起動直後から一律に悪用可能なのではなく、管理者が後からパスワードを設定するなどして条件がそろうと、標準のalpineユーザーから管理者権限に至り得ると公式案内が説明しています。初期設定だけでなく、その後の変更も確認対象です。Alpineのクラウドイメージに関する注意

修正版の適用に加え、稼働中のsshdの再起動を

OpenSSH本体の対策版は10.6p2です。Alpineでは既存の版にも修正を取り込んでいるため、10.6という番号だけを基準にせず、利用ブランチに対応した修正済みパッケージを確認します。

  • Alpine 3.24：openssh 10.3_p1-r2
  • Alpine 3.23：openssh 10.2_p1-r1
  • Alpine 3.22：openssh 10.0_p1-r11
  • Alpine 3.21：openssh 9.9_p2-r1
  • edge：openssh 10.6_p2-r0

これらは今回の修正が入った版です。作業時には、利用ブランチの最新の修正済み版を確認してください。3.16〜3.20にも修正パッケージが提供されていますが、3.21を含め通常サポートが終了した版では、今回の対処と併せて移行を検討する必要があります。Alpineの修正版一覧

Alpine 3.21.10、3.22.8、3.23.8、3.24.4には修正が含まれます。公式は、パッケージを更新するだけでは、すでに動いているsshdは置き換わらないため、更新後に再起動するよう求めています。OS全体の再起動と混同せず、保守担当者に対象サービスへの反映を確認してもらってください。Alpineの修正リリース案内

OpenSSHの修正版適用、sshd再起動、新しい接続での確認、完了記録の4段階を示す図

図は保守対応の確認順です。接続を失った場合の復旧手段を準備し、設定変更後の新しい接続を確認するまで、作業中の接続を不用意に閉じないことが大切です。

すぐに更新できない場合、AlpineはPasswordAuthentication noにしてsshdを再起動する対処を案内しています。変更前にSSH鍵でのログインが機能することを確認し、担当者が設定の検証と再接続の確認まで行う必要があります。利用者や接続元ごとの例外設定もあるため、設定ファイルの1行だけでなく、対象の接続に適用される設定を確認します。Alpineの暫定対処、OpenSSHの条件別設定

開発会社・保守会社には、この4点を確認

  1. どこで使っているか：本番サーバーだけでなく、開発・検証環境、踏み台、コンテナー内で稼働するsshdも調べたか。
  2. 対象条件に当たるか：OS、muslとPAM、実際の認証設定、アカウント条件、外部から接続できる範囲を確認したか。対象外なら根拠は何か。
  3. 稼働環境に反映したか：修正済みパッケージ、更新日時、sshdの再起動、新しい接続での動作確認まで完了したか。
  4. 不審なログインがないか：通常は鍵だけで使うアカウントのパスワード認証成功、管理者権限の利用、アカウントや登録鍵の変更を確認したか。

Alpineは、パスワード未設定のアカウントに対する認証成功のログなどを調べ、侵入を否定できなければ侵害されたものとして扱うよう案内しています。疑わしい記録がある場合は、更新作業の完了だけで対応を終えず、ログの保全と調査を保守・セキュリティ担当者に依頼してください。Alpineの侵入確認の案内

Webサイトが普段どおり表示されていても、管理用の接続経路が修正済みかは分かりません。まずはCVE番号を添えて対象確認を依頼し、「更新した」だけでなく「再起動して反映を確かめた」まで報告してもらいましょう。

情報確認日：2026年11月7日。対象条件や対応状況は更新されることがあるため、作業前には提供元の最新案内を確認してください。