FreeSWITCHのSIPメッセージでコマンド実行の悪用確認｜1.11.3への更新とチャット設定を点検

FreeSWITCHのSIPメッセージ処理に、サーバー上のコマンド実行につながる脆弱性CVE-2026-116779があり、CISAは2026年11月9日に既知悪用脆弱性カタログ（KEV）へ追加しました。対象は1.11.3未満です。ブラウザー通話や会議サービスの裏側でFreeSWITCHを運用する担当者は、1.11.3以降への更新と、SIPプロファイルごとのチャット設定を優先して確認してください。

更新までの間、受信SIPチャットが不要なプロファイルではenable-chat=falseが公式の緩和策です。MESSAGEの認証を有効にすることや、通常の着信ACLを厳しくすることだけで対策済みとは判断できません。本稿は11月10日確認時点のニュースと対応解説で、以下の点検順序は公式資料を踏まえた本サイトの提案です。

今回の新情報と修正版の公開日は別

CISAのKEV公式JSONでは、本件の追加日は11月9日、対応期限は11月12日、ランサムウェアへの利用状況はUnknownです。期限は米国の対象機関向けの要件に関わる情報で、日本の全利用者に同じ法的義務があるという意味ではありません。登録日を攻撃の開始日や修正版の公開日へ置き換えないでください。

FreeSWITCHの公式セキュリティ告知は10月28日公表で、実環境での悪用観測を記載しています。一方、1.11.3の公式リリースは8月28日に公開されており、重大な修正を含むため速やかな更新を推奨しています。今回は新しい修正版の登場ではなく、既存の修正を取り込んでいない環境への対応を改めて急ぐ局面です。

CVE公式レコードは11月5日の公開、11月9日の更新を記録しています。CNAの評価はCVSS v3.1で9.8、Criticalです。更新にはCISAの悪用情報も含まれますが、被害組織、攻撃規模、個別環境での侵害時刻まで確定する資料ではありません。KEVのUnknownも、ランサムウェア利用がないことの証明にはなりません。

Web通話サービスでもSIPの受け口を調べる

公式のWebRTC over SIP解説によると、FreeSWITCHのブラウザー通信には、mod_sofiaを使うSIP over WebSocketと、mod_vertoを使うVertoという異なる方式があります。JsSIPやSIP.jsなどの標準SIPクライアントを用いる構成では、WebSocket上にSIPのメッセージが運ばれます。Web画面のHTTPSだけを確認しても、通話サーバーの受付経路を調べたことにはなりません。

本件の主題はmod_sofiaの受信SIP MESSAGEです。WebRTCという名前だけで、すべてのWeb会議製品やVerto利用環境を同じ影響と断定しないでください。自社サービスがどのモジュール・版・プロファイルを使うかを先に確定します。外部製品にFreeSWITCHが組み込まれている場合は、その製品の提供元が案内する修正の取り込み状況も必要です。

Sofiaプロファイルの公式マニュアルは、プロファイルごとにIPアドレス、ポート、認証、ルーティングなどを持つと説明しています。標準のinternalプロファイルにはWebRTC向けのWS・WSSの受け口もあります。名称がinternalだから外部から届かないと推定せず、リバースプロキシ、負荷分散、ファイアウォールを含め、実際にどの接続がどのプロファイルへ届くかを確認します。

メッセージ配送が管理用APIへつながる問題

CVEレコードが示す原因は、受信MESSAGEのToユーザー部分を「+」で分け、その左側をチャットプロトコルの選択に使う処理です。ここでapi側が選ばれるとFreeSWITCH APIの実行へ到達します。通常のチャットの配送先を選ぶ入力が、サーバーの制御処理を選べてしまう境界の不備です。単にメッセージ本文を表示する際の問題ではありません。

成立すると、FreeSWITCHプロセスの権限でコマンド実行、設定・資格情報の露出、通話の制御につながります。OSのroot権限が必ず得られるとは記載されていません。プロセスの実行ユーザーに加え、読める設定、接続できる外部サービス、発信できる回線を確認することが、実際の影響範囲を判断する手掛かりになります。

攻撃には対象プロファイルへMESSAGEが受け付けられる必要があります。認証が要求される構成でも、登録可能な一般アカウント一つで足りると公式告知は説明しています。また、標準設定由来のパスワード情報を持たないディレクトリーユーザーが残る構成では、認証の障壁が失われる場合があります。「登録利用者だから管理コマンドも許可してよい」とは扱えません。

緩和策で閉じる経路と残る経路を分ける

