CVE-2026-123158: OpenSSHパスワード認証バイパス、Alpine Linuxに影響

OpenSSHにおける高深刻度の脆弱性により、未認証のリモート攻撃者が、特定のLinuxシステムで過長なパスワードを送信することにより、パスワード認証をバイパスできる可能性があります。CVE-2026-123158として追跡され、SSHholeと名付けられたこの欠陥は、CVSS 3.1スコア8.1を持ち、主にmusl libcにリンクされ、PAMなしで動作するLinux環境に影響を与えます。Alpine Linuxは、標準のopenssh-serverパッケージがこの構成をデフォルトで使用しているため、最も顕著な影響を受けるプラットフォームです。

この脆弱性は、OpenSSHのパスワード検証とmusl libcのcrypt()実装との予期しない相互作用から生じます。過剰に長いパスワードが提供された場合、crypt()はエラーを示すために文字列*を返すことがあります。従来のパスワードが設定されていないLinuxアカウントの中には、/etc/shadowのパスワードフィールドにも*を格納しているものがあります。脆弱な条件下では、sshdは一致する値を成功した認証として誤って解釈することがあります。

攻撃者はターゲットユーザーのパスワードを知らなくてもよいです。露出したSSHサービスが必要な条件を満たす場合、サービスに到達できる攻撃者は脆弱な長さの範囲のパスワードを使用して特定のアカウントに認証することができます。影響は、侵害されたアカウントに割り当てられた特権に依存します。特権付きのサービスアカウントやdoasまたは他の特権昇格メカニズムを使用できるアカウントにアクセスできると、システム全体の侵害につながる可能性があります。

営業に連絡

OpenSSHはこの問題に対処するため、2026年11月5日にPortable OpenSSH 10.6p2をリリースしました。Alpine Linuxは同時に、すべてのサポートされているブランチといくつかの古いブランチの修正済みOpenSSHパッケージをリリースしました。OpenSSHチームはこのリリースを、musl libcを用いてPAMを無効にしているLinuxシステムのための重大なセキュリティ回避策を含むと説明しています。

公的な再現環境と概念実証の資料はすでに利用可能です。ただし、2026年11月6日時点で、確認済みの現実世界での攻撃における脆弱性の悪用は報告されておらず、この欠陥はCISAの既知の悪用されている脆弱性カタログに追加されていません。

組織は、SOC PrimeのAIネイティブ検出インテリジェンスプラットフォームを使用して、新たな認証バイパス脆弱性に対する防御を強化できます。これにより、SIEM、EDR、XDR、およびデータレイク環境全体での脅威のハンティングと検出エンジニアリングが加速されます。

セキュリティチームはPrime Architectを使用して、利用可能なSSH、認証、エンドポイント、およびネットワークのテレメトリに合わせたハンティングクエリと検出ロジックに脆弱性インテリジェンスを変換することもできます。

通常はキーのみの認証を使用するアカウントへのパスワードベースのSSHログインの成功、異常に長いパスワードを含む異常な認証試行、サービスアカウントへの予想外のリモートアクセス、およびアカウントの通常の動作と一致しない認証後の活動を監視することで、CVE-2026-123158を検出します。

すべてのCVEに対して検出コンテンツが利用可能であるとは限りません。SOC Prime Platformで現在のカバレッジを確認してください。関連する検出がまだ利用可能でない場合は、新しい脅威インテリジェンスと検出コンテンツが継続的に追加されるため、再度確認してください。

CVE-2026-123158の分析

CVE-2026-123158は、PAMなしでパスワード認証が行われるときに、musl libcを使用してLinux上で動作するOpenSSH sshdのPortable OpenSSH 10.6p2以前に影響を与えます。このCVEは、CVSS 3.1のスコア8.1を持ち、ベクトルAV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:Hで遠隔からの事前特権やユーザー操作なしでの悪用を反映していますが、特定のシステムおよびアカウント構成が必要です。

根本原因はOpenSSHとmusl libcによって提供されるパスワードハッシュ関数間の相互作用にあります。

PAMが無効になっているシステムでは、sshdはシステムのcrypt()機能を使用してパスワードの検証を行います。一般的なアカウントの場合、/etc/shadowには暗号化されたパスワードハッシュが含まれ、ユーザーから送信されたパスワードから生成された値が保存されたハッシュと比較されます。

musl libcは、供給されたパスワードがサポートされる入力長を超える場合には異なる動作をします。256バイトを超えるパスワードに対しては、crypt()は通常のパスワードハッシュではなく、エラー値として*を返します。

*はまた、従来のパスワードが設定されていないアカウント用に/etc/shadowで一般的に使用されるため、問題が発生します。

脆弱なsshdがこれらのアカウントの1つに対して過長なパスワードを受け取ると、認証フローはcrypt()によって返された*をアカウントのシャドウエントリに格納された*と効果的に比較することができます。値が一致し、認証が誤って成功する可能性があります。

