Cisco-Unified-Communications-Manager-Server-Side-Forgery-Request-Vulnerability-CVE-2026-20230

CVE-2026-20230のSSRFから任意ファイル書き込み、Cisco Unified Communications ManagerでのRCEを分析し、PoCの導出、検出ロジック、防御ガイダンスを提供します。

したがって、単独でインターフェースにアクセスしてHTTP 200、302、401、404、500を得ても、脆弱性の存在または非存在を直接証明することはできません。

例えば、WebDialer WSDLインターフェースにアクセスできることは、ターゲットがWebDialer関連機能を露出していることを示すだけであり、その後のSSRFが必ずフィルタを突破できることを証明するものではありません。installClusterStatusExecuteインターフェースにアクセスできることも、関連するエントリポイントが存在することを示すだけであり、単独で任意ファイル書き込みが成立することを証明するものではありません。逆に、あるステップで異常が返る場合も、ターゲットのバージョン、パッチ、ホスト名解決、パス権限、プロキシ機器、サービス状態などが原因である可能性があり、必ずしも脆弱性チェーン全体が存在しないことを意味するわけではありません。

より確実な判断は、多段階の証拠を組み合わせるべきです：

1. ターゲットがCisco Unified CM / Unified CM SMEであることを確認する。
2. WebDialerサービスが有効状態であることを確認する。
3. ターゲットの実際のホスト名または内部サービス識別子を取得できることを確認する。
4. SSRFエントリポイントに到達可能であり、サーバーサイドから内部リクエストが発生している兆候があることを確認する。
5. 許可されたターゲット環境で、制御されたファイル書き込みの証拠を生成できるか確認する。
6. サーバーサイドログ、ファイルシステムの変更、Webコンテナログ、アラートデータを組み合わせて、実際にトリガーされたかを判断する。

「WebDialer有効 + 影響を受けるバージョン + SSRF動作成立 + 制御されたファイル書き込み成立」が同時に発生した場合にのみ、信頼性の高い悪用可能と判断すべきです。

3. PoC構築の考え方

現在公開されている攻撃チェーンの核心は、単なるSSRFではなく、SSRFとAxis/Java Webサービスメカニズム、ログ書き込み、またはデプロイメント記述子ファイル処理ロジックとの組み合わせ利用です。

全体の考え方は次のように要約できます：

リンク設計から見ると、ホスト名が重要なポイントです。一部のフィルタリングロジックは127.0.0.1、localhostなどの一般的なローカルアドレスをブロックしますが、ターゲットの実際のホスト名は後続のリクエストフローに入ることが許可される可能性があります。そのため、PoCはまずWebDialerのWSDL情報から実際のホスト名を抽出し、それをSSRFチェーンにおける内部アクセスのプレフィックスとして使用します。

2つ目の重要なポイントは、Axisサービス関連ロジックです。PoCはWebディレクトリに直接ファイルをアップロードするのではなく、内部サービス処理チェーンを介して、サーバーサイドコンポーネントに攻撃者が制御可能なコンテンツを特定のパスに書き込ませます。このプロセスは本質的に「サーバーサイド内部リクエスト + コンポーネント設定/ログ書き込み動作 + パストラバーサル/パス制御」の組み合わせです。

3つ目の重要なポイントは、2段階書き込みです。第1段階は通常、より安定したファイル書き込みエントリを確立するために使用され、第2段階でコマンド実行スクリプトをWebアクセス可能なディレクトリに書き込みます。この理由は、SSRFを介して直接1ステップで完全なコマンド実行ロジックを書き込もうとすると、エンコーディング、長さ、XML構造、パス権限、サーバーサイド解析動作などの影響を受ける可能性がある一方、2段階方式では複雑なペイロードを分割しやすいためです。

本記事では、完全な攻撃パケットやWebShellの内容は提供しません。防御と検証に必要なのは、以下の核心的な特徴を理解することだけです：

4. ホスト名取得ロジック

PoCはまずターゲットの実際のホスト名を取得する必要があります。IPアドレスや外部ドメイン名だけを使用するのではありません。

その理由は、SSRFフィルタリングロジックは最終接続先だけを判断するとは限らず、ホスト名フィールド、URL文字列、ローカルアドレスキーワードなどを検証する可能性があるからです。一般的な127.0.0.1、localhostなどのローカルアドレスはブロックされる可能性がありますが、デバイスの実際のホスト名は一部のシナリオで正当なノード名として扱われることがあります。

