FreeSWITCH 脆弱性 CVE-2026-116779：SIP MESSAGEからのコマンド実行と1.11.3への更新

オープンソースの電話交換ソフトFreeSWITCHで、SIPのMESSAGEを1通送るだけでサーバー上のコマンドを動かせる欠陥CVE-2026-116779が、2026年11月9日にCISAの悪用確認済み脆弱性カタログ（KEV）へ追加されました。対象は1.11.2以前で、初期設定のまま運用しているIP-PBXやコールセンター基盤がそのまま該当します。この記事では、宛先の「api+」がAPI実行に化ける原因コード、手元の版と設定を調べるコマンド、更新できない環境の暫定策、1.11.3への更新と新しい設定、侵害を疑うときの確認を順に整理します。記述の基準は、11月10日時点で公開されている情報です。

まとめ：FreeSWITCHは1.11.3へ更新し、それまではSIPチャットを止める

恒久対策は1.11.3への更新です。1.11.3では、SIP MESSAGEから「api」のチャットプロトを選ぶ経路が既定で拒否されます。更新に数日かかる環境は、SIPチャットを使わないプロファイルでenable-chatをfalseにして、今日中に経路を閉じてください。

パスワードの無いディレクトリユーザーが残っている環境は、認証なしで攻撃が成立します。インターネットからSIPを受けている環境では、更新と並行して侵害の有無も調べます。米国連邦機関向けのKEVの是正期限は11月12日です。自社だけで判断がつかない場合は、脆弱性診断・セキュリティ診断で公開範囲と設定の確認を受け付けています。

CVE-2026-116779でSIP MESSAGEの宛先がAPIコマンドになる仕組み

GitHubのアドバイザリGHSA-mg63-h38w-8p9pは、原因を「メッセージ配送用のプロトと、コマンド実行用のプロトを区別していなかったこと」と説明しています。

宛先ユーザーを「+」で分割しapiプロトを選べたsofia_presence.c

SIPプロファイルを担うmod_sofiaは、受け取ったMESSAGEの宛先（To）ユーザーを+で2つに分け、左側をチャットプロトの名前として扱います。たとえば宛先が[email protected]なら、左側のapiがプロトの名前です。

このapiは、mod_dptoolsが登録するチャットインターフェースです。受け取った宛先をswitch_api_execute()へ渡すため、右側の文字列がFreeSWITCHのAPIコマンドとして実行されます。選べるプロトに制限は無く、systemのようにOSコマンドを動かすAPIも到達先に含まれる仕組みです。mod_luaが読み込まれていれば、Luaのコードを直接実行する経路にもなります。

初期設定のinternal・externalプロファイルが対象になる条件

SignalWire公式のSIPプロファイルの解説では、enable-chatの既定値はtrueです。標準の設定（vanilla）は内線用のinternal、外線用のexternalのどちらでもこの値を変えていません。追加の設定をしなくても攻撃の対象になります。

攻撃側に必要なのは、MESSAGEを1通受け付けさせることだけです。MESSAGEの認証は1.10.7から既定で有効ですが、そのプロファイルの内線・端末・トランクのアカウントが1つあれば足ります。アドバイザリによると、受信側のACLはMESSAGEを対象にしないため、ACLを絞っても対象から外れません。

パスワード無しのdefaultユーザーで認証が素通りになる理由

標準設定のdefault.xmlには、passwordもa1-hashも持たないdefaultユーザーが定義されています。こうしたユーザーは、allow-empty-passwordをfalseにしない限り認証に通ってしまいます。Skinny用のサンプルskinny-example.xmlも同じ形です。

導入時のサンプルを消さずに本番へ持ち込んだ環境は、アカウントを持たない外部の相手からでも攻撃が成立します。後述のgrepで、このファイルが残っていないかを必ず確かめてください。

影響版1.11.2以前と修正版1.11.3、KEV追加までの経緯

修正版は早く出ていました。1.11.3のリリースは2026年8月28日です。アドバイザリの公開は10月28日、NVDへの登録は11月5日でした。NVDのデータに頼るスキャナでは、11月まで検出されなかった可能性があります。

CVSS 9.8と悪用確認、11月12日が是正期限になった経緯

CVSS 3.1の基本値は9.8で、ネットワーク越しに、利用者の操作なしで成立します。アドバイザリとNVDはどちらも、実際の悪用を確認したと明記しています。影響はFreeSWITCHのプロセス権限でのOSコマンド実行、設定と認証情報の読み出し、通話の任意操作です。

CISAのKEVは11月9日に本件を追加し、是正期限を11月12日としました。この追加では、侵害の有無を確かめる手順（Forensics Triage）も求められています。期限の決まり方はBOD 26-04の是正期限の仕組みで整理しています。

1.11.1以前に残る別のcritical 3件と1.11.3でまとめて塞ぐ理由

FreeSWITCHのセキュリティアドバイザリ一覧には、10月26日以降に20件を超える公表が並んでいます。本件以外の多くは1.11.1以前が対象で、1.11.2で直っています。

