Network & Infrastructure2026-11-10約17分で読めます

OpenSSH CVE-2026-123158（sshole）ほか3件 — 11月10日の脆弱性まとめ（悪用確認4件）

OpenSSHのsshole（CVE-2026-123158）が悪用確認でKEV入り。Alpine等は10.6p2へ更新しsshd再起動、または鍵認証のみに。GPUStack 2.2.0、FreeSWITCH 1.11.3、Aspera Faspex 5.0.19 PL1も同日KEV追加。期限は11月12日。

脆弱性情報まとめセキュリティ ITリスク対策 CVE 脆弱性 Linux SSH

最優先は、11月6日にお伝えした OpenSSH の CVE-2026-123158（通称 sshole）が、11月9日に CISA の KEV（悪用が確認された脆弱性の一覧）に追加されたことである。実際に悪用されていることを意味する。対象は、musl libc を使い PAM を使わない Linux 上の sshd、つまり Alpine Linux、Alpine ベースのコンテナやクラウドイメージ、OpenWrt などである。該当する環境では、今日中に OpenSSH を修正版（10.6p2 相当）へ更新して sshd を再起動するか、更新できない間はパスワード認証を無効にする。Debian、Ubuntu、RHEL など glibc を使う一般的なサーバーは対象外である。次に急ぐのは、AI 基盤の GPUStack（2.2.0 へ）、IP 電話・通話基盤の FreeSWITCH（1.11.3 へ）、IBM Aspera Faspex 5（5.0.19 PL1 へ）を使っている会社である。

11月10日（JST）に確認した CISA の KEV カタログ（JSON フィード）、NVD、OpenSSH のリリースノート、Alpine Linux の告知、GPUStack と FreeSWITCH の GitHub セキュリティアドバイザリ、IBM のセキュリティ情報に基づく。明記のない点は「公表されていない」とする。本日の4件は、いずれも11月9日（米国時間）に KEV へ追加された。CISA が示した対応期限は4件とも11月12日である。なお KEV の「ランサムウェアでの利用」欄は、4件とも「不明（Unknown）」である。

今日の脆弱性一覧

製品	CVE	深刻度（CVSS）	悪用状況	対処（修正版）
OpenSSH（musl libc・PAM なしの Linux。Alpine など）	CVE-2026-123158（sshole）	8.1 High（CVSS 3.1。評価者は MITRE）	KEV に11月9日追加。悪用確認	OpenSSH 10.6p2。Alpine は apk upgrade のあと sshd を再起動
GPUStack	CVE-2026-102895	9.8 Critical（CVSS 3.1。評価者は GitHub）	KEV に11月9日追加。悪用確認	2.2.0
SignalWire FreeSWITCH	CVE-2026-116779	9.8 Critical（CVSS 3.1。評価者は GitHub）	KEV に11月9日追加。悪用確認	1.11.3
IBM Aspera Faspex 5	CVE-2026-123218	9.8 Critical（CVSS 3.1。評価者は IBM）	KEV に11月9日追加。悪用確認	5.0.19 PL1（Linux）

1. OpenSSH CVE-2026-123158（sshole）— 11月9日に悪用が確認され KEV に追加された

11月6日のまとめで取り上げた脆弱性である。11月6日のまとめの時点では、実環境での悪用は報告されていなかった。今回の新しい事実は、CISA が11月9日に KEV へ追加し、NVD の SSVC（CISA の評価）が Exploitation=active（悪用あり）になったことである。KEV の概要は「OpenSSH on Linux に、予期しない戻り値の扱いによる認証バイパスがある」（弱点の種類は CWE-394）で、対応期限は11月12日である。どの環境で、どの規模の悪用が起きているかは、公表されていない。

おさらいすると、NVD の記載では、musl libc を使い PAM を使わない Linux 上の OpenSSH 10.6p2 より前の版で、アカウントの設定によっては 256 文字から 1024 文字の長さのパスワードなら何でも受け入れられてしまう。パスワードでログインできないはずのアカウント（パスワード欄が "*" のもの）に、長い適当な文字列を入れるだけで入られ得る、ということである。深刻度は CVSS 3.1 で 8.1（High、評価者は MITRE、攻撃条件の複雑さは High）。報告者は Özgün Kültekin（Wakefield）である。

