🔴 一頁看完

B1 掃完了。結論：只要有一個能登入的帳號，再知道某個檔案的編號，就能把別家客戶的檔案下載走、線上預覽、永久刪除——系統從頭到尾只檢查「你有沒有登入」，從來沒檢查過「這個檔是不是你的」。

而且還能替別人的檔案換發一張免登入的下載通行證，直接把網址傳給公司外面的任何人。另有一條：上傳一個網頁檔，別人一點預覽就會在我們自己的網域裡執行。

四條全是同一個病：認得出你是誰，但不管你能碰什麼。四條共用同一道修法。

好消息：卡片列為「本棒最重要」的路徑穿越經查不成立——但它是靠執行順序意外擋住的，不是有人刻意防的，重構就會長回來。

B2 回答了 B1 留下的問題：宿主那半邊有沒有補上檢查？沒有。 合起來是一條四層全空的路徑——網址入口只驗登入、業務邏輯零檢查、資料查詢無範圍條件、資料表連租戶欄位都沒有（隔離也是關的）。沒有任何一層會問「這個檔是不是你的」。

B2 另外人工追出一條同級的：任何登入者打一支查設定的 GET，就拿到自己租戶物件儲存的位址、帳號、密碼明文——拿到後可完全繞過系統直接連上倉庫，應用層再怎麼補都管不到。三處小改可修。

📄 B1 報告｜B2 報告｜B1b 待派。

產品裡所有「上傳檔案、下載檔案、預覽檔案」都經過這支套件。它決定三件事：

• 使用者傳上來的檔案存到哪（主機硬碟、物件儲存、或客戶自己的設備）
• 存成什麼檔名、放在哪個目錄
• 下載時怎麼判斷**「這個檔是不是你的」**

這個 arc 要回答：有沒有辦法把檔案寫到不該寫的地方、有沒有辦法下載到別人的檔案、儲存憑證會不會外洩。

• 從未掃過。 跨 arc 總表把它列在建議順序第三，理由是「路徑穿越與任意檔案讀取的天然溫床」。
• 存檔案的那張表沒有多租戶欄位（建表腳本檔頭自陳），意思是資料庫層對它沒有任何隔離兜底——應用層的歸屬檢查是唯一防線。
• 首腦盤點看到的疑點密度高於前幾支（見下）。

第 1、2、3 條若都成立，合起來就是一條完整的跨租戶取檔路徑——這正是三棒要分別驗證的。

三棒是一條路徑的三段：B1 查「請求進來時路徑是不是使用者可控」→ B2 查「挑後端時有沒有驗歸屬」→ B1b 查「落地時有沒有兜底」。驗收時要互相對照。

🔴 砍掉了原本規劃的第四棒

偵察建議過一棒「remote_agent 檔案通道」，首腦查證後砍掉——它與 FR-077 的 CM-1594（R3 宿主接線，17 檔）範圍完全重疊。要掃那條路請派 CM-1594，不要在本 arc 重開。

檔數已核對（排名表過時）

跨 arc 總表的排名表寫「61 檔／2,510 行」，實際是 68 檔／2,877 行（排除測試與報告目錄後），低估約 11%。已據實際數字切棒。

（掃完驗收後才會有。依決策者裁定，修正卡先不開，發現登記進跨 arc 總表 §3。）

• 套件：~/Projects/Jedicogy/module/jedi-python-package/jedi-file-upload/
• 宿主接線：app/upload_file/、infra/upload_file/、core/upload_file_wiring.py
• 相關前案：CM-1594（FR-077 R3，遠端 agent 宿主接線，與本 arc 砍掉的那棒重疊）、CM-1633（FR-081 I3，另一支套件的附件功能）、CM-1559（FR-085 C1，無身分時隔離關掉）
• 首腦手冊：.claude/skills/security-scan-lead/SKILL.md
• 跨 arc 總表：security-scan-consolidated/
• 現況：FR-075/handoff/security-scan-STATE.md

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

其他文件

卡片內容（決策紀錄、驗收條件）以 Notion 為準，本頁只記座標。

相關需求：

• FR-075 — jedi-package-security-audit
• FR-077 — remote-agent-security-scan
• FR-081 — issue-tracking-security-scan
• FR-085 — common-security-scan