Clash Partyのrule-providersにおけるコマンドインジェクションのリスクへどう対処する？

Clash Party v2.0.3の公式リリースノートでは、「悪意のあるrule-providers設定によって任意のコマンドが実行される可能性がある」セキュリティ問題の修正が明記されています。対応するコミット588aaa6によると、旧版のconvertMrsRulesetはrule-providers.behaviorとルールセットのパスをshellコマンドへ連結していました。

behaviorは実行時設定から取得され、その実行時設定はユーザーが購読するYAMLから提供される場合があります。悪意がある、または改ざんされたサブスクリプションは異常なbehaviorを書き込めます。修正コミットではさらに、Windowsで二重引用符が埋め込まれたルールセットパスも、旧コマンドの引用符境界を壊せたと説明されています。

その後、ユーザーがリソースビューアーで該当するMRSルールセットを開くと、旧実装ではOSのshellがこれらの値を解釈し、現在のClash Partyユーザー権限でコマンドを実行する可能性がありました。

修正ではshell文字列の実行をexecFileの引数配列に置き換え、behaviorをMihomoが対応するdomain、ipcidr、classicalに制限しました。修正対象はClash Partyのルールセット変換経路であり、Mihomoのrule-providers形式自体でも、すべてのClashクライアントに共通する脆弱性でもありません。

上流では、影響を受ける開始バージョン、CVE、GHSA、深刻度、実際の悪用の有無は公表されていません。旧版や不明なサブスクリプションがあるだけで、端末が悪用されたとは断定できません。ただし、実際のバージョンがv2.0.3未満で、設定元が信頼できず、該当するMRSリソースを開いた場合は、本記事に従って直ちに隔離し、更新してください。

まだバージョンを確認できない場合は、まずClash Partyのルールセットリソースビューアーを閉じ、疑わしいrule-providerをクリックしないでください。疑わしいProfileの自動更新と使用を停止し、自分で保存して入手元を確認済みの設定へ切り替えます。安全に切り替えられない場合は、Clash Partyを完全に終了してください。

疑わしい設定のbehaviorを変更して試行を続けたり、サブスクリプション全体をオンライン診断サイトへアップロードしたりしないでください。サブスクリプションURLにはtokenが含まれる場合があり、ルールセットのアドレス、ノード認証情報、スクリプト内容からもアカウントやネットワーク構成が漏れる可能性があります。

未知のコマンドウィンドウ、不審なプロセス、セキュリティソフトの警告、異常な外部通信、ファイル変更がすでに見つかっている場合は、直ちに端末をネットワークから切断し、後述のインシデント対応へ進んでください。この段階では、アプリを更新するだけで実行済みのコマンドが取り消されたとは確認できません。

Clash Partyの「About」または更新ページで実際のアプリバージョンを確認し、OSとインストールしたアーキテクチャを記録します。ダウンロードファイル名、古いスクリーンショット、Mihomoコアのバージョンだけで判断しないでください。この修正はClash Party本体に含まれます。

次に、ルールセットの内容を開かず、疑わしいProfileが手動インポート、ローカルファイル、リモートサブスクリプションのどれか、最終更新日時、rule-providersにMRS形式のリソースがあるかを記録します。

記録するのはprovider名、type、behavior、format、機密情報を除いた入手元ドメインまたはパスだけにします。Windowsではパスに異常な二重引用符が含まれていないかにも注意し、ノードのパスワードやサブスクリプションtokenはコピーしないでください。

Clash Partyのログ、OSのセキュリティログ、現在の設定の読み取り専用コピーを保管します。異常の証拠がない場合、正常なmihomo子プロセス、ルールのダウンロード、一時ファイルをすべて侵害と決めつけないでください。明確な警告がある場合も、先にファイルを削除したり再インストールして時系列を上書きしたりしないでください。

Clash Party v2.0.3は2026年9月20日にリリースされ、公式リリースノートとコミット588aaa6の双方にこの修正が含まれています。最低条件は実際にv2.0.3を実行することです。今後、公式から新しい安定版が提供された場合は、そのコミットが引き続き含まれていることを確認してください。

mihomo-party-org/clash-partyの公式Releaseから、OSとアーキテクチャに合うインストーラーを選びます。Windowsではx64、ia32、ARM64を区別し、macOSではIntelとApple Siliconを区別します。Linuxでは、現在のディストリビューションで使うDEB、RPM、PACMAN形式も選択してください。

更新前に旧プログラムを完全に終了し、現在の設定をバックアップします。検索広告、オンラインストレージ、チャットの添付ファイルから同名のインストーラーを入手しないでください。古いプラグインを残すために、v2.0.3のプログラムファイルを一部だけ上書きすることも避けてください。

インストール後に「About」ページを開き直し、実際のバージョンを確認します。Mihomoコアの更新、サブスクリプションの更新、ルールセットだけの差し替えは、Clash Party本体の更新の代わりにはなりません。