Alpine Linux の告知によると、影響を受けるのは次の条件がすべて重なったときである。

- openssh-server（PAM なしのビルド）を使っている、または openssh-server-pam を使い UsePAM no にしている
- PasswordAuthentication が有効（OpenSSH の既定は有効）
- パスワード欄が "*" のアカウントが1つ以上ある（Alpine のベースイメージの root、鍵専用のユーザー、ディレクトリ連携のユーザー、tiny-cloud イメージの alpine ユーザーなど）
- $5$ か $6$ のパスワードハッシュを持つローカルアカウントが1つ以上ある

影響しないのは、openssh-server-pam を UsePAM yes で使う構成、PasswordAuthentication no にしている環境、ロック済みのアカウント（"!"）、sshd を動かしていないコンテナである。glibc を使う Debian、Ubuntu、RHEL なども対象外である。Alpine の影響版は 3.21 から 3.24、edge、およびサポート終了の 3.16 から 3.20 である。

修正版は OpenSSH 10.6p2（11月5日リリース）である。OpenSSH チームはこれを「critical security workaround」と位置づけ、根本原因は sshd の外（musl の crypt()）にあるが、sshd 側で回避する、と説明している。Alpine の修正版パッケージ（openssh）は次のとおりである。

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

更新後は、動いている sshd を再起動する。更新だけでは再起動されない。更新できない間は、鍵認証で入れることを確認したうえで、パスワード認証を無効にする（回避策）。作業中は、いま接続しているセッションを閉じない。

# 更新して sshd を再起動（Alpine）
apk upgrade -U -a
rc-service sshd restart

# 回避策: パスワード認証を無効にする
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
# sshd_config 本体や Match ブロック内に PasswordAuthentication yes があれば no に直す
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication   # passwordauthentication no と出ればよい

悪用が確認されたため、すでに入られていないかの確認が重要になる。Alpine の告知は、次を挙げている。心当たりのないログインが残っていて、侵害を否定できない場合は、そのサーバーは侵害されたものとして扱う。

- /var/log/messages で、パスワードを持たないアカウント（alpine、root、鍵専用のユーザーなど）への "Accepted password for" の記録を探す
- doas の使用履歴、最近作られたユーザー、最近変更されたファイル、authorized_keys を確認する

専用の解説はOpenSSH CVE-2026-123158（sshole）の確認と対処にまとめている。公式: OpenSSH リリースノート、Alpine の告知、修正コミット、NVD

2. GPUStack CVE-2026-102895 — 認証なしで管理者になれ、コマンドも実行される（CVSS 9.8）

GPUStack は、GPU クラスタを管理し、AI モデルを提供するためのオープンソースの基盤である。GitHub のセキュリティアドバイザリと NVD によると、2.2.0 より前の版で、リクエストの送信元がループバック（127.0.0.1）に見えると、組み込みの管理者として扱われる（force_auth_localhost が false の場合。これが既定値）。外部からのリクエストが 127.0.0.1 から来たように見える経路が2つある。同じ機械上のリバースプロキシ経由（すべてのリクエストが 127.0.0.1 から届く形になる）と、クライアントが偽造した X-GPUStack-Real-IP ヘッダーである。

その結果、認証なしで管理者の操作ができる。NVD と KEV の記載では、ユーザーやモデルの変更、永続的な管理者 API キーの作成、ワーカーやクラウド事業者の秘密情報の漏えい、POST /v2/inference-backends/from-yaml を通じたコードの実行が可能になる。深刻度は CVSS 3.1 で 9.8（評価者は GitHub。弱点は CWE-287、CWE-290、CWE-346）である。アドバイザリと NVD は、2.1.1 の環境に対する実環境での悪用が観測されたと記している。

平易に言うと、社内の AI 基盤に、外から「自分は管理者本人（この機械の中の人）」と名乗るだけで入れてしまう問題である。クラウドの認証情報も漏れ得るため、悪用された場合の被害は大きい。影響を受けるのは 2.2.0 より前の全版で、修正版は 2.2.0 である。2.2.0 は、ループバック送信元を管理者とみなす経路を削除し、クライアント IP と転送ヘッダーの扱いを強化している。