CVEの説明は、影響を受けるアカウント構成では、256文字から1024文字の間のパスワードが認証の成功につながる可能性があると述べています。独立した再現は、通常の256バイトの境界を超えるパスワードが脆弱な条件を引き起こすために十分であると述べています。

したがって、この欠陥はすべてのOpenSSHの展開に影響を与える普遍的なパスワードのバイパスではありません。

いくつかの特定の条件が一致する必要があります。

まず、サーバーはmusl libcを使用する必要があります。Alpine Linuxは主要な主流の例ですが、他の組み込みや最小限のLinux環境もmuslを使用することができます。

第二に、sshdはPAMなしでユーザーを認証する必要があります。Alpineの標準のopenssh-serverパッケージはPAMなしで構築されており、代替のopenssh-server-pam構成はUsePAM yesが有効なときに保護されています。

第三に、パスワード認証が有効でなければなりません。PasswordAuthentication yesが関連する構成です。PasswordAuthentication noで公開鍵のみの認証に構成されたシステムは、文書化された攻撃経路にさらされていません。

最後に、攻撃者はパスワードフィールドに*を含むアカウントを必要とします。これには、キーオンリーのユーザー、パスワードなしで作成されたアカウント、一部のディレクトリサービスを介したアイデンティティ、および特定のクラウドイメージユーザーが含まれます。

Alpineはまた、追加の条件として、脆弱な認証経路が説明されるように機能するために、少なくとも1つのローカルアカウントが$5$または$6$スタイルのパスワードハッシュを含む必要があることを指摘しています。

ルートアカウントには特別な注意が必要です。Alpineは通常root:*を格納しますが、OpenSSHのデフォルトPermitRootLogin prohibit-passwordはルートへのパスワード認証を直接的には防ぎます。その結果、標準のAlpineインストールは、このバグを通じた直接的なルートログインを自動的に公開しません。

この保護は、より広範なリスクを排除するものではありません。もし別のアカウントがパスワードフィールドに*を持っていて、doas、sudo、コンテナの機能、あるいは他の特権メカニズムを通じて管理者権限を持っている場合、成功した認証は依然として完全なシステム侵害への経路を提供する可能性があります。

Alpineの公式tiny-cloudイメージは特に関連があります。セキュリティ研究は、alpineアカウントが脆弱な条件を満たすことができ、doasを使用して昇進された権限を得ることができるバージョンを特定しました。これにより、防御者がアカウントの権限を評価する必要性を示しています。脆弱性がすべての環境で無害なユーザーアクセスや自動的なルートアクセスを提供するとは限らないことを示しています。

Debian、Ubuntu、RHELなどのglibcベースのLinuxディストリビューションは、この特定の脆弱性の影響を受けません。なぜなら、この脆弱な動作はmusl libcのパスワードハッシュ実装に依存しているからです。SSHパスワード検証にPAMを使用しているシステムもまた、文書化された脆弱な構成の外にあります。

コンテナには、同様の資格が必要です。Alpineはコンテナのベースイメージとして広く使用されていますが、sshdを実行しない通常のコンテナは、この攻撃経路を通じて脆弱ではありません。主な懸念は、SSHサーバーを明示的にインストールして露出しているコンテナ、アプライアンス、開発環境、またはレガシーワークロードです。

CVE-2026-123158のPoCの状況は急速に発展しています。脆弱性レコードで直接参照されている公開再現ラボは、防御者がプライベートなエクスプロイト研究へのアクセスなしに認証バイパスを再現できることを前提とすべきことを示しています。これにより、確認された悪意のある攻撃がまだ報告されていないにもかかわらず、修正の緊急性が実質的に高まります。

この脆弱性はWakefieldのÖzgün Kültekinによって報告されました。OpenSSHは2026年11月5日にセキュリティ対策を施したバージョン10.6p2を公開しました。レビューされた主要な情報源は、研究者が最初にこの問題を発見または個人的に報告した正確な日付を特定していません。

OpenSSHの修正は、エラー値や無効な短いパスワードハッシュがパスワード認証中に受け入れられないように設計された検証を追加します。OpenSSHは、基礎となる根本原因がsshdの外部に存在すると考えていると指摘していますが、条件がSSHサーバーを通じて悪用される可能性があるため、プロジェクトはOpenSSH自体に防御的な回避策を実装しました。

Alpine Linuxは、複数のブランチにわたって修正をバックポートしました。

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

管理者は、SSHハンドシェイク中に表示されるSSHバージョンバナーだけでなく、ディストリビューションパッケージの状態に依存する必要があります。Linuxディストリビューションは、しばしばセキュリティパッチをバックポートしますが、SSHハンドシェイク中に表示されるオープンSSHのバージョンを変更せずにそれを行います。したがって、古いバージョン文字列を表示しているサーバーには、すでにベンダーの修正が含まれている可能性があります。

