Clash Party内蔵Sub-Storeのリスクにはどう対処する？

Sub-Store issue #634の公開報告では、影響範囲をNodeバックエンドの2.11.4～2.37.1とし、広すぎるクロスオリジンアクセスとスクリプト処理機能が組み合わさるリスクを説明しています。その後、上流はcommit 038745fでデフォルトのCORSを絞り込み、一部のNodeスクリプト操作を制限して拒否テストを追加しました。2.38.0のリリースノートでは、このissueを閉じたことが明記されています。

2026年9月12日時点で、Sub-Storeの現行安定版は2.39.6です。この記事では、上流が#634を明示的に閉じた最低ラインを2.38.0とし、現行安定版への更新を勧めます。ただし、2.38.0があらゆるネットワーク公開経路に認証を追加したという意味ではなく、バージョン番号だけで端末がすでに影響を受けたかどうかも判断できません。

Clash Party issue #2134はv2.0.2環境についてのユーザー報告です。その後、プロジェクトのセキュリティ報告手順に沿ってbotにより閉じられ、コントリビューターはSub-Storeの更新を勧めています。Clash Partyでは内蔵バックエンドを個別に更新できるため、クライアントのバージョンだけでは稼働中のSub-Storeバージョンを特定できません。

v2.0.2のソースでは内蔵Sub-Storeがデフォルトで有効ですが、実際の状態はローカル設定と待受結果で確認する必要があります。ページを開いたことがない、入口が見えない、サブスクリプションを1件削除した、といった事実だけではバックエンドが停止しているとはいえません。

Clash PartyでSub-Storeが動作していてバックエンド版が分からない場合は、まず信頼できないWebページを閉じ、公開されている悪用コードを探したり実行したりしないでください。Clash Partyの「設定 > Sub-Store」を開いて「Sub-Storeを有効にする」をオフにします。公式ソース上、この操作で内蔵フロントエンドとバックエンドの両サービスが停止します。

同時に「LANからのアクセスを許可」がオフのままであることを確認します。この項目をオンにするとサービスは0.0.0.0にバインドされ、LAN内の端末から直接アクセスできます。オフでは127.0.0.1を使用します。公開報告にはブラウザページからループバックアドレスへ到達する経路も含まれるため、LANアクセスを止めるだけでは更新の代わりになりませんが、ネットワークへの露出拡大は防げます。

Sub-Storeはサブスクリプションの編集・変換・管理ツールであり、Mihomoコアそのものではありません。無効にしても、Clash Partyへ取り込み済みのProfile、ポリシーグループ、システムプロキシ、TUNは通常そのまま利用できます。使えなくなるのは、Sub-Storeページでのサブスクリプション処理です。

更新する前に、「設定 > Sub-Store」で内蔵バックエンドとカスタムバックエンドのどちらを使っているか確認します。内蔵モードではClash Partyがローカルbundleを起動します。カスタムモードでは内蔵バックエンドを停止し、ユーザーが入力したURLへ接続します。アプリ内更新は、外部デプロイ側で行う更新、待受制限、認証の代わりにはなりません。

内蔵バックエンドを使う場合は、信頼できないWebページを閉じたことを確認してからSub-Storeを一時的に有効にし、設定欄の「LANからのアクセスを許可」はオフのままにします。Sub-Storeページの「ブラウザで開く」を使い、画面に表示された実際のアドレスを確認してください。どの端末でも同じポートが固定で使われるとは限りません。

Clash Party v2.0.2のソースでは、バックエンドはデフォルトで127.0.0.1:38324から空きポートを探し、使用中なら番号を順に増やします。バックエンドのルートアドレスを開くと、Sub-Storeの応答にあるdata.versionで実際のバージョンを確認できます。記録するのはバージョンとアドレスだけにし、スクリプト引数の送信や悪用テストは行わないでください。

バージョンが2.11.4～2.37.1なら直ちに更新します。2.11.4未満はこの報告の範囲外でも大幅に古いため、現行安定版へ更新してください。ページを開けない、またはバージョンを確認できない場合は無効の状態へ戻し、「不明」を「安全」とみなさないでください。

