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

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

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

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

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

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

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

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の「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形式も選択してください。

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ファイル、不明なスクリプトをそのままコピーしないでください。比較が必要な場合は、オフラインの読み取り専用コピーでテキスト差分を確認し、リソースビューアーをクリックして変換を発動させないでください。

疑わしい MRS キャッシュを削除する前に、証拠のハッシュと時刻を保存します。

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

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

Clash Party を完全に終了して再起動し、バージョンと Profile を確認します。正しいバージョン、正常なルールリソース、実通信の成功が再起動後も維持される必要があります。

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、影響を受けるバージョン、新しい対策を公表した場合は公式説明に従って記録を更新し、二次情報の見出しから深刻さや規模を推測しないでください。