FR-187 D3 掃描報告：更新中心主系統端（頁面 API、離線上傳、診斷包）

掃描當下版本：commit 1c9be8d84（branch ws-CM-3711-CM-3720）。行號以這個版本為準。

沒有急件，但有一條要排進修正。 這次找到 2 個問題，兩條都是同一個缺口：落地版裡，更新中心沒有檢查操作的人是不是「總部」。

• F1（中）：子公司管理員可以下載整台機器的診斷包，裡面是所有公司最近 24 小時的操作紀錄。如果只看「升級紀錄」，只有讀取權限的人也拿得到。
• F2（低）：子公司管理員可以替整台機器立即升級或排程升級，也可以關掉自動檢查更新。

兩條都經過三個獨立檢查員投票，結果都是 3 比 0 成立。我也自己開檔核對過。

更新中心頁面背後的 API：查目前版本與更新紀錄、檢查新版、下載新版、離線分塊上傳更新包、立即或排程更新、取消與重試、產生並下載診斷包、下載升級紀錄，以及這次新加的 Agent 區（查 Agent 新版、下載、推送給各台 Agent）。

這些動作影響的是整台機器，不是某一家公司。落地版也可以開子公司（子租戶），所以重點是「子公司的管理員是不是碰得到整台機器的東西」。

範圍：4 個檔、約 1135 行。為了查證，我翻了範圍外的 core/host_capabilities.py:214-215、upgrade_order.py:424-463、product_update_flow.py 的上傳段、common/util/chunked_upload.py、resources/roles/shipped-roles.json。這些檔只是拿來查證，本身不算發現。

為什麼 F1 是中、不是高：要先滿足三個條件：客戶在落地版上開了子公司、攻擊者本身就是那家子公司的管理員、拿到的資料已經遮過密碼。外部的人打不到，拿到的也是紀錄，不是帳密。

為什麼 F2 是低：升級只能升到原廠簽過章的新版，換不成惡意程式，最壞就是挑時間讓整台停機。

F1：子公司管理員下載得到整台機器的診斷包與升級紀錄

白話：診斷包是主機上的 guidantai diag 產生的。它在「系統身分」下執行，會跳過「每家公司只能看自己資料」的資料庫隔離機制（RLS），所以包裡是全部公司的 API 紀錄、系統紀錄、Agent 紀錄，再加上 docker 紀錄和遮過的設定檔。「支援頁」也能匯出同一種診斷資料，但那條路只給呼叫者自己公司的資料；更新中心這條路沒有。

_assert_may_write() 只在 SaaS 時要求平台管理員，落地版直接放行。更新中心的兩個權限（system.product-update.read／.update）也沒有標「只限平台」（is_platform）。出廠的「系統管理員」角色是萬用字元 *.*.*，子公司的管理員因此會自動拿到這兩個權限。

出事會怎樣：子公司管理員先按「產生診斷包」（POST /system/product-update/diag），再下載（GET /system/product-update/diag/<diag_id>），就拿到總部和其他子公司的操作紀錄。只有讀取權限的人，可以從狀態 API 拿到 job_id，再打 GET /system/product-update/upgrade-log/<job_id> 下載升級紀錄包。

要先有什麼才打得到：落地版、開了子公司、子公司管理員（或者擁有更新中心讀取權限的人）。

在哪裡：

• app/product_update/service/product_update_app_service.py:104-107：_assert_may_write 只在非落地版擋
• app/product_update/service/product_update_app_service.py:228-230：diag_file
• app/product_update/service/product_update_app_service.py:232-235：upgrade_log_file（route 只掛讀取權限，見 api/product_update/routes/product_update_route.py:205）
• core/host_capabilities.py:214-215：兩個權限都沒有 is_platform

怎麼修：在 diag_file、request_diag、upgrade_log_file 開頭，落地版加 require_tenant_hq()（common/authz/tenant_hq.py）；或者比照支援頁匯出，改用 require_log_viewer('platform.support.export') 再加總部檢查。另一個做法是讓這條路產生的診斷包只含呼叫者自己公司的資料。

小弟開檔核對：成立。 _assert_may_write 的判斷、兩個權限沒有 is_platform、出廠角色是 *.*.*，三點都開檔看過，和描述一致。

