**有風險。最重要的是：原生視窗雖然要求確認，卻沒有可靠地證明收到金鑰的就是視窗所稱的「這個瀏覽器」。** 我建議修正後再把它視為安全的配對入口。

本次針對 `96ad9d5` 做原始碼靜態檢視；未執行 App、攻擊重現或正式環境測試。

1. **高風險，需 Cloud 頁面遭控制及使用者確認：可替換配對對象。**

   `CloudPairLocal` 接收網頁提供的 `offer`，原生確認只顯示本機名稱，沒有顯示接收端的裝置識別或指紋，也沒有把 offer 綁定到目前 WebView 持有的金鑰。使用者同意後，就把該 offer 送進具有本機權限的配對 API。位置：[`CloudPairing.swift` 第 245–269 行](https://github.com/sainteye/clawdline/blob/96ad9d5e9cd5658f803b27a205901b6f53099e88/shell/darwin/CloudPairing.swift#L245)。

   因此，若 Cloud 主頁遭 XSS、供應鏈或部署入侵，攻擊者可以提交同帳號下、由攻擊者持有私鑰的有效 offer，誘使使用者按下「與這台機器配對」。後端會驗證帳號與 offer，但無法證明它代表目前這個 WebView；完成後會交付內容金鑰並寫入信任紀錄。**事後在網頁核對指紋，無法阻止已完成的金鑰交付。** [`pairing.go` 第 332–469 行](https://github.com/sainteye/clawdline/blob/96ad9d5e9cd5658f803b27a205901b6f53099e88/internal/transport/cloud/pairing.go#L332)。

   建議把接收端金鑰與配對流程綁定到原生持有的狀態，並在交付前完成可信的接收端確認。僅增加網頁提示不足以解決。

2. **中風險：舊的助理配對橋在確認後沒有重新檢查來源。**

   `CloudPairAgent` 在收到訊息時檢查 Cloud 主框架，但原生確認視窗結束後，直接執行 `handOff`；沒有像新的 `CloudPairLocal` 再次檢查頁面來源。因此即使頁面已離開 Cloud，舊請求仍可能啟動本機助理工作。這是既有路徑，本 commit 仍保留它。建議導頁立即取消待確認請求，確認後也核對來源與文件世代。 [`CloudPairing.swift` 第 71–110 行](https://github.com/sainteye/clawdline/blob/96ad9d5e9cd5658f803b27a205901b6f53099e88/shell/darwin/CloudPairing.swift#L71)。

已有的防護是有效的：新橋檢查主框架、scheme／host／port，確認後再檢查來源；本機 token 留在原生端，配對 API 也拒絕 Cloud 轉入的管理請求。**目前未找到一般外站免確認即可配對的路徑。** [來源檢查](https://github.com/sainteye/clawdline/blob/96ad9d5e9cd5658f803b27a205901b6f53099e88/shell/darwin/Pairing.swift#L315)、[本機管理限制](https://github.com/sainteye/clawdline/blob/96ad9d5e9cd5658f803b27a205901b6f53099e88/internal/transport/http/cloud.go#L401)。

Fixed but not yet released (awaiting review): Nothing（本次僅審查，未修改）。