Sangoma SwitchvoxのCVE-2026-9586。認証不要の/paがPhoneIPをSQLへ連結する機構と悪用の実態

社内の電話を束ねるPBXは、いったん設置すると触る機会が減る装置です。保守業者の遠隔対応や在宅勤務の内線利用のために管理用のWeb画面をインターネット側へ出したまま、版を上げずに動かし続けている環境も珍しくありません。そのWeb画面に、認証を求めないまま外部の入力をデータベースへ渡す受け口が残っていたというのが、Sangoma SwitchvoxのCVE-2026-9586です。

CISAは2026年9月2日、実際の悪用の証拠にもとづいてこの脆弱性をKnown Exploited Vulnerabilities(KEV)カタログへ追加しました。CVSS v4.0は9.3 CRITICAL、NVDが一次評価として付けたCVSS v3.1は9.8 CRITICALです。修正版のSwitchvox 8.4.0.2は2026年7月14日に出ており、研究者が設置したハニーポットで悪用が観測されたのはその47日後の8月30日です。

この記事は、VoIP基盤やPBXを運用する情報システム担当に向けて、CVEレコード、NVD、CISAのKEVカタログとBOD 26-04、Sangomaのリリースノート、Horizon3.aiとSecurity Risk Advisors(SRA)のアドバイザリ、JVN iPediaという資料から、機構、影響範囲、侵害の確かめ方、遮断の手順を整理します。攻撃を再現する手順は扱いません。確認や設定変更は自組織が管理する機器に限って行ってください。他者の環境への試行は不正アクセス禁止法などの関連法令に違反する可能性があります。記述は執筆時点(2026年9月7日)に確認できた範囲に限ります。

一次資料で確認できる事実#

まず、参照できる値を並べます。CNAはSecurity Risk Advisors(短縮名SRA)で、CVEレコードのタイトルは「Unauthenticated SQL Injection Leading to Remote Code Execution in Switchvox SMB」です。

CVSSの2つの値は評価者も版も違います。v4.0の9.3はCNAであるSRAがSecondaryとして付けたもの、v3.1の9.8はNVDがPrimaryとして付けたものです。どちらも認証と利用者の関与を要さないネットワーク越しの攻撃で、機密性と完全性と可用性のすべてに高い影響が出るという評価で一致しています。数値の差は版ごとの計算式の違いによるもので、深刻度の解釈が割れているわけではありません。

CVEレコードのdescriptionは「An unauthenticated SQL injection vulnerability exists in Sangoma Switchvox SMB Edition 8.3 (104997). The /pa endpoint processes XML content beginning with <PolycomIPPhone> and directly concatenates the user-controlled PhoneIP value into PostgreSQL queries without sanitization or parameterization. An unauthenticated remote attacker can execute arbitrary SQL statements against the backend PostgreSQL database using a single crafted request, including database operations and remote code execution.」です。assignerShortNameはSRA、dateReservedは2026-05-26、datePublishedは2026-07-17です。

Sangomaの8.4.0.2リリースノートは、リリース日2026年7月14日、ビルド105309と記載しています。Issues Resolvedの欄には、CWE-89、CWE-22(パストラバーサル)、CWE-78(OSコマンドインジェクション)、CWE-269(不適切な権限管理)、CWE-918(SSRF)というCWEの並びに続けて、CVE-2026-9588(認証済みの格納型XSS)、CVE-2026-9587(認証済みのローカルファイルインクルージョン)、CVE-2026-9586(「Unauthenticated RCE via SQL Injection in SwitchVox 8.2.2.1」)、CVE-2026-9585(未認証の反射型XSS)が挙がっています。なおSangomaのセキュリティアドバイザリ一覧が案内するGitHubリポジトリ(sangoma/security-switchvox)には、執筆時点でCVE-2026-9586のアドバイザリは公開されておらず、公開されている最新はCVE-2026-45362(バックアップファイルからの資格情報漏えい)です。

