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

Sub-Storeはサブスクリプションの編集、変換、管理を行うツールで、Mihomoのコアではありません。停止後はClash Partyにインポート済みのProfileで、ポリシーグループ、システムプロキシ、TUNが引き続き使えるか確認してください。通常は影響を受けず、止まるのはSub-Store画面でのサブスクリプション処理です。

Clash Party は内蔵バックエンドを個別に更新できるため、クライアントの版だけでは Sub-Store の安全性を判断できません。Clash Party #2134 は v2.0.2 環境の利用者報告で、貢献者は Sub-Store の更新を勧めていますが、管理者が確認したリスクの結論はありません。

Sub-Store issue #634 の公開報告は Node バックエンド 2.11.4～2.37.1 を対象とし、2.38.0 の公開説明で問題を閉じています。2026 年 9 月 23 日の確認時点の安定版は 2.41.0 で、この版または確認済みの後続安定版へ更新してください。修正であらゆる通信が認証されるわけではなく、版だけで端末が影響を受けていないとも証明できません。

v2.0.2 のソースは内蔵 Sub-Store を既定で有効にしています。動作中かどうかは本機のスイッチと待ち受けアドレスで確認します。ページを開かない、入口を隠す、サブスクリプションを消す、通知が出ない、といったことでは停止を証明できません。版が不明なら次の節に沿って停止し、本機の実際のアドレスで確認してください。

Clash Party で Sub-Store が動作していてバックエンドのバージョンが不明なら、信頼できない Web ページを閉じ、公開された悪用コードを探したり実行したりしないでください。「設定 > Sub-Store」を開き、スイッチが表示されている間に「LAN アクセスを許可」をオフにしてから「Sub-Store を有効にする」をオフにし、内蔵のフロントエンドとバックエンドを停止します。すでに無効なら、隠れたスイッチを変更するためだけにサービスを再度有効にしないでください。

「LAN アクセスを許可」がオンなら 0.0.0.0 で待ち受け、LAN 内の端末から直接アクセスできます。オフなら 127.0.0.1 を使います。報告には Web ページからローカルのループバックアドレスへアクセスする場合も含まれるため、LAN アクセスを無効にするだけでは更新の代わりになりません。アプリを再起動し、既存の Profile で実際の HTTPS リクエストを行って、通常のプロキシが使えることを確認してください。

更新する前に、「設定 > 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、フロントエンドは sub-store-org/Sub-Store-Front-End の公式 latest Release からそれぞれ取得し、完了後に両サービスを再起動します。

最低限の対象は 2.38.0 です。本記事で確認した対象は、2026年9月22日公開の 2.41.0 です。後に別の安定版を選ぶ場合は、公式 Releases で確認してください。

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

コミット 038745f は既定の CORS を制限し、一部の Node スクリプト操作を制限して拒否テストを追加しています。Origin のないリクエストは扱いが異なり、Clash Party の独自バックエンド名では一部のスクリプト制限も適用されません。この変更だけで、すべての API 呼び出しが認証されるとは限りません。

今後、セキュリティ勧告や認証の仕組みが変わった場合は、公式の Release、コミット、説明で確認し直してください。

Clash Party を再起動して Sub-Store の画面から実際のバックエンドのアドレスと data.version を読み、新しい版が維持されているか確認します。アドレスは 127.0.0.1 である必要があり、LAN のアドレスや 0.0.0.0 ではいけません。更新成功の表示だけでは不十分です。

次に「Sub-Storeを有効にする」をオフにして、フロントエンドとバックエンドのページへアクセスできなくなったことを確認します。その後、既存のProfileで実際のHTTPSリクエストを一度行います。これにより、無効化スイッチが独立サービスを確実に停止することと、通常のプロキシ処理が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全体の制限を緩めるのではなく、そのスクリプトの使用を止めてメンテナーへ更新を依頼してください。