Clash Party 內建 Sub-Store 風險怎麼處理？

Sub-Store issue #634 的公開報告把受影響範圍寫為 Node 後端 2.11.4 至 2.37.1，並描述了過寬的跨來源存取與指令碼處理能力組合後的風險。上游隨後用提交 038745f 收緊預設 CORS、限制部分 Node 指令碼操作並增加拒絕測試，2.38.0 的發布說明明確關閉該 issue。

截至 2026 年 9 月 12 日，Sub-Store 目前穩定版是 2.39.6。本文把 2.38.0 作為上游明確關閉 #634 的最低版本邊界，並建議更新到目前穩定版；這不等於 2.38.0 為所有網路暴露增加了認證，也不能據版本號判斷裝置是否已經受到影響。

Clash Party issue #2134 是一條針對 v2.0.2 環境的使用者報告，隨後按專案安全報告流程由機器人關閉，貢獻者建議更新 Sub-Store。Clash Party 可以獨立更新內建後端，所以只看用戶端版本無法確定正在執行的 Sub-Store 版本。

v2.0.2 原始碼把內建 Sub-Store 設為預設啟用，但實際狀態仍以本機設定和監聽結果為準。沒有開啟過頁面、隱藏入口或刪除一條訂閱，都不等於後端已經停用。

如果 Clash Party 正在執行 Sub-Store，但你還不知道後端版本，先關閉不受信任的網頁，不要尋找或執行公開利用程式碼。開啟 Clash Party 的“設定 > Sub-Store”，關閉“啟用 Sub-Store”；官方原始碼顯示，這個動作會停止內建前端和後端服務。

同時確認“允許區域網路存取”保持關閉。該選項開啟時服務會綁定 0.0.0.0，區域網路裝置可直接存取；關閉時使用 127.0.0.1。公開報告包含瀏覽器頁面存取回環位址的路徑，所以只關區域網路存取不能代替更新，但它能避免繼續擴大網路暴露面。

Sub-Store 是訂閱編輯、轉換和管理工具，不是 Mihomo 核心本身。停用後，已經匯入 Clash Party 的 Profile、策略群組、系統代理和 TUN 通常仍可繼續工作，只是不能繼續使用 Sub-Store 頁面處理訂閱。

準備更新時，先在「設定 > Sub-Store」確認使用的是內建後端還是自訂後端。內建模式由 Clash Party 啟動本機 bundle；自訂模式會停止內建後端並連線使用者填寫的 URL，應用內更新不能替代外部部署端自己的升級、監聽限制、身分驗證與存取控制。

使用內建後端時，確保不受信任的網頁已經關閉，再臨時啟用 Sub-Store，並保持該設定區的“允許區域網路存取”關閉。進入 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 後端。它是獨立下載和執行的元件，必須在自己的頁面完成更新並讀取自己的版本號。

更新提示成功只是第一層驗證。重啟 Clash Party 後，再從 Sub-Store 頁面讀取實際後端位址和 data.version，確認版本沒有回到舊值；同時確認位址使用 127.0.0.1，而不是區域網路位址或 0.0.0.0。

然後關閉“啟用 Sub-Store”，確認前端和後端頁面不再可用，再用現有 Profile 完成一次實際 HTTPS 請求。這樣可以同時證明停用開關確實停止獨立服務，也證明普通代理並不依賴 Sub-Store 持續執行。

版本落在報告範圍不等於已經被利用。只有出現未知處理程式、異常網路連線、系統安全軟體告警、設定或認證資訊被異常改動等證據時，才應把事件升級為可能的裝置入侵；此時更新只能封堵後續入口，不能刪除已經存在的程式或恢復洩露的認證資訊。

先停用 Sub-Store 並斷開裝置網路，記錄 Clash Party 與 Sub-Store 版本、監聽位址、告警時間和可疑現象。不要為了“清理”而立即刪除日誌、設定或未知檔案，它們可能是判斷影響範圍的重要證據。

使用作業系統或企業已批准的安全工具做完整掃描。若訂閱 URL、節點認證資訊、WebDAV、GitHub Token 或其他金鑰曾進入該裝置，應從一台可信裝置讓舊認證資訊失效並重新簽發；分享日誌前先製作脫敏副本。完整性無法確認時，從官方來源重新安裝系統或用戶端，並只恢復確認乾淨的設定。

如果 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、提交和說明更新結論。