PhoneIPの値がPostgreSQLのクエリへ文字列として埋まる機構#

Switchvoxには、対応する電話機が着信や発信といったイベントの通知を受け取れるようにする機能があります。Horizon3.aiのアドバイザリによれば、この通知を扱うのがPhoneAppsHandler.pmで、公開されるパスが/paです。名前のとおり電話機向けのアプリ連携(Phone Apps)用の受け口で、ここへXMLのメッセージがPOSTされます。

処理の流れは次のとおりです。リクエストの本体が<PolycomIPPhone>という要素で始まるとき、ハンドラはそれ以外の中身を検証しないままXMLとして受け付けます。続いてXML::SimpleのXMLin()でパースし、PhoneIPの値を取り出します。取り出した値は検証されないまま、次の形のPostgreSQLのクエリへ文字列として連結されます。

-- 機構の説明のための、連結が起きる箇所の形
SELECT proposed_extension FROM auto_phone_config WHERE ip_address = '<PhoneIPの値>'

値はシングルクオートで囲まれた文脈に置かれます。プレースホルダへ束縛するのではなく、文字列としてSQLの一部になるため、送り込んだ値の中の引用符がそのままSQLの構文として解釈されます。ここがCWE-89そのものの形です。

問題を大きくしているのが、その先です。PostgreSQLにはCOPY ... TO PROGRAMという、クエリの結果をOSのコマンドへ渡す機能があります。データベースのスーパーユーザー権限で実行できる場合、SQLの実行がそのままOSコマンドの実行になります。Horizon3.aiは、この経路を通じてシェルコマンドが動き、リバースシェルの確立に至ることを報告しています。SQLインジェクションが「データベースの中身が読まれる」で終わらず、ホストの掌握まで届くのはこの機能を経由するためです。

そして/paは認証を求めません。電話機との連携のための経路として、ログインを介さずにリクエストを受け付けます。Horizon3.aiは注入されたSQLがPostgreSQLのスーパーユーザー権限で実行されることも記載しています。攻撃に必要なのは、SwitchvoxのWebインターフェースへネットワーク的に到達できることだけになります。

同じ8.4.0.2では、CVE-2026-9586のほかに未認証の反射型XSS(CVE-2026-9585)、認証済みのローカルファイルインクルージョン(CVE-2026-9587)、認証済みの格納型XSS(CVE-2026-9588)が直っています。Horizon3.aiが2026年4月にSangomaへ報告したのは12件です。またリリースノートのCWEの並びには、パストラバーサル、OSコマンドインジェクション、不適切な権限管理、SSRFも挙がっています。リリースノートはCWEの列挙と個々のCVEの対応関係を示していないため、どのCWEがどの報告に紐づくかまでは読み取れません。それでも、この版で相当数の修正がまとめて入ったことは読み取れます。KEVに載ったのはCVE-2026-9586だけですが、更新の目的をこの1件の解消に限定して考えないほうが実態に合います。

Horizon3.aiの公開資料は、この機能を「対応する電話機が着信や発信などのイベントの通知を受け取れるようにするSwitchvoxの機能のひとつ」と説明し、脆弱な処理をPhoneAppsHandler.pmが扱う未認証のHTTPエンドポイント/paと特定し、XML::Simple::XMLin()でパースしたPolycomIPPhoneのXMLからPhoneIPを検証せずに取り出してPostgreSQLのクエリへ連結する、と説明しています。RCEへの到達にはCOPY ... TO PROGRAMを用いること、データベースのスーパーユーザー権限でシェルコマンドが実行されることが記載されています。開示のタイムラインは、2026年4月10日にSangomaへ12件の脆弱性を報告、4月21日に検証用のパッチビルドを受領、5月8日にゼロデイ監視のためのハニーポットを設置、7月14日に公式パッチ公開、7月17日にSRAが独立したアドバイザリを公開、8月30日にハニーポットで悪用を観測、9月1日に公開、という順です。