すぐ更新できない間の回避策として、アドバイザリは次の3つを挙げている。force_auth_localhost を true に設定する。手前のプロキシで X-GPUStack-Real-IP ヘッダーを取り除く。API を信頼できないネットワークに出さない。さらに、すでに攻撃を受けていないか、管理者 API キーやユーザーに身に覚えのないものがないかを確認し、あればキーを失効させ、ワーカーやクラウドの認証情報を更新する。

# 版の確認（pip で入れた場合）
pip show gpustack | grep -i '^version'
# コンテナの場合は、使っているイメージのタグを確認する
docker ps --format '{{.Names}} {{.Image}}' | grep -i gpustack

公式: GitHub アドバイザリ GHSA-gj9m-f8ph-pmhr、NVD

3. SignalWire FreeSWITCH CVE-2026-116779 — SIP のメッセージ1通でコマンドを実行される（CVSS 9.8）

FreeSWITCH は、IP 電話や通話システムを構築するためのオープンソースの通信基盤である。GitHub のセキュリティアドバイザリと NVD によると、1.11.2 以前（1.11.3 より前）に、外部から届く SIP の MESSAGE の宛先（To のユーザー部）を「+」で分け、左側をチャットのプロトコルとして扱う処理がある。ここで api を選ぶと、FreeSWITCH の API 実行機能に渡り、OS コマンドを含む API コマンドを、サービスの権限で実行できる。

影響は、設定や認証情報の漏えい、通話の不正な制御、コマンドの実行である。深刻度は CVSS 3.1 で 9.8（評価者は GitHub。弱点は CWE-77、CWE-78、CWE-749）。アドバイザリと NVD は、実環境での悪用が観測されたと記している。MESSAGE を受け付ける SIP プロファイルは、既定で影響を受ける。MESSAGE の認証を有効にしても、登録済みのアカウントなら悪用できる。標準設定のディレクトリには、パスワードのないユーザー（default ユーザーなど）があり、その場合は認証なしでも通る。

修正版は 1.11.3 である。api を選ぶ要求を 403 で拒否し、ログに残す。api を許す設定（enable-chat-api-proto）は、既定で無効である。更新できない間の回避策としてアドバイザリが挙げる、経路を完全に塞ぐ唯一の手段は、チャットが不要な SIP プロファイルで enable-chat=false を設定することである。MESSAGE 認証の有効化、パスワードのないディレクトリユーザーの削除、disable_system_api_commands=true の設定は、リスクを下げるが経路は塞がない。

# FreeSWITCH の版の確認
freeswitch -version
# 回避策（SIP プロファイルの設定）
# <param name="enable-chat" value="false"/>

FreeSWITCH を自社で運用していなくても、IP 電話やコールセンター用の製品が内部で使っている場合がある。使っているかどうかは、導入業者か製品の提供元に確認する。公式: GitHub アドバイザリ GHSA-mg63-h38w-8p9p、NVD

4. IBM Aspera Faspex 5 CVE-2026-123218 — 権限の確認を回避され、管理者権限を奪われ得る（CVSS 9.8）

IBM Aspera Faspex は、大容量ファイルの転送に使うソフトウェアである。IBM のセキュリティ情報（初回公開は11月7日）によると、Faspex 5 の 5.0.0 から 5.0.19 に、認可された利用者が細工したメッセージを送ることで、ユーザーの認可を回避し、管理者の権限をすべて得られる欠陥がある。弱点は CWE-863（不適切な認可）である。深刻度は CVSS 3.1 で 9.8（評価者は IBM）。KEV の概要は「認証済みの利用者が認可を回避し、権限昇格を起こせる」となっている。

補足すると、説明文は「認可された利用者」を前提にしているが、IBM が付けた CVSS のベクターは、権限不要（PR:N）で評価されている。実際にログインなしで悪用できるかは、公表された情報だけでは分からない。ログインできる利用者が管理者になれる、と受け止めて対処するのが安全である。IBM のセキュリティ情報には、回避策は載っていない。

対処は、Linux 版を 5.0.19 PL1 に更新することである。IBM の手順（コンテナイメージのパッチ適用）に従い、faspex-core のイメージが 5.0.19（1ce4b13、Fix Pack: 1）であることを確認する。外部の取引先とファイルをやり取りするために Faspex を公開している場合は、優先して対処する。この版数の確認は、IBM の情報にある記載に基づく。

