---
title: "FreeSWITCH 脆弱性 CVE-2026-116779：SIP MESSAGEからのコマンド実行と1.11.3への更新"
url: "https://www.issoh.co.jp/tech/details/19561/"
published: 2026-11-10
updated: 2026-11-10
categories: ["セキュリティ"]
publisher: "株式会社一創"
---
# 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日です。自社だけで判断がつかない場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で公開範囲と設定の確認を受け付けています。
## CVE-2026-116779でSIP MESSAGEの宛先がAPIコマンドになる仕組み
[GitHubのアドバイザリGHSA-mg63-h38w-8p9p](https://github.com/signalwire/freeswitch/security/advisories/GHSA-mg63-h38w-8p9p)は、原因を「メッセージ配送用のプロトと、コマンド実行用のプロトを区別していなかったこと」と説明しています。
### 宛先ユーザーを「+」で分割しapiプロトを選べたsofia\_presence.c
SIPプロファイルを担うmod\_sofiaは、受け取ったMESSAGEの宛先（To）ユーザーを`+`で2つに分け、左側をチャットプロトの名前として扱います。たとえば宛先が`api+status@pbx.example.com`なら、左側の`api`がプロトの名前です。
この`api`は、mod\_dptoolsが登録するチャットインターフェースです。受け取った宛先を`switch_api_execute()`へ渡すため、右側の文字列がFreeSWITCHのAPIコマンドとして実行されます。選べるプロトに制限は無く、`system`のようにOSコマンドを動かすAPIも到達先に含まれる仕組みです。mod\_luaが読み込まれていれば、Luaのコードを直接実行する経路にもなります。
### 初期設定のinternal・externalプロファイルが対象になる条件
SignalWire公式の[SIPプロファイルの解説](https://developer.signalwire.com/freeswitch/users-and-endpoints/sip-profiles/)では、`enable-chat`の既定値は`true`です。標準の設定（vanilla）は内線用のinternal、外線用のexternalのどちらでもこの値を変えていません。追加の設定をしなくても攻撃の対象になります。
攻撃側に必要なのは、MESSAGEを1通受け付けさせることだけです。MESSAGEの認証は1.10.7から既定で有効ですが、そのプロファイルの内線・端末・トランクのアカウントが1つあれば足ります。アドバイザリによると、受信側のACLはMESSAGEを対象にしないため、ACLを絞っても対象から外れません。
### パスワード無しのdefaultユーザーで認証が素通りになる理由
標準設定の[default.xml](https://github.com/signalwire/freeswitch/blob/v1.11.3/conf/vanilla/directory/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のリリース](https://github.com/signalwire/freeswitch/releases/tag/v1.11.3)は2026年8月28日です。アドバイザリの公開は10月28日、[NVDへの登録](https://nvd.nist.gov/vuln/detail/cve-2026-116779)は11月5日でした。NVDのデータに頼るスキャナでは、11月まで検出されなかった可能性があります。
### CVSS 9.8と悪用確認、11月12日が是正期限になった経緯
CVSS 3.1の基本値は9.8で、ネットワーク越しに、利用者の操作なしで成立します。アドバイザリとNVDはどちらも、実際の悪用を確認したと明記しています。影響はFreeSWITCHのプロセス権限でのOSコマンド実行、設定と認証情報の読み出し、通話の任意操作です。
[CISAのKEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)は11月9日に本件を追加し、是正期限を11月12日としました。この追加では、侵害の有無を確かめる手順（Forensics Triage）も求められています。期限の決まり方は[BOD 26-04の是正期限の仕組み](https://www.issoh.co.jp/tech/details/18233/)で整理しています。
### 1.11.1以前に残る別のcritical 3件と1.11.3でまとめて塞ぐ理由
FreeSWITCHの[セキュリティアドバイザリ一覧](https://github.com/signalwire/freeswitch/security)には、10月26日以降に20件を超える公表が並んでいます。本件以外の多くは1.11.1以前が対象で、1.11.2で直っています。
| 識別子 | 内容 | 影響版 | 深刻度 |
| --------------- | ------------------------- | -------- | -------------- |
| CVE-2026-116779 | SIP MESSAGEからのAPIコマンド実行 | 1.11.2以前 | critical（悪用確認） |
| CVE-2026-116785 | mod\_xml\_rpc：認証前ヒープ書き込み | 1.11.1以前 | critical |
| CVE-2026-116790 | ICE接続確認でSTUNの完全性を検証しない | 1.11.1以前 | critical |
| CVE-2026-119293 | 平文RTPの送信元を検証せず学習する | 1.11.1以前 | critical |
| CVE-2026-116786 | SIP REFERからの変数注入によるコマンド実行 | 1.11.1以前 | high |
表の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リファレンス](https://developer.signalwire.com/freeswitch/reference/cli-and-api/)にある`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行を足します。
```
```
```
# 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](https://github.com/signalwire/freeswitch/commit/7015f6a73ab3d67fed5fbfc277ecfb88a74c2a86)は、プロファイル単位の新しいパラメータ`enable-chat-api-proto`を追加しました。明示的に`true`にしない限り、`api`プロトを選んだMESSAGEは403で拒否されます。
### SignalWireのパッケージリポジトリから1.11.3を入れる更新手順
公式の[Getting Started](https://developer.signalwire.com/freeswitch/foundations/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システムの構成](https://www.issoh.co.jp/column/details/17490/)のようにCRMと連携している基盤では、連携先のAPIキーも同じ扱いです。録音に個人情報が含まれる場合は、[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)を確認してください。自前の交換機を運用し続けるか迷う場合は、[クラウドPBXとの違いと導入判断](https://www.issoh.co.jp/column/details/13360/)も比較材料になります。
## よくある質問
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対策](https://www.issoh.co.jp/tech/details/18346/)：外部から届く要求を認可で絞る設計の基本をまとめています。
- [ボイスチャットの実装方法｜WebRTC自作とVivox・Photon Voice等SDKの選び方【2026年10月】](https://www.issoh.co.jp/tech/details/2292/)：音声通話を自前で組むときの構成と、SDKに任せる場合の比較です。
- [CTIシステムとは？構成・導入形態3類型と費用構造、選定の判断基準を解説](https://www.issoh.co.jp/column/details/17490/)：交換機とCRMをつなぐ基盤の構成と、導入形態ごとの責任範囲を扱います。
---
出典: [FreeSWITCH 脆弱性 CVE-2026-116779：SIP MESSAGEからのコマンド実行と1.11.3への更新]()（株式会社一創）