F2：子公司管理員可以操作整台機器的升級

白話：更新中心的每個寫入動作（檢查新版、自動檢查開關、下載、離線上傳、立即或排程更新、取消、重試、Agent 推送）都只過 _assert_may_write，這一關在落地版什麼都不擋。系統裡其他「全站共用設定」，例如登入規則、LDAP、日誌轉送，都有過 require_tenant_hq()，只有更新中心漏掉。

出事會怎樣：子公司管理員送 POST /system/product-update/apply、mode=now，整台機器馬上升級，所有公司在升級期間都用不了。他也可以排程更新、關掉每日自動檢查（PUT /auto-check）。有一位檢查員指出，「取消總部排好的升級」這一點說得有點誇大，但「自己發起整台升級」這一點成立。

要先有什麼才打得到：落地版、子公司管理員。

在哪裡：app/product_update/service/product_update_app_service.py:104-107

怎麼修：_assert_may_write 改成：SaaS 照舊要求平台管理員，落地版加呼叫 require_tenant_hq()（平台管理員在那支函式裡本來就會放行）。F1 和 F2 可以合成一張修正卡。

小弟開檔核對：成立（同 F1 的核對）。

1. 子公司拿到 system.product-update.update 能不能升級整台：成立，就是 F2。core/host_capabilities.py:214-215 兩個權限都沒有 is_platform，也沒有「只限總部」的宣告。出廠角色 *.*.* 在子公司只排除 is_platform 的權限，所以子公司管理員一定有這個權限。
2. 離線上傳：不成立（沒問題）。 upload_id 要符合 32 碼十六進位格式（common/util/chunked_upload.py:24,55）。index 在路由宣告成整數，而且會檢查 0 <= index < total_chunks（:97）。每塊最多 50MB，邊讀邊算，超過就中止（:109）。總大小最多 8GB，塊數也有上限（product_update_flow.py:581-584），開始上傳前會先檢查磁碟空間，而且同一時間有下載或更新在跑就回 409。驗章的順序也對：單一離線檔是先讀檔內的清單、驗過簽章，才把包抽出來（product_update_flow.py:674-683）；舊的兩檔送法是清單一開始就要驗過才收包（:592-598）。小缺口：上傳中的檔案不受「同一時間只能一個」的限制，同一個人可以開很多個上傳把磁碟塞滿，但能這樣做的人本來就有更新權限，所以不列為發現。
3. diag_file／upgrade_log_file：路徑本身沒問題。id 要符合 job_id 格式，會跳過符號連結，也會檢查是不是一般檔案（upgrade_order.py:426-431）。權限面有問題，就是 F1。
4. ProductUpdateNoticeRoute 只驗登入：沒問題。 回傳的只有 scheduled_at、version 和固定的提醒分鐘數（product_update_app_service.py:245-246）。
5. package_downloader.py Agent 包路徑：沒問題。 agent_bundle_dir 先用 parse_version 檢查版號格式，不符就丟例外（package_downloader.py:87-89），檔名用的也是同一個版號。
6. 新加的 Agent 方法有沒有漏 @transaction 或權限檢查：Agent 寫入方法都呼叫了 _assert_may_write（:264-311），下載完自動推送的 push_after_download 也有（:328）。這些方法沒有 @transaction，檔案裡的註解說明是刻意的：流程交給下一層各自包交易，不是漏掉。權限檢查本身的缺口和 F2 是同一件事。

• 「這兩條存在嗎」：可信度高。三個檢查員分別從「打不打得到」「影響多大」「有沒有其他防線」三個角度投票，2 條各 3 票，6 票都投出、都成立。我也開檔核對過。
• 「只有這兩條嗎」：不能保證。low 檔只派一個研究員讀完整個範圍，再加一個專門找寫死密碼的研究員。掃描每次結果不一定一樣，沒報出來不代表一定沒有。範圍外的 product_update_flow.py、upgrade_order.py、agent_rollout_service 只讀了查證需要的那幾段，沒有完整掃。
• 程式碼都沒有實際執行，所有結論都是讀程式碼推出來的。

歸檔：docs/features/security-scan-consolidated/runs/be/CLAUDE-SECURITY-20261108-191322/