更新後すぐに元の疑わしいProfileを再び有効にしないでください。リモートサブスクリプションが改ざんされた可能性がある、または入手元を確認できない場合は、サービス提供者へ公式アドレスを確認し、古いサブスクリプションtokenを無効にして再発行してもらいます。tokenのローテーションは信頼できる端末で実施してください。

新しい設定のrule-providersを確認します。Mihomoのドキュメントでは、一般的なbehaviorとしてdomain、ipcidr、classicalの三種類が挙げられていますが、format: mrsが対応するのはdomainとipcidrだけです。classicalは別の対応形式で使用できますが、MRSと組み合わせないでください。

連結記号、コマンド断片、またはそのformat/behaviorの組み合わせに合わない内容は読み込まないでください。provider URLのドメイン、パス、更新経路、想定形式も確認します。

入手元が明確な新しい設定からだけノードとルールを復元し、疑わしいYAML、キャッシュされたMRSファイル、不明なスクリプトをそのままコピーしないでください。比較が必要な場合は、オフラインの読み取り専用コピーでテキスト差分を確認し、リソースビューアーをクリックして変換を発動させないでください。

セキュリティ確認の第一項目は、実際のClash Partyがv2.0.3以上であることです。第二項目は、入手元が明確でformat/behaviorの組み合わせが正しく、パスに異常のないProfileだけをインポートし、ルールセット一覧を正常に読み込めることを確認することです。フィルターが機能する証明のために悪意のある値を作る必要はありません。

信頼できるProfileで既知のMRSリソースを一つ開き、それがdomainまたはipcidrを使用していること、リソースビューアーにルールが表示されること、アプリが予期しないコマンドインタープリターや未知の子プロセスを起動しないことを確認します。次に、動作確認済みのノードを一つ固定し、サブスクリプション更新、ルール一致、実際のHTTPSリクエストをそれぞれ確認します。

最後にClash Partyを完全に終了して再起動し、バージョンとProfileをもう一度確認します。バージョンが正しいこと、ルールリソースが正常であること、実際のリクエストが成功することの三点がそろって初めて、更新がインストール画面だけで終わっていないと確認できます。

ルールリソースを開いた前後に、未知のコマンドウィンドウ、不審なプロセス、異常な外部通信、OSのセキュリティ警告、スタートアップ項目やファイルの変更が見つかった場合は、通常のクライアント更新として扱わないでください。ネットワークを切断して端末の状態を保ち、時系列、プロセス、接続、警告、ファイルパスを記録します。

OSまたは組織が承認したセキュリティツールで、オフラインスキャンまたは完全スキャンを実施します。サブスクリプションtoken、ノード認証情報、WebDAV、GitHub Token、ブラウザーセッションなど、現在のユーザー権限で読み取られた可能性がある認証情報は、別の信頼できる端末から失効させ、再発行してください。

v2.0.3への更新で遮断できるのは旧変換経路だけであり、すでに実行されたプログラムを削除したり、漏えいした認証情報を復元したりはできません。システムの完全性を確認できない場合は、公式メディアからOSとクライアントを再インストールし、確認済みのクリーンなデータだけを復元してください。古いアプリディレクトリ全体をそのまま戻さないでください。

v2.0.3で現在の端末にインストール、起動、プラグイン互換性の問題が起きても、機能を戻すために旧変換経路を含むバージョンへ戻さないでください。まずClash Partyを完全に終了し、疑わしいProfileを停止したまま、検証済みの別の保守中クライアントまたはシステムプロキシで必要な通信を復旧します。

Clash Partyを引き続き使う場合は、信頼できる設定のオフラインバックアップだけを残し、公式の後続安定版と関連issueを確認します。新しいバージョンが正常に起動してから、システムプロキシ、TUN、サブスクリプション更新、ルールリソース表示を一項目ずつ復元し、古いデータディレクトリ全体を一度にコピーしないでください。

問題が特定の第三者ルールセットやサブスクリプションだけで起きる場合は、behaviorを緩めたり旧版のshell実行を再び有効にしたりせず、提供者に設定の修正を依頼してください。上流へ報告するときは、OS、アーキテクチャ、バージョン、最初のエラー、機密情報を除いた再現手順を示し、サブスクリプションtokenや実行可能なpayloadは添付しないでください。

今回の修正から、サブスクリプションはノード一覧だけでなく、rule-providersなどの構造化フィールドもクライアントへ渡すことが分かります。長期的な保守では、サブスクリプション提供者、rule-providerのドメイン、behavior、最終確認日時、現在のClash Partyバージョンを記録してください。

アプリの自動更新を有効にするか、公式Releaseを定期的に確認します。サブスクリプションのドメイン、発行方法、内容構造が変わった場合は、オフラインで比較してから通常のProfileへ戻してください。保守が終了した、または入手元を説明できないルールセットは、クライアント側のフィルターへ依存し続けるより、使用関係を削除する方が確実です。

公式Releaseと修正コミットが、今回の結論における事実の範囲です。今後、上流がGHSA、CVE、影響バージョンの範囲、新しい緩和策を公開した場合は、その公式説明に基づいて判断を更新し、二次情報の見出しから深刻度や影響規模を推測しないでください。