以下の手順はClash Partyの内蔵バックエンドだけが対象です。Sub-Storeページ右上には雲形の「更新を確認」ボタンがあります。v2.0.2のソースによると、この入口はsub-store-org/Sub-Storeの公式Releaseにあるlatestからバックエンドとフロントエンドのファイルをダウンロードし、完了後に両サービスを再起動します。

更新をクリックしたら完了表示を待ち、途中でクライアントを終了しないでください。同時にアプリディレクトリのbundleを手作業で上書きすることも避けます。最低目標は2.38.0、現在の目標は2026年9月11日公開の2.39.6です。今後さらに新しい安定版が出た場合は、公式Releasesを基準にしてください。

Mihomoコアの更新、サブスクリプションの再取得、同じClash Partyクライアントの再インストールでは、Sub-Storeバックエンドの確認を代替できません。Sub-Storeは独立してダウンロード・実行されるコンポーネントなので、専用ページで更新し、固有のバージョン番号を読み取る必要があります。

更新成功の表示は最初の確認にすぎません。Clash Partyを再起動した後、Sub-Storeページから実際のバックエンドアドレスとdata.versionを再確認し、古い版へ戻っていないことを確かめます。アドレスがLAN内のアドレスや0.0.0.0ではなく、127.0.0.1を使用していることも確認してください。

次に「Sub-Storeを有効にする」をオフにして、フロントエンドとバックエンドのページへアクセスできなくなったことを確認します。その後、既存のProfileで実際のHTTPSリクエストを1回行います。これにより、無効化スイッチが独立サービスを確実に停止することと、通常のプロキシ処理がSub-Storeの常時稼働に依存しないことを同時に確認できます。

バージョンが報告範囲内でも、すでに悪用されたことを意味しません。未知のプロセス、不審なネットワーク接続、OSのセキュリティソフトによる警告、設定や認証情報の不審な変更などの証拠がある場合に限り、端末侵害の可能性がある事案として扱います。その段階では、更新で今後の侵入口は塞げても、すでに存在するプログラムを削除したり、漏えいした認証情報を元に戻したりはできません。

まずSub-Storeを無効にして端末をネットワークから切り離し、Clash PartyとSub-Storeのバージョン、待受アドレス、警告が出た時刻、不審な現象を記録します。「クリーンアップ」のためにログ、設定、未知のファイルをすぐ削除しないでください。影響範囲を判断する重要な証拠になる可能性があります。

OS標準または組織が承認したセキュリティツールで完全スキャンを行います。サブスクリプションURL、ノードの認証情報、WebDAV、GitHub Token、その他の鍵をその端末で扱っていた場合は、信頼できる別の端末から古い認証情報を失効させ、再発行してください。ログを共有する前には機密情報を除いたコピーを作成します。完全性を確認できない場合は公式ソースからOSまたはクライアントを再インストールし、安全を確認した設定だけを復元してください。

2.38.0以降で特定のサブスクリプション変換やスクリプトが動かなくなっても、機能を戻すために2.37.1以前へダウングレードしないでください。まずSub-Storeを無効にし、動作確認済みのClash Party Profileを引き続き使用します。サブスクリプションを復元する必要がある場合は、信頼できるサービス事業者から元のリンクを再取得するか、更新前の安全なバックアップを取り込みます。

新しいバージョンで、Allow LANがオフ、待受が127.0.0.1に限定されている場合にだけSub-Storeを再度有効にして確認します。第三者スクリプトが制限された古い挙動に依存し続ける場合は、ローカルAPI全体の制限を緩めるのではなく、そのスクリプトの使用を止めてメンテナーへ更新を依頼してください。

今回のリスクの中心はClash Partyが起動するSub-StoreのNodeバックエンドであり、Mihomoコアや、Clashという名前を持つすべてのクライアントではありません。今後の確認では、Clash Partyのバージョン、Sub-Storeのdata.version、Allow LANの状態、実際の待受アドレスをセットで記録してください。

公式の2.38.0リリースで#634は閉じられ、2.39.6が今回の確認時点の現行安定版です。一方、Clash Party #2134は依然としてユーザー報告にとどまります。今後、上流から新しいセキュリティ告知、認証機構、Clash Partyへの統合版が公開された場合は、新しい公式Release、commit、説明に基づいて結論を更新してください。