影響を受ける版と到達性の条件#

影響範囲の記述は、資料ごとに少しずつ違います。CVEレコードのaffectedは「Switchvox SMB Edition 8.3 (104997)、8.4.0.2未満」と書いており、NVDが生成したCPE照合の条件はcpe:2.3:a:sangoma:switchvox:*:*:*:*:on-premises:*:*:*のversionStartIncludingが8.2.2.1、versionEndExcludingが8.4.0.2です。Sangomaのリリースノートの見出しは「in SwitchVox 8.2.2.1」と書いています。JVN iPediaも「Switchvox 8.2.2.1 以上 8.4.0.2 未満」を採っています。

確認できている影響範囲と、運用上の扱いは分けて考えます。資料で影響が確認されているのは、下限を8.3(104997)とするか8.2.2.1とするかの違いはあるものの、いずれも8.4.0.2未満の範囲です。それより古い版については、脆弱であるとも安全であるとも示した資料が見当たりません。したがって8.2.2.1より前の版を使っている場合は「影響不明」として扱い、サポート状況を含めてSangomaまたは販売代理店へ確認したうえで、最新版への更新を検討するのが安全側の判断になります。

もうひとつの条件が到達性です。攻撃には認証情報も利用者の操作も要らないため、成立条件はSwitchvoxのWebインターフェースへ届くかどうかに集約されます。次のような構成は届く側です。

• 管理用のWeb画面をグローバルIPで公開している
• ポートフォワードでルーターの外側から転送している
• リモート内線やモバイル利用のためにHTTPSを外向けに開けている
• 保守業者の遠隔対応のために期間限定で開けたまま閉じ忘れている

なお公開資料が説明しているのは、/paがSwitchvoxの公開する未認証のHTTPエンドポイントであるところまでで、待ち受けポートや管理画面との関係までは書かれていません。管理画面へのアクセスを絞ったことをもって/paも届かなくなったとみなさず、外部から到達できる経路を実機で確かめてください。

閉じたネットワークの内側だけで動いている機器も、無関係ではありません。社内の別の端末が踏み台になれば同じリクエストは通ります。境界の外から直接届く機器を最優先に扱いつつ、内部からの到達も後述の分離で絞る、という順序になります。

提供形態による差も確認が要ります。NVDが生成したCPEの照合条件はon-premisesという版指定を含んでおり、自社で設置するオンプレミスのSwitchvoxを指しています。SangomaはSwitchvox Cloud UCaaSという事業者側で運用する形態も持っており、セキュリティアドバイザリの案内ページでもオンプレミスのソフトウェアとは別のリンクが割り当てられています。クラウド側の対応状況は利用者側からは確認できないため、この形態を使っているならSangomaまたは販売代理店へ、影響の有無と適用済みの版を照会するのが確実です。

国内の情報源をたどる運用にしている場合は、時期のずれも見込んでおく必要があります。JVN iPediaのJVNDB-2026-031598は、公表日が2026年7月17日、登録日と最終更新日がいずれも2026年9月3日です。CVEレコードの公開から国内データベースへの掲載まで約1か月半あり、掲載されたのはCISAがKEVへ追加した翌日でした。国内の窓口経由の情報だけを待つ運用では、修正版が出てから掲載までの期間が空白になります。

KEVの是正期限が3日になる理由#

KEVカタログのエントリを見ると、dueDateは2026年9月5日です。追加日の2026年9月2日から3日後で、KEVでよく見る14日ではありません。この差はBOD 26-04の判定表から来ています。

BOD 26-04は、是正の緊急度をPublicly Exposed、In the KEV、Automatable by Adversary、Technical Impactの4つの軸で決め、16行の表に落としています。CVE-2026-9586のSSVC判定はExploitation: active、Automatable: yes、Technical Impact: totalです。KEV収録済みかつAutomatableがYesでTechnical Impactがtotal controlという条件は、表の1行目(Publicly ExposedがYes)と9行目(同じくNo)に当たり、どちらも「3 days & forensic triage」です。KEVのforensicTriageがYesになっているのはこのためです。