判断を補助するために使用できるインターフェースは、通常WebDialer WSDL情報に関連しています。そのようなWSDLにアクセスすると、レスポンスにはサービスアドレス、locationフィールド、またはその他の解析可能なホスト識別子が含まれている可能性があります。PoCはレスポンステキストからURL内のホスト名を抽出し、それを次のフェーズのSSRFの内部アクセスターゲットとして使用します。

このフェーズの判断基準は以下の通りです：

1. WSDLインターフェースにアクセス可能か。
2. レスポンスの内容がWebDialer / Axisサービスの特徴に合致するか。
3. レスポンスから実際のホスト名を解析できるか。
4. 解析されたホスト名が外部アクセスIPやドメイン名と異なるか。
5. そのホスト名が後続のSSRFエントリポイントで受け入れられるか。

ホスト名の解析に失敗した場合、PoCはターゲットIPにフォールバックすることがありますが、成功率は大幅に低下します。実際の環境でホスト名解析が失敗する一般的な理由には、WebDialerが有効でない、インターフェースがアクセス制御で制限されている、レスポンスがリバースプロキシによって書き換えられている、証明書やサービス設定が不完全であるなどがあります。

5. SSRFトリガーフェーズ

SSRFのトリガーポイントは、cmplatform関連のインストール状態照会ロジックにあります。この機能は元々クラスタノードのインストール状態を照会するためのもので、サーバーサイドはユーザーが送信したノード識別子やホスト名に基づいて内部リクエストを組み立てます。

脆弱性の核心は、攻撃者が制御可能なホスト名パラメータが正当なノード名や信頼されたホストに厳密に制限されておらず、そのパラメータをより複雑な内部アクセスパスに構成できることです。その後、サーバーサイドは攻撃者に代わって内部インターフェースにリクエストを送信します。

このフェーズの鍵は「外部URLにアクセスできること」ではなく、「CUCMデバイス自体に、内部で到達可能なWebDialer / Axis管理インターフェースにアクセスさせること」です。したがって、SSRFの価値は2つの側面から来ます：

1. 外部ネットワークアクセス制限をバイパスし、ローカルホストまたは内部コンポーネントからのみアクセス可能なサービスパスに到達する。
2. 内部サービスの信頼境界を利用して、通常のHTTPパラメータを内部コンポーネント操作に変換する。

許可された検証では、HTTPステータスコードだけでSSRFの成功を判断してはいけません。より信頼性の高い証拠には以下が含まれます：

1. サーバーサイドログに内部パスへのアクセス記録が現れる。
2. リクエスト応答の内容に内部インターフェースの特徴が現れる。
3. 後続のWebDialer servicesページに新規または異常なサービス痕跡が現れる。
4. ファイルシステムにサーバーサイドプロセスによって作成された異常なファイルが出現する。
5. セキュリティデバイスが、ホスト名パラメータに異常なパス、エンコードされた内容、内部サービスパスが含まれていることを記録する。

6. Axisサービス書き込みと任意ファイル書き込みの考え方

公開されたチェーンでは、SSRFはさらにAxis関連サービスインターフェースにアクセスし、サービスデプロイメント記述内容の書き込みを試みます。攻撃者は特別なXML/WSDD構造を構築し、サーバーサイドコンポーネントが処理中に制御可能なコンテンツを指定パスに書き込むようにします。

このフェーズの本質は従来のファイルアップロードではなく、サーバーサイドコンポーネントの処理ロジックを悪用することです：

セキュリティ分析の観点から、ここにはいくつかの重要なポイントがあります：

1. 書き込み先パスは通常、Webコンテナがアクセス可能なディレクトリまでトラバーサルする必要がある。
2. 書き込む内容はサーバーサイドコンポーネントの処理形式を満たす必要がある。そうでなければ無効なファイルしか生成されない可能性がある。
3. 書き込まれたファイルの所有者と権限は、Tomcat / CUCMサービスプロセスに依存する。
4. 書き込み位置がWebアクセス可能であれば、ファイル書き込みはさらにスクリプト実行に変換される可能性がある。
5. 書き込み位置が実行可能でなくても、設定汚染、永続化、後続の権限昇格条件を引き起こす可能性がある。