CVE-2026-123158の検出のためには、防御者はSSH認証のテレメトリを優先的に使用するべきです。特に強力なハンティングシグナルは、公開鍵認証のみに使用されることを意図したアカウントへの成功したパスワードログインや、使用可能なパスワードが構成されていないアカウントへの成功したログインです。

Alpineシステムでは、管理者は/var/log/messages、集中認証ログ、SIEM記録、または同等のテレメトリを確認して、予期しないサービス、キーオンリー、または管理者アカウントを含む受け入れられたパスワードイベントを確認できます。

防御者は、成功した認証をソースIPアドレス、ログイン時間、セッション継続時間、ログイン後に実行したコマンド、特権の昇格、authorized_keysの変更、アカウントの作成、予定されたジョブ、予期しないアウトバウンドネットワーク接続と相関させるべきです。

ネットワークテレメトリも露出されたシステムを特定する助けになります。外部から到達可能なSSHサービスでパスワードまたはキーボードインタラクティブ認証を提供しているものは、特にその基礎となるシステムがAlpineまたは他のmuslベースのディストリビューションの場合は、より高い修正優先度を受けるべきです。

現在、キャンペーン固有の CVE-2026-123158 IOC たとえば、確認済みの攻撃者IPアドレス、ドメイン、マルウェアハッシュ、またはコマンド&コントロールインフラストラクチャはありません。静的な指標がないため、SSH認証とその後のセッション活動の行動モニタリングが特に重要です。

CVE-2026-123158の緩和策

主な対策は、OpenSSH 10.6p2またはLinuxディストリビューションが提供する修正パッケージのインストールです。Alpine管理者は、最新のパッケージリポジトリを使用してシステム全体を更新し、その後sshdを再起動する必要があります。パッケージの更新のみでは、すでに実行されているSSHデーモンプロセスを置き換えません。

Alpineベースのコンテナを運用している組織は、openssh-serverをインストールしているイメージを再構築し、再デプロイする必要があります。ホストオペレーティングシステムを更新するだけでは、コンテナイメージに埋め込まれた脆弱なOpenSSHパッケージを修正しません。

管理者は、すべてのAlpineホストが脆弱であると仮定する前に露出を特定する必要があります。主要なチェックポイントは以下の通りです：

1. ホストがmusl libcを使用しているかどうかを確認します。
2. sshdがPAM無効で実行されているかを確認します。
3. パスワード認証が有効かどうかを確認します。
4. /etc/shadowパスワードフィールドが*であるログイン可能なアカウントを特定します。
5. これらのアカウントに割り当てられた権限を確認します。
6. インストールされているOpenSSHパッケージをディストリビューションの修正パッケージバージョンと照合します。

即時のパッチ適用が不可能な場合、組織はSSHのパスワード認証を無効にするべきです。

設定：

PasswordAuthentication no

そして、該当する場合：

KbdInteractiveAuthentication no

この設定を適用する前に、管理者は公開鍵認証が機能することを確認して、正当な管理アクセスが失われないようにするべきです。

SSHの設定はその後確認され、デーモンをリロードまたは再起動する必要があります。その後、外部確認を行ってサーバーが公開鍵認証のみを提供していることを確認してください。

ネットワークアクセスの制限は、深層的な防御を提供します。SSHは、信頼できる管理ネットワーク、VPNインフラストラクチャ、バスティオンホスト、または明示的なソースIP許可リストからのみ到達可能であり、インターネットに普遍的に公開されるべきではありません。

組織はまた、コンテナ内でSSHが必要かどうかを再評価すべきです。一般的なオーケストレーション環境は通常、docker execやkubectl execなどの代替手段を提供し、リモートでアクセス可能な不要な認証サービスを排除します。

露出の可能性があるシステムについては、修正前に発生した過去の成功したパスワードログインを確認します。パスワードなしで構成されているアカウントと、通常SSHキーのみで認証することが期待されるアイデンティティに特に注意を払います。

予期しない成功したログインが確認された場合、そのアカウントを潜在的に侵害されているものとして扱います。シェル履歴が利用可能な場合はそれを確認し、プロセスの実行、特権の昇格、新規または変更されたauthorized_keysエントリ、ユーザーおよびグループの変更、cronジョブ、スタートアップスクリプト、パッケージのインストール、およびアウトバウンドネットワーク接続を確認します。

侵害されたアカウントがアクセス可能な資格情報やキーは潜在的に露出していると見なされ、調査結果に基づいてローテーションされるべきです。アカウントが管理者権限を持っていた場合、防御者はホスト全体およびそこに保存されている資格情報を使用してアクセス可能なシステム全体に調査を拡大するべきです。

公開概念実証資料は、組織が修正を適用する前に広範な攻撃の証拠を待つべきではないことを意味します。悪用の前提条件は脆弱な人口を絞りますが、これらの条件を満たすシステムは有効なパスワードの知識なしにリモートでアクセス可能です。