表のCVE-2026-116785は、mod_xml_rpcのWebSocketで認証前にヒープへ書き込める欠陥です。1.11.1以前の環境は、本件と合わせてこれらにも該当します。1.11.2へ上げても本件は残るので、更新先は1.11.3に固定してください。

手元のFreeSWITCHで版番号とプロファイル設定を調べるコマンド

確認したい項目は3つです。動いている版、各プロファイルのenable-chat、パスワードの無いユーザーの有無です。どれも読み取りのみで、通話を止めません。

fs_cliのversionとsofia statusで版と公開中のプロファイルを確認

公式のCLIリファレンスにあるversionとsofia statusを、サーバー上で実行します。

# 動いている版（1.11.3より前なら対象）
fs_cli -x "version"

# 読み込まれているプロファイルと待ち受けアドレス
fs_cli -x "sofia status"

2つ目の結果で、グローバルIPやインターネット向けのポートに結び付いたプロファイルを洗い出します。そこが最優先の対応先です。SBCやクラウドPBXの裏側でFreeSWITCHを動かしている場合も、前段がMESSAGEを素通しする限り対象になります。

enable-chatの値とpassword無しユーザーをgrepで洗い出す手順

# enable-chat と auth-messages の明示設定（何も出なければ既定の true）
grep -n -E 'enable-chat|auth-messages' /etc/freeswitch/sip_profiles/*.xml

# password も a1-hash も持たないユーザー定義ファイル
grep -L -E 'name="(password|a1-hash)"' /etc/freeswitch/directory/default/*.xml

パスは公式パッケージの設定ディレクトリを前提にしています。ソースから入れた環境は/usr/local/freeswitch/confなどに置き換えてください。2つ目のgrepでdefault.xmlやskinny-example.xmlが出たら、使っていないことを確かめてから削除します。

あわせて、標準のvars.xmlにあるdefault_passwordが初期値の1234のままになっていないかも見ます。内線1000〜1019はこの値をパスワードに使うため、残っていれば総当たりで1つ目のアカウントを取られます。

すぐ更新できない環境でSIPチャットを止める暫定策と効かない対策

アドバイザリが確実な暫定策として挙げるのは、enable-chatをfalseにすることだけです。MESSAGEはプロトの解析より前に捨てられます。

enable-chatをfalseにする設定とrescanでの反映手順

SIPチャットを使っていないプロファイルのsettingsに、次の1行を足します。

<!-- /etc/freeswitch/sip_profiles/internal.xml の <settings> 内 -->
<param name="enable-chat" value="false"/>

# XMLを読み直してプロファイルに反映（既存の通話は維持される）
fs_cli -x "sofia profile internal rescan"
fs_cli -x "sofia profile external rescan"

CLIリファレンスでは、rescanは既存の通話を保ったまま設定を読み直す操作です。1.11.3のソースでは、rescanでもenable-chatを含むパラメータの読み込み処理を通ります。反映されたか不安なら、通話の少ない時間帯にrestartを選んでください。こちらはプロファイルを止めて起動し直すので、そのプロファイルの通話は切れます。

MESSAGEの認証要求とsystem API制限だけでは塞げない理由

代わりになりそうな設定が2つありますが、どちらも単独では経路を閉じません。重みが違うので順に書きます。

1つ目はauth-messagesです。MESSAGEに認証を求めても、内線や端末のアカウントを1つ持つ相手には通ります。パスワード無しのユーザーを消したうえでも、攻撃が「認証済みの相手からのコマンド実行」に変わるだけです。2つ目のdisable_system_api_commandsはsystemコマンドを消しますが、モジュールの読み込みや発信の操作など他のAPIには届いたままです。設定する価値はありますが、更新の代わりにはなりません。

1.11.3へ更新して新設定enable-chat-api-protoを確かめる手順

修正コミット7015f6aは、プロファイル単位の新しいパラメータenable-chat-api-protoを追加しました。明示的にtrueにしない限り、apiプロトを選んだMESSAGEは403で拒否されます。

SignalWireのパッケージリポジトリから1.11.3を入れる更新手順

公式のGetting Startedにあるとおり、Debian向けパッケージの取得にはSignalWireの個人アクセストークンが必要です。リポジトリ登録が済んでいる環境なら、次の流れで更新します。

apt-get update
# 候補の版が 1.11.3 以上になっているかを先に見る
apt-cache policy freeswitch
apt list --upgradable 2>/dev/null | grep freeswitch

apt-get install --only-upgrade $(dpkg-query -W -f='${Package}\n' 'freeswitch*')
systemctl restart freeswitch
fs_cli -x "version"

候補の版が1.11.3より古いままなら、リポジトリの指定先やトークンの期限を見直します。ソースからビルドしている環境は、タグv1.11.3を取得して作り直してください。systemctl restartは全通話を切るので、利用の少ない時間帯に行います。

更新後に403で拒否されたMESSAGEをログで確認する方法

1.11.3は、apiプロトを選んだMESSAGEを拒否すると、送信元とコマンドを含むWARNINGを出します。更新後に次の文字列で検索すれば、攻撃が続いているかが分かります。

# ログファイルの場所は環境に合わせて置き換える
grep "addressed to the 'api' chat proto" /var/log/freeswitch/freeswitch.log

社内の監視ツールなど、正当な用途でapiプロトを使っていた場合は、信頼できる相手だけが届くプロファイルに限ってenable-chat-api-protoをtrueにします。リリースノートによると、WebRTC向けのmod_vertoにも同じ名前の設定が入りました。

判断：侵害を疑うべきFreeSWITCHと更新だけで済ませてよい条件

更新だけで終えてよいのは、MESSAGEを受け付けるプロファイルが社内網やVPNの内側にしか無く、パスワード無しのユーザーも無かった環境です。それ以外は、更新と並行して侵害の確認を行います。

外部向けプロファイルにdefaultユーザーが残っていた環境の扱い

インターネットから届くプロファイルでenable-chatが有効なまま、default.xmlが残っていた環境は、誰でもコマンドを実行できた期間があったと見なします。KEVへの追加は実際の攻撃が確認されたことを意味し、公開範囲を洗うだけでは安全と言えないからです。

まだ通信を記録できるうちに、平文のSIPを流れるMESSAGEを確かめておく方法もあります。

# 5060番の平文SIPで「api+」宛てのMESSAGEを探す（TLS・WSSは見えない）
tcpdump -n -A -s 0 -i any 'port 5060' | grep -i -E '^(MESSAGE|To:).*api\+'

これは今後の試行を見る手段で、過去の侵入を否定する材料にはなりません。見送ってよい対策もはっきりさせます。SIPのファイアウォールで特定の文字列だけを止める方式は、TLSや表記の揺れで抜けるため採用しません。

侵害が疑われる環境での認証情報の入れ替えと通話録音・CDRの漏えい確認順

1. FreeSWITCHの実行ユーザーで動いている見覚えのないプロセス、cron、外向きの通信を調べる
2. 設定ディレクトリと読み込まれているモジュールに、身に覚えのない変更が無いかを見る
3. キャリアやSIPトランクの認証情報、内線パスワード、Event Socketのパスワードを入れ替える
4. 発信履歴（CDR）に不審な国際発信や高額番号への発信が無いかを確かめる
5. 通話録音や顧客情報の読み出しが疑われる場合は、報告義務の該当性を判断する

3は痕跡が見つからなくても実施します。設定ファイルを読まれた可能性を否定できない以上、そこにある認証情報は漏れた前提で扱います。CTIシステムの構成のようにCRMと連携している基盤では、連携先のAPIキーも同じ扱いです。録音に個人情報が含まれる場合は、個人情報保護委員会への報告義務を確認してください。自前の交換機を運用し続けるか迷う場合は、クラウドPBXとの違いと導入判断も比較材料になります。

よくある質問

FreeSWITCHの脆弱性CVE-2026-116779について、運用の現場で迷いやすい点に答えます。

1.11.2に上げていれば対応は完了ですか？

完了ではありません。CVE-2026-116779の影響版は1.11.2以前で、修正は1.11.3です。1.11.2では10月下旬に公表された1.11.1以前向けの多数の欠陥が直っていますが、本件は残ります。11月10日時点では、1.11.3以上で動いていることをfs_cli -x "version"で確かめた時点を完了の基準にしてください。

SIPチャットを使っていなくても影響はありますか？

あります。enable-chatの既定値はtrueで、標準のinternal・externalプロファイルはどちらも有効のままです。使っているかどうかではなく、設定で明示的にfalseにしているかで判断します。設定ファイルをgrepして何も出なければ、有効になっています。

KEVの是正期限11月12日は日本の企業にも適用されますか？

KEVの是正期限は、BOD 26-04にもとづき米国の連邦政府機関に課されるものです。日本の民間企業に法的な拘束力はありません。ただ、KEVへの追加は実際の攻撃が確認されたことを意味します。インターネットからSIPを受けるFreeSWITCHは、同じ期限を目安に更新か暫定策を終えてください。

SBCやファイアウォールの内側にあれば安全ですか？

前段の機器がMESSAGEを転送していれば、内側にあっても届きます。アドバイザリによると、FreeSWITCH自身の受信ACLもMESSAGEを対象にしません。前段でMESSAGEを止めているかを設定で確かめ、確証が無ければenable-chatをfalseにするか、更新を優先してください。

悪用されたかどうかをログで判定できますか？

1.11.2以前には、apiプロトの選択を記録する処理がありません。標準のログだけで過去の悪用を判定するのは困難です。手がかりは、見覚えのないプロセスや設定変更、不審な発信履歴です。1.11.3へ更新した後は、拒否したMESSAGEがWARNINGとして記録されるので、その件数で攻撃が続いているかを追えます。

関連記事

• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：外部から届く要求を認可で絞る設計の基本をまとめています。
• ボイスチャットの実装方法｜WebRTC自作とVivox・Photon Voice等SDKの選び方【2026年10月】：音声通話を自前で組むときの構成と、SDKに任せる場合の比較です。
• CTIシステムとは？構成・導入形態3類型と費用構造、選定の判断基準を解説：交換機とCRMをつなぐ基盤の構成と、導入形態ごとの責任範囲を扱います。