公式告知では、チャットを必要としない全プロファイルでenable-chat=falseとする方法を案内しています。これは受信MESSAGEによるチャット配送全体を止めます。音声通話だけのつもりでも、業務でメッセージ機能を使っていないかを確認してから適用します。特定の一プロファイルだけ変更し、別の受付先を残さないことが重要です。

一方、auth-messagesだけでは一般アカウントによる実行経路が残り、disable_system_api_commands=trueだけでも他のAPIへの経路が残ります。また、告知はinbound ACLがMESSAGEを対象にしないと明記しています。いずれも補助的な制限を、本件の修正やチャット停止の代替として数えないでください。

設定例は、チャットを使わない対象プロファイルの既存<settings>へ追加する一行です。これは新しい設定ファイル全体ではありません。配備元のテンプレートや管理ツールが設定を上書きする構成では、稼働ホストの手修正だけでなく、次の再配備でも維持されるよう管理元へ反映します。

<param name="enable-chat" value="false"/>

1.11.3の修正を古い設定で開き直さない

mod_sofiaの公式修正コミットは、プロファイル単位のenable-chat-api-protoを追加しています。未設定ではapiへの配送を許可せず、該当要求には403を返して送信元と要求コマンドをログへ残す実装です。通常のチャットと管理APIへの配送を分ける修正であり、チャット機能を全面停止する緩和策とは動作が異なります。

比較は大文字小文字を区別しない形で実装され、標準プロファイルの設定例はコメントアウトされています。更新後に以前の動作を取り戻すため、理由を確認せずenable-chat-api-proto=trueへ変えると、この経路を再び許可することになります。本サイトでは通常のメッセージ配送だけが必要な環境では有効化せず、設定管理の差分確認項目へ入れることを勧めます。

リリースノートにはmod_sofiaとmod_verto双方のAPIチャット制御の追加が記されていますが、これを根拠に本件CVEの影響条件をVerto全体へ拡張しません。また1.11.3ではDebian 11 Bullseyeが対象から外れています。古いOS上の独自ビルドを続ける場合は、単純なパッケージ更新で済むか、実行基盤の移行が必要かを提供元の配布条件と照合します。

反映確認は全ノードと実際の受付先で行う

本サイトが提案する作業順は、まず構成を記録し、更新・設定変更の対象を決め、通話への影響を調整して反映し、全ノードの稼働版と受付設定を読み直す流れです。台帳にはホストやコンテナの識別子、取得したビルド、プロファイル名、接続元、チャットの必要性、変更担当を残します。パッケージの更新成功だけで、稼働中のプロセスまで切り替わったと判断しないでください。

複数ノードがある環境では、更新済みノードだけへ接続した確認で完了にせず、旧ノードや待機系がサービスへ戻る経路も点検します。プロファイルの再起動などが必要な場合は、既存通話への影響を管理手順で確認します。任意コマンドを実行する攻撃用メッセージを、本番で対策確認のために送る必要はありません。

機能確認では、管理下のテストアカウントを使い、通常の登録・発着信・必要なチャットが期待どおりかを分けて記録します。チャットを停止した構成では、その機能が利用できなくなることも確認対象です。予期せぬ不具合があれば、api経路を全面的に開き直す前に、接続先、設定の配布漏れ、認証、モジュールのロード状況を順に調べます。

公式のモジュール管理資料は、ビルド・導入されたモジュールと、modules.conf.xmlで実際にロードするモジュールを区別しています。ファイルが存在するだけで稼働中とは限らず、設定に書かれていても導入されていなければロードに失敗します。独自ビルド環境では、版の表示に加え、想定するmod_sofiaと必要な業務モジュールが実際に動いていることを確認します。

拒否ログと過去の侵害調査を混同しない

修正後の拒否ログは、新しい制御が要求を止めたことを調べる材料になります。ただし、それがないことだけで過去に攻撃されていないとは判断できません。本サイトでは既存ログを保持し、想定外の発信、設定変更、未知のプロセス、資格情報の利用などを時系列で確認することを提案します。これは本件専用の確定IOCではなく、コマンド実行の影響を調べる観点です。

資格情報や設定の持ち出しが疑われる場合は、更新完了と、漏れた可能性がある秘密情報の失効・再発行を別の作業として管理します。ログを外部へ共有する際も、通話先や利用者情報、認証情報が含まれないかを確認してください。今回優先すべきなのは、悪用情報を踏まえて未修正の受付経路を減らし、修正後もAPIチャットの許可を意図せず戻さないことです。