這起事件表面上是 SiYuan 筆記軟體的一個端點漏做權限檢查，真正值得注意的卻是更普遍的問題：當應用程式把檔案、資料庫、外掛與系統操作包裝成 MCP 工具後，一個原本只該「看內容」的身分，可能瞬間取得接近管理員的能力。
事件背景：不是破解密碼，而是繞過角色邊界
CVE-2026-66012 被列為 CWE-862「缺少授權檢查」，CVSS 分數為 10。彙整頁面指出，SiYuan 3.7.2 以前版本的 POST /mcp 僅檢查請求是否通過一般身分驗證，沒有確認呼叫者是不是管理員，也沒有套用唯讀限制，因此暴露 31 項 MCP 工具。來源：https://cvefeed.io/vuln/detail/CVE-2026-66012
SiYuan 官方 GitHub 安全公告提供了更精確的版本資訊：明確列出的受影響版本是 3.7.1，修補版本為 3.7.2；官方 Docker 映像與使用相同核心的桌面版都在影響範圍內，但必須啟用 Publish 功能才會形成公告描述的攻擊路徑。來源：https://github.com/siyuan-note/siyuan/security/advisories/GHSA-cvhv-7xhj-xjp8
漏洞如何運作
攻擊鏈由三層權限落差串起。第一層是 Publish 反向代理：在開啟 Publish、但未啟用其密碼驗證時，系統會替匿名訪客附上一個 Reader 角色的 JWT。這原本可理解為讓公開文件訪客取得最低限度的讀取身分。
第二層是 MCP 路由只做「你是不是已驗證身分」的檢查，卻沒有問「你的角色能不能執行這個動作」。Reader JWT 因而足以抵達 MCP 工具。即使 Publish 設了密碼，官方公告仍指出，持有合法 Reader 帳號的人也能取得相同工具能力；差別只在於前者是遠端未登入攻擊，後者是低權限帳號升權。
第三層是工具本身的權能過大。其中的檔案工具可在整個工作區執行列出、讀取、寫入、刪除、重新命名與複製。路徑保護確實會阻止跳出工作區，卻沒有保護工作區內的設定檔、筆記資料與外掛目錄。換句話說，沙箱邊界仍在，但敏感資產全被放在沙箱裡。
從讀者到管理員，再到主機端執行
根據官方公告，攻擊者可讀取工作區內的 conf/conf.json，其中包含管理驗證碼、API token 與 cookie 簽章金鑰；取得這些資料後，可進一步登入管理介面。攻擊者也能改寫筆記、刪除檔案與版本歷程，因而同時衝擊機密性、完整性及可用性。
桌面版還多一層風險：若惡意外掛被寫入工作區的外掛目錄，下次開啟桌面程式時，可能在允許 Node.js 整合、且未啟用 context isolation 的環境中載入，最終以桌面使用者權限執行程式碼。這不是單一請求立即取得作業系統權限，而是「先寫入、等待使用者下次啟動」的持久化路徑；區分這點，有助於正確評估事件應變時限。
為何現在值得注意
可確認的事實是：漏洞存在於 SiYuan 的授權實作，並已有 3.7.2 修補版。SiYuan 的 3.7.2 官方發布頁也列有「修正部分安全漏洞」，但沒有在版本說明中逐項對應此 CVE；補丁版本的直接依據仍應以安全公告為準。來源：https://github.com/siyuan-note/siyuan/releases/tag/v3.7.2
合理推論則是，MCP 正把過去分散在多個 API 的高權限操作，集中成一個方便代理程式探索與呼叫的入口。這不表示 MCP 協定本身有漏洞；問題在於開發者容易把「工具說明寫著唯讀」、「呼叫者已有 token」誤當成安全控制。自然語言描述不是強制政策，通過驗證也不等於擁有授權。
作者觀點是：MCP 端點應被視為新的管理平面，而非一般聊天或整合功能。只要它能觸及檔案、SQL、外掛安裝或設定變更，就應逐工具檢查角色、操作類型與資源範圍，不能只在入口做一次粗粒度驗證。
容易忽略的限制
- 官方公告描述的未登入攻擊需要 Publish 已啟用，且匿名模式未開啟驗證；未啟用 Publish 的部署不具備這條公開代理路徑。
- 已啟用 Publish 密碼不代表安全：Reader 使用者仍可能利用缺少角色檢查的 MCP 端點升權。
- 公告證實的是工作區內任意讀寫，不是任意寫入整台主機的所有路徑；主機端執行還依賴桌面版載入被植入的外掛。
- CVSS 10 代表最壞條件下的技術嚴重度，不等同已發現大規模利用。現有來源沒有提供遭野外利用的證據，不宜把可重現漏洞寫成正在爆發的攻擊事件。
對台灣自架環境的意義
台灣的個人工作室、研究團隊與中小企業常以 NAS、Docker 或雲端主機自架知識庫，並透過反向代理公開文件。這類部署最該先確認實際版本與 Publish 設定，而不是只看主服務是否設有登入密碼。若仍使用 3.7.1，應升級至 3.7.2 或更新版本；暫時無法更新時，至少停用不必要的 Publish、限制網路來源，並避免讓 Publish 埠直接暴露於網際網路。
若系統曾以受影響設定公開，更新只能關閉入口，不能證明過去未被使用。管理者仍應檢查外掛目錄、工作區異常修改與刪除紀錄，並更換設定檔中可能外洩的管理驗證碼、API token及相關工作階段金鑰。後續最值得觀察的指標，包括官方是否公布更細的修補差異、是否出現可信的野外利用證據，以及其他導入 MCP 的自架應用是否也把 Reader、Editor 與 Administrator 共用同一組高權限工具。