ここは読み違えやすい箇所です。BOD 26-04はインターネットから外すことを有効な緩和として扱っており、実際に管理画面を外から到達できない位置へ移せば、その資産のPublicly ExposedはYesからNoへ変わります。ただしこのCVEの場合、Publicly Exposedを反転させても表の行は9行目へ移るだけで、3日という期限とフォレンジックトリアージの要件は変わりません。期限が延びるのは、KEV収録かAutomatableかTechnical Impactのいずれかの値が違う脆弱性の場合です。非公開化は攻撃面を減らす手として有効ですが、対応期限を先送りする根拠にはなりません。なおBOD 26-04が法的に義務を課すのは連邦政府の行政機関(FCEB)であり、民間組織にそのまま適用されるものではありません。優先順位の付け方の参考として使う、という位置づけになります。

KEVカタログのJSONフィードは、執筆時点でcatalogVersion 2026.09.04、count 1695です。CVE-2026-9586のエントリは、vendorProjectがSangoma、productがSwitchvox、vulnerabilityNameが「Sangoma Switchvox SQL Injection Vulnerability」、dateAddedが2026-09-02、dueDateが2026-09-05、knownRansomwareCampaignUseがUnknown、forensicTriageがYes、cwesがCWE-89です。notesにはSangomaの8.4.0.2リリースノートのURL、BOD 26-04、Forensics Triage Requirements、NVDのURLが並んでいます。2026年9月2日のアラートで同時に追加されたのは7件で、CVE-2026-48710(Starlette)、CVE-2026-49869(Kestra OSS)、CVE-2026-59822(BerriAI LiteLLM)、CVE-2026-82329(JFrog Artifactory)、CVE-2026-83548とCVE-2026-83549(SonicWall SMA1000)が同じ回に入っています。

ハニーポットで観測された悪用の内容#

Horizon3.aiは、パッチが出る前の2026年5月に、脅威インテリジェンス企業のDefused Cyberと連携してSwitchvoxを模したインターネット上のハニーポットを設置していました。ここで2026年8月30日から、CVE-2026-9586を狙うリクエストが観測されています。

観測された挙動は次の順でした。単一の送信元IP(176.65.148.184)から複数のハニーポットへ短時間のうちに攻撃が届き、COPY ... TO PROGRAM経由でncを使ったリバースシェルが張られました。続いて、稼働中のプロセスのうちCPU使用率の高いものを抜き出すコマンドがbase64で符号化された形で実行され、その結果がcurlで外部へ送られています。Horizon3.aiのZach Hanley氏はHelp Net Securityに対し、同じ攻撃者が第2段のマルウェアを落としており、一見したところ暗号資産のマイナーに見えると述べています。プロセス情報の収集が何を目的にしていたかは公開資料に書かれていません。マイニングに向く機材かを選別する動きだと読むこともできますが、これは推測の域を出ないため、そう決めつけずに痕跡そのものを追うのが確実です。

規模については、Horizon3.aiがShodanの結果として、インターネット上に約4,000台のSwitchvoxが見えており、その多くが米国に所在すると述べています。Help Net Securityの2026年9月2日の記事には、ブログ公開後にハニーポットを狙う送信元IPが数十単位で増えたという同氏の追加コメントも載っています。同社は「インターネットに露出したSwitchvoxのほとんどが、すでに狙われたか、これから狙われる可能性が高い」という見立てを示しています。