したがって、CVE-2026-20230の高リスク点はSSRFだけではなく、SSRFが信頼境界を越え、内部管理/サービスデプロイチェーンに入り、最終的に制御可能なファイル書き込みをトリガーできることです。

7. 2段階WebShell書き込みロジック

PoC設計では通常、1ステップでコマンド実行を完了するのではなく、2段階書き込みを採用します。

第1段階は、単純なファイル書き込み能力を作成するために使用されます。この段階の目標は、攻撃者がWebアクセス可能なパスを介してサーバーの指定位置に内容を書き込めるようにすることです。

第2段階では、第1段階で書き込んだ能力を利用して、コマンド実行スクリプトをWebアクセス可能なディレクトリに書き込みます。その後、攻撃者はHTTPパラメータを介してシステムコマンド実行をトリガーできます。

2段階設計の利点は次のとおりです：

1. 単一のSSRFリクエストにおけるペイロードの複雑さを低減する。
2. XML、URLエンコーディング、特殊文字エスケープによるペイロード破損を回避する。
3. 「サービスのデプロイ」と「最終実行ファイルの書き込み」を分離し、デバッグを容易にする。
4. 異なるターゲットパスで着弾点を調整しやすくする。
5. 後続のコマンド実行フェーズをSSRFフェーズから切り離す。

しかし、防御の観点から見ると、2段階書き込みはより明確な検出面をもたらします：

1. 最初の異常リクエストは通常、新しいサービスの作成または中間JSPの書き込みを試みる。
2. 2番目の異常リクエストは通常、中間JSPにアクセスし、ファイル名やファイル内容などのパラメータを運ぶ。
3. 第3段階では最終コマンド実行JSPにアクセスし、認証パスワードやコマンドパラメータを運ぶ。
4. Webアクセスログには、短時間に連続してWebDialer、services、axis2-web、platform-servicesなどのパスにアクセスする動作が現れる。
5. ファイルシステムに異常なJSP、異常なサービス名、異常なログファイル、または新規のWebリソースが出現する可能性がある。

8. 現在のPoCの完全な実行フロー

現在のPoCのフローは次のように要約できます：

1. ターゲットアドレスを解析する。
2. WebDialer WSDLにアクセスし、実際のホスト名の抽出を試みる。
3. SSRFリクエストを構築し、内部WebDialer / Axis管理パスをターゲットとする。
4. 内部リクエストを介してAxisサービス関連コンテンツを書き込む。
5. servicesページにアクセスし、異常なサービスがデプロイされたかを確認する。
6. 新しいサービスを呼び出し、第1段階のファイル書き込みスクリプトを書き込む。
7. 第1段階のスクリプトにアクセスし、第2段階のコマンド実行スクリプトを書き込む。
8. 第2段階のスクリプトにアクセスし、テストコマンドを実行する。
9. HTTPレスポンス、ファイル配置結果、コマンド出力に基づいて悪用の成功を判断する。

悪用成功率の観点から、最も重要な失敗点は通常次の点に集中します：

1. WebDialerが有効でない。
2. ホスト名の解析に失敗するか、フィルタリングされる。
3. SSRFリクエストが実際に内部サービスに到達していない。
4. Axisサービスのデプロイに失敗する。
5. パストラバーサルの着弾点がターゲットバージョンに適合しない。
6. Webディレクトリが書き込み不可であるか、スクリプトが実行されない。
7. ターゲットがすでにパッチ適用済みか、Ciscoの一時修正パッケージを使用している。
8. プロキシ、WAF、EDR、ファイル整合性監視が中間段階をブロックしている。

したがって、このPoCは特定の影響を受けるバージョンとデフォルトパスが一致する場合に悪用可能性が高いですが、すべてのCUCMアセットに対して安定して有効というわけではありません。

9. 成功判断ロジック

CVE-2026-20230の成功判断は、スクリプトが完了したかだけを見るべきではありません。より合理的な判断は4段階に分けるべきです。

第1段階：ターゲットが露出の疑い

条件：

これはターゲットに関連する攻撃面が存在することを示すだけであり、脆弱性が悪用可能であることを証明するものではありません。

第2段階：脆弱性が存在する疑い

条件：

この場合、サーバーサイドログや許可されたターゲット環境での検証を続けるべきです。

第3段階：ファイル書き込みの確認

条件：

この段階に達すると、脆弱性チェーンが通常のSSRF段階を突破し、任意ファイル書き込みリスクに入ったことを確認できます。