公式: IBM セキュリティ情報、NVD

非IT担当者向け: 今日やることチェックリスト

- 社内のサーバーやクラウドで、Alpine Linux（Docker の alpine イメージを含む）を使っていないかを担当者に聞く。使っていて sshd を動かしていれば、OpenSSH の更新と sshd の再起動を依頼する。ルーターなど OpenWrt の機器は、提供元の更新情報を確認する
- 更新が済むまでの間は、パスワード認証を無効にして鍵認証だけにするよう依頼する
- 悪用が確認されているため、該当する環境では、心当たりのないログインがないか（ログ、新しいユーザー、authorized_keys）の確認も依頼する
- 社内で AI 基盤の GPUStack を試験的にでも動かしていないかを聞く。あれば 2.2.0 以上への更新と、管理者 API キーの棚卸しを依頼する
- IP 電話やコールセンターの基盤に FreeSWITCH を使っていないかを、導入業者に確認する。あれば 1.11.3 への更新を依頼する
- 大容量ファイルの転送に IBM Aspera Faspex 5 を使っていないかを聞く。あれば 5.0.19 PL1 への更新を依頼する
- 該当する製品がなければ、今回は対象外だと記録しておく

- OpenSSH CVE-2026-123158（sshole）の確認と対処
- 11月6日の脆弱性まとめ（OpenSSH の初報）
- 11月9日の脆弱性まとめ
- 中小企業のパッチ・アップデート管理ガイド（2026年版）

出典

- CISA: Known Exploited Vulnerabilities Catalog
- OpenSSH リリースノート
- Alpine Linux: openssh-server のパスワード認証バイパス
- openssh-portable: 修正コミット
- NVD: CVE-2026-123158
- GitHub アドバイザリ: GHSA-gj9m-f8ph-pmhr（GPUStack）
- NVD: CVE-2026-102895
- GitHub アドバイザリ: GHSA-mg63-h38w-8p9p（FreeSWITCH）
- NVD: CVE-2026-116779
- IBM: Aspera Faspex 5 のセキュリティ情報
- NVD: CVE-2026-123218

よくある質問

KEV に載ると、何が変わるのですか。

KEV は、実際に悪用された脆弱性の一覧です。載った時点で、「いつか狙われるかもしれない」から「すでに狙われている」に状況が変わります。米国の連邦機関には対応期限（今回は11月12日）が設定されますが、日本の民間企業に法的な義務はありません。ただ、攻撃者が実際に使っている脆弱性という意味で、優先順位を上げる根拠になります。

Debian や Ubuntu のサーバーで OpenSSH を使っています。sshole の影響はありますか。

ありません。この欠陥は、musl libc を使い PAM を使わない Linux の構成で起きます。glibc を使う Debian、Ubuntu、RHEL などは、Alpine の告知でも対象外とされています。ただ、Alpine ベースの Docker イメージの中で sshd を動かしていないか、OpenWrt などの機器がないかは確認してください。

GPUStack をリバースプロキシの後ろに置いています。安全ですか。

むしろ注意が必要です。アドバイザリによると、同じ機械上のリバースプロキシ経由だと、すべてのリクエストが 127.0.0.1 から届く形になり、管理者として扱われます。2.2.0 に更新するか、force_auth_localhost を true にしてください。X-GPUStack-Real-IP ヘッダーも、手前のプロキシで取り除きます。

FreeSWITCH を使っているかどうかが分かりません。

自社で通話基盤を構築していなければ、直接は使っていない可能性が高いです。ただ、IP 電話やコールセンター向けの製品が内部で使っている場合があります。導入業者か製品の提供元に、FreeSWITCH を使っているか、使っていれば版が 1.11.3 以降かを確認してください。

IBM Aspera Faspex の CVSS が「権限不要」なのに、説明は「認可された利用者」なのはなぜですか。

IBM の説明文と、IBM が付けた CVSS のベクターが一致していません。公表された情報だけでは、ログインなしで悪用できるかは判断できません。ログインできる利用者が管理者権限を得られる、という前提で、5.0.19 PL1 への更新を進めてください。

この記事に関連する無料ツール（登録不要・その場で結果）

ホシュ診断（保守リスク健康診断）8つの質問でサイト・システムの保守リスクを3段階判定

お気軽にご相談ください

お問い合わせ