修正版の公開が2026年7月14日、ハニーポットでの初観測が8月30日なので、その間は47日あります。ただしこの47日は「悪用が世界で始まるまでの時間」ではありません。Horizon3.aiとDefused Cyberが設置したハニーポットに、この日はじめて有効な攻撃が届いたという意味であり、それより前に実環境で試行が無かったことを示すものでもなければ、8月30日から一斉に広い探索が始まったと確認できるものでもありません。公開資料から言えるのは、パッチ公開の直後ではなく1か月半ほど経った時点で観測に引っかかった、という事実までです。いずれにせよ、更新を先送りできる猶予が長いという読み方には使えません。PBXのように更新に業務の停止が伴う装置ほど、この種の期間を使い切ってしまいやすい点に注意が要ります。

Help Net Securityの2026年9月2日の記事は、Horizon3.aiのZach Hanley氏がメールで伝えた内容として「the same threat actor has been observed downloading second-stage malware onto the system, which on a cursory look appeared to be a cryptominer」と記載しています。同記事は、Horizon3.aiとSRAがそれぞれ独立にこの脆弱性を発見して報告したこと、ハニーポットがDefused Cyberとの連携で2026年5月に設置されたこと、8月30日から悪用が観測されたことを伝えています。マイナーである点は「一見したところ」という留保付きの記述であり、検体解析にもとづく確定した分類ではありません。

侵害の有無を確かめるときに見る場所#

更新の適用と、すでに侵入されていないかの確認は別の作業です。KEVがforensicTriage: Yesとしているのは、この2つを同時に求めているからです。CISAはBOD 26-04の実装ガイダンスで、対象範囲の特定、証拠の保全と収集、パッチ適用、封じ込め、分析、エスカレーション判断という6段階の順序を示しています。この順序には理由があり、更新や隔離を先に済ませてしまうと、判定に使える材料が失われることがあります。CISAの記述も「可能な場合は」という条件付きで、止血を優先すべき状況はありえます。順序を変える場合は対応の責任者が判断します。以下は、その順序をSwitchvoxに当てはめた流れです。

CISAの実装ガイダンスは、フォレンジックトリアージを6段階で示しています。Step 1のScopingで範囲の特定と体制の起動、Step 2のPreserve and Collect Evidenceで「揮発性データの即時取得を優先する」「可能な場合は証拠や成果物の収集前にシステムを変更または修復しない」「収集した項目、取得元、日時、取得者を記録する収集ログを維持する」、Step 3で証拠収集を終えてからのパッチ適用、Step 4で封じ込め(「早すぎる封じ込めは重要な証拠を破壊しうる」と注記)、Step 5で分析、Step 6でエスカレーション判断、という順です。なお同ページは、これらの時間目安は推奨であり、BOD 26-04が求めるのは適切なトリアージ分析が行われることだと明記しています。またBOD 26-04本文のTable 1は16行の判定表で、In the KEVがYes、AutomatableがYes、Technical Impactがtotal controlの行は、Publicly ExposedがYesの1行目とNoの9行目のいずれも「3 days & forensic triage」です。

更新までの時間を稼ぐ遮断のしかた#

すぐに更新できない事情がある場合、成立条件である到達性を切ります。効果の大きい順に並べると次のようになります。

1. Switchvoxの管理画面と/paを含むHTTP/HTTPSの受け口をインターネットから外し、VPNまたは許可した送信元IPからのみ到達できるようにする
2. 前段にリバースプロキシやファイアウォールを置いている場合、/paへの外部からのアクセスを遮断する
3. PBXを専用のセグメントへ移し、業務端末の一般的なネットワークから直接届かないようにする
4. PBXから外部へ出る通信を、必要な宛先だけに絞る

2番については、/paは電話機との連携が使う経路なので、遮断すると着信通知などの機能が止まる場合があります。どの機能が止まるかは導入している電話機と機能構成によって変わるため、社内からの到達を残したうえで外部だけを落とす形にして、電話機の動作を試験してから本適用してください。4番の外向きの絞り込みは、侵入されたあとの第2段のダウンロードや外部への持ち出しを止める役割を持ち、侵入の成否にかかわらず効く層です。ただしSwitchvoxが外部へ出る先はSIPトランクだけではありません。ボイスメールのメール転送に使うSMTP、DNS、更新や登録の確認、電話機のファームウェア取得、モバイルアプリや会議機能の接続などが構成によって加わります。使っている機能を棚卸しし、通信ログで実際の宛先を確認したうえで許可リストを作り、試験を経てから本適用する順序にしてください。順序を飛ばすと、電話が鳴らない、ボイスメールが届かないといった業務影響が出ます。