第4段階：RCEの確認

条件：

この段階のみでリモートコマンド実行が成立したと判断できます。ファイル書き込みの成功は必ずしもRCEの成功を意味しませんが、CUCMのような高権限サービス環境では、ファイル書き込みだけで重大なリスクを構成するのに十分です。

10. 使用例

本記事では、攻撃に直接使用できるエクスプロイトの実行例を提供しません。

許可された環境では、優先的に「読み取り専用チェック」または「非破壊的検証」方式を使用することを推奨します。例えば：

推奨されるチェック項目：

1. ターゲットがCisco Unified CM / Unified CM SMEであるか。
2. WebDialerサービスが有効か。
3. WSDLにアクセス可能か。
4. servicesページが露出しているか。
5. ターゲットバージョンが修正バージョン未満か。
6. 異常な新規JSP、異常なAxisサービス、異常なログ書き込み痕跡が存在するか。

本番システムで完全なファイル書き込みやコマンド実行の検証を行うことは推奨しません。許可されたテストであっても、隔離されたターゲット、スナップショット環境、またはベンダー推奨の検証フローを優先すべきです。

11. PoC設計におけるセキュリティ境界

この種のPoCのセキュリティ境界は明確にすべきです。

第一に、デフォルトでコマンドを実行してはいけません。コマンド実行フェーズは高リスクな検証であり、システム状態の変更、ログ汚染、サービス異常、セキュリティ機器の連動応答を引き起こしやすいです。

第二に、デフォルトでWebShellを書き込んではいけません。たとえテストファイルであっても、EDR、WebShellマルウェア対策、ファイル整合性監視、コンプライアンス監査システムによって実際の侵害行為と判断される可能性があります。

第三に、公開ネットワークのターゲットに対してバルクプローブを行ってはいけません。この脆弱性は認証不要であり、ターゲットの多くは企業通信インフラであるため、許可されていないスキャンと悪用のリスクは極めて高いです。

第四に、チェックモードと悪用モードは分離すべきです。PoCを2つのスクリプトに分割することを推奨します。1つはアセット識別とサービス状態判断専用、もう1つはローカルターゲットまたは明確に許可された環境でのみファイル書き込みを検証するものです。

第五に、ターゲット範囲を制限すべきです。PoCにはローカルアドレス、プライベートネットワークセグメント、ホワイトリストドメイン、許可確認パラメータなどの保護メカニズムを追加し、誤ってサードパーティシステムを攻撃しないようにする必要があります。

第六に、デフォルトでRCEフェーズを無効にする必要があります。研究コードを保持する場合でも、ユーザーが明示的に許可確認パラメータを渡した場合にのみファイル書き込みまたはコマンド実行の検証を許可するようにすべきです。

12. 防御ルール作成への示唆

トラフィック検出の観点から、特定の固定ファイル名、固定サービス名、固定JSP名だけにマッチングしてはいけません。公開PoCのサービス名、ファイル名、パスはすべて変更可能であり、単一の文字列ルールでは見逃しが発生しやすいです。

より合理的な検出アプローチは、攻撃チェーンのフェーズごとに特徴を抽出することです。

第1類：情報取得フェーズ

重点的に監視：

短時間に外部クライアントがWSDLにアクセスした後、cmplatformのインストール状態インターフェースにアクセスした場合、リスクレベルを上げるべきです。

第2類：SSRFトリガーフェーズ

重点的に監視：

このフェーズの鍵は、hostnameパラメータが通常のホスト名ではなくなり、パス化、URL化、エンコード化、XML化の特徴が現れることです。

第3類：Axis / WSDD注入フェーズ

重点的に監視：

これらのフィールドが同時に出現する場合、攻撃者がAxisサービスのデプロイメント記述ファイルを介して制御可能なコンテンツを書き込もうとしている可能性が高いと疑うべきです。

第4類：ファイル書き込みフェーズ

重点的に監視：

攻撃トラフィックに大量の ../、URLエンコードされたパストラバーサル、JSP拡張子、Tomcat WebAppパスが出現した場合、高リスクと判断すべきです。

第5類：コマンド実行フェーズ

重点的に監視：

ルール設計の観点からは、フェーズごとの検出を推奨します：