侵害が疑われるときに残る後始末#

PBXが持っている情報は、電話帳と通話履歴だけではありません。SIPトランクの認証情報や管理者アカウントの情報、内線ごとのボイスメールの設定が同じ機器に載っているのが一般的な構成です。データベースへ任意のSQLが通り、さらにOSコマンドの実行まで到達しうる以上、これらは読み出された可能性のあるものとして扱うのが安全側です。何がどの形式で保存されているかは版や構成によって変わるため、まずは当該機器に保存している資格情報と連携用のシークレットを棚卸しするところから始めます。

参考になるのが、Sangomaが別のCVEについて公開しているアドバイザリGHSA-mfm3-g35x-c9w8(CVE-2026-45362)です。ここでは、Switchvoxのバックアップファイル(.svb)がデータベースの内容を平文で含み、SIPトランクのパスワードなどの認証情報や機微な情報が入ると説明されています。そして、以前のバックアップの管理経路に確信が持てない場合の推奨として、SIPトランクの資格情報のローテーションが挙げられています。これはCVE-2026-9586とは別の脆弱性の話ですが、この機器のデータベースにどの種類の情報が平文で載りうるかを示す、ベンダー自身の記述として読めます。

後始末として残るのは、棚卸しした資格情報のうち、侵害の疑いの範囲に入るものの入れ替えです。SIPトランクのパスワードと管理者アカウントのパスワードは優先度が高く、API連携やAsterisk側の管理インターフェースの資格情報、ボイスメールの暗証番号を設定しているならそれも対象になります。あわせて、通信事業者側で国際電話の発信に上限や制限をかけられるかを確認しておくと、次に何かが起きたときの損害額が変わります。

VoIP基盤に効かせる恒久的な守り方#

CVE-2026-9586を1件の脆弱性として閉じるだけでは、同じ形の事象が次の版でも起きます。PBXという装置の置かれ方に手を入れる方が効果が長く続きます。

導入や保守を業者に任せているPBXは、自組織の資産管理表から漏れやすい装置です。サーバーやネットワーク機器は棚卸しの対象になっているのに、電話交換機だけが「電話の設備」として別枠になっている、という状態がしばしば見つかります。KEVに載った日から3日という期限は、資産の一覧がすでに手元にあることを前提にした速さです。棚卸しの対象へPBXを入れておくことが、次の同種の事象での初動を分けます。

電話機との連携経路を信頼境界として扱う#

この脆弱性が示しているのは、SQLの書き方の問題であると同時に、信頼の置き方の問題です。/paは電話機との連携のための経路として設計されました。公開資料から読み取れるのは、この経路が認証を求めず、本体が<PolycomIPPhone>で始まるかどうかだけを見て中身のXMLを信頼していた、というところまでです。設計の意図そのものは公開されていませんが、相手は構内の電話機だという想定があったと読むこともできます。その前提は、機器がインターネットへ出た瞬間に成り立たなくなります。

電話機やセンサーとの連携、ヘルスチェック、監視エージェントの受け口といった「機械が機械に話しかける」経路は、人が使う画面ほど注視されません。認証を課すと運用が回らないという理由で開けたままになり、入力の検証もゆるいまま残ります。設計時に置いた「この経路には社内の機器しか来ない」という前提を、ネットワーク構成が変わるたびに確かめ直すことが、この種の受け口を守る方法です。前提が崩れているなら、まず到達性を戻すのが先で、その次にコードの修正が来ます。