1. WebDialer情報取得：低リスクまたは中リスクのアラート。
2. cmplatform SSRF異常hostname：高リスクアラート。
3. Axis/WSDD/LogHandlerの組み合わせ特徴：重大アラート。
4. JSPファイル書き込みまたはコマンド実行パラメータ：重大アラート。
5. 多段階関連ヒット：直接侵入イベントに昇格。

13. 調査とフォレンジックの推奨事項

緊急調査時には、以下の場所と現象を重点的に確認することを推奨します：

1. WebDialerアクセスログに異常なWSDLやservicesの列挙が存在するか。
2. cmplatformアクセスログにinstallClusterStatusExecuteの異常リクエストが存在するか。
3. hostnameパラメータにURLエンコード、パストラバーサル、Axis、WSDD、LogHandlerなどの内容が含まれているか。
4. Webディレクトリに異常なJSPファイルが出現していないか。
5. Axis servicesページまたは設定に異常なサービス名が出現していないか。
6. Tomcatログ、プラットフォームサービスログに異常なデプロイメント記述、XML解析エラー、パス書き込み記録が存在するか。
7. /tmp、WebAppディレクトリ、ログディレクトリにテストファイルや未知のファイルが出現していないか。
8. 短時間に同一ソースIPから多段階連続アクセスが行われていないか。
9. 異常なシステムコマンド実行痕跡、プロセス作成記録、シェル関連動作が出現していないか。
10. root権限関連の異常ファイル、スケジュールタスク、起動項目、永続化痕跡が存在するか。

もし悪用された疑いがある場合は、管理面アクセスを優先的に隔離し、ログとファイルシステムの証拠を保持した上で、パッチアップグレード、WebShellのクリーンアップ、異常サービスのクリーンアップ、アカウント/認証情報のローテーションを実施すべきです。

14. 修正と緩和の推奨事項

根本的な修正方法は、Cisco公式修正バージョンにアップグレードするか、公式が提供する一時修正パッケージを適用することです。

一般的な対応推奨事項は以下の通りです：

1. 直ちにUnified CM / Unified CM SMEのバージョンを確認する。
2. WebDialerサービスが有効かどうかを確認する。
3. 業務でWebDialerが不要な場合は、直ちにサービスを無効にする。
4. Cisco公式修正バージョンにアップグレードする。
5. Release 15環境で当面アップグレードできない場合は、Ciscoの指示に従って対応するCOPファイルを適用する。
6. 管理面およびWebDialer関連サービスのアクセスソースを制限する。
7. 境界デバイス、WAF、IDS/IPSにcmplatform、WebDialer、Axis/WSDD異常リクエストの検出を追加する。
8. 異常なJSP、異常なAxisサービス、未知のファイルがすでに出現していないか確認する。
9. 露出したシステムに対してログのバックトレースを実施し、特に2026年6月3日以降のアクセス記録を重点的に調査する。
10. ファイル書き込みまたはコマンド実行の証拠を発見した場合、パッチアップグレードだけでなく、ホスト侵害として対応すべきである。

15. まとめ

CVE-2026-20230の鍵は単一のインターフェース露出ではなく、CUCMのWebDialer、cmplatformインストール状態照会ロジック、内部Axisサービス処理、ファイル書き込み能力の間に形成された連鎖可能な信頼境界の破綻にあります。

このチェーンは次のように要約できます：

実際の悪用可能性は、WebDialerが有効か、ターゲットバージョンが影響を受けるか、ホスト名フィルタがバイパス可能か、パス着弾点が適合するか、Webコンテナが書き込まれたファイルを実行するか、ターゲットがパッチを適用済みかによって決まります。

防御の観点からは、「特定のJSPファイルが存在するか」だけに依存して攻撃を判断してはいけません。より確実な方法は、多段階チェーンに沿った関連検出です：WSDL情報取得、cmplatform異常hostname、Axis/WSDD特徴、パストラバーサル書き込み、JSP配置アクセス、コマンドパラメータアクセス。これらの複数の段階が短時間に同一ソースから連続して出現した場合、高リスクの侵入イベントとして処理すべきです。

References

• Cisco Security Advisory: Cisco Unified Communications Manager Server-Side Request Forgery Vulnerability
• NVD: CVE-2026-20230
• SSD Secure Disclosure: Cisco Unified Communications Manager Arbitrary File Write to RCE
• Cisco Unified CM / Unified CM SME 公式アップグレードとCOP修正説明