2026-09-05 — CodeWhale 九項 AI 代理漏洞、SiYuan 發布權限繞過八連發、vLLM 修補被競爭條件繞過

CodeWhale AI 編碼代理爆九項資安公告：Shell 自動核准、參數注入與 SSRF 全踩雷

GitHub Advisories · 2026-09-04

AI 編碼代理專案 CodeWhale（其程式碼與 deepseek-tui 共享同一套核心）在 2026 年 9 月 4 日一次揭露九篇 GHSA 資安公告，涵蓋 shell 自動核准、任意程式碼執行、參數注入與 SSRF 防護繞過等多種攻擊面。這批公告的共同點是：攻擊者只要能讓 AI 模型讀到惡意內容——不論是 clone 下來的 repo 還是外部注入的工具呼叫——就能繞過使用者核准機制執行任意操作。以下整理四個 CVSS 分數最高、機制最具代表性的漏洞。

漏洞機制

GHSA-gx45-xrj5-g6c4（CVE-2026-75911）出在專案設定檔 .codewhale/config.toml：程式碼會無條件複製 project-level 的 allow_shell 布林值，不像其他安全選項只允許「收緊」不允許「放寬」。攻擊者只要在公開 repo 裡放一個 allow_shell = true 的設定檔，受害者 clone 並開啟專案後，AI 模型就取得預設的 shell 執行權。

GHSA-wrj3-vj8c-784f（CVE-2026-75858）則是 rlm_eval 工具本身：它把核准需求回報為 ApprovalRequirement::Auto，讓 LLM 選中的任意 Python 程式碼繞過使用者核准直接執行，攻擊者透過注入到聊天內容的惡意工具呼叫即可在受害者工作站上以其 UID 取得未沙箱化的程式碼執行權，進而讀取憑證、改檔或啟動新程序。

GHSA-c6mw-8xh8-gpq6（CVE-2026-75912）是 git_blame 工具的參數注入：rev 參數未經檢查即傳給 git 指令，攻擊者可注入 --contents=/path/to/file，讓 git 讀出任意檔案內容並回顯進模型輸出，全程不需要使用者核准。

CVSS 最高的 GHSA-6v2g-fpxh-pmmh（CVE-2026-75856，9.2 分）是 DNS pinning 的 TOCTOU 缺陷：程式碼假設「DNS 解析失敗就視為失敗」，但攻擊者可用自架 DNS 先讓初次解析失敗、再於後續查詢中回傳 127.0.0.1，藉此繞過 SSRF 防護、存取內部服務與雲端憑證。

受影響版本

修補與緩解

四個套件生態系（npm codewhale、cargo codewhale-tui、npm/cargo deepseek-tui）的受影響版本區間各不相同，cargo 版 deepseek-tui 在多篇公告中都沒有對應的修補版本，等同無修補可用。其餘五篇公告（GHSA-h539-c7r8-3xq4、GHSA-7j5w-7r7x-9v27、GHSA-g29h-pfmp-qp9r、GHSA-62f5-cp2p-vq95、GHSA-w7wx-5q49-r59w）屬於同一批揭露，涉及類似的核准邏輯繞過與環境變數外洩問題。已升級到 npm codewhale 0.8.64 或 deepseek-tui 0.8.41 的使用者可規避已知路徑，仍在使用 cargo 版 deepseek-tui 的專案則需自行評估風險。

原始來源：SSRF Bypass、allow_shell 覆寫、rlm_eval RCE、git_blame 參數注入、GHSA-h539、GHSA-7j5w、GHSA-g29h、GHSA-62f5、GHSA-w7wx

SiYuan 筆記軟體再爆 8 個公告：發布權限繞過與系統金鑰外洩

GitHub Advisories · 2026-09-04

開源筆記軟體 SiYuan 在 2026 年 9 月 4 日新增 8 篇 GHSA 資安公告，是繼稍早一批共 18 篇公告之後的第二波揭露，GHSA ID 與 CVE 編號皆與前一批不同。這波的核心問題集中在 publish（公開發布）模式下的存取控制：多個 API 端點在判斷文件是否可見時遺漏了密碼或發布權限驗證，讓匿名使用者能讀到原本應被擋下的內容，其中一篇甚至外洩了 session cookie 簽章金鑰等系統機密。

漏洞機制

GHSA-mp7r-57w4-5qm3（CVE-2026-72792）出在 /api/tag/getTag：端點用 FilterTagsByPublishIgnore 檢查文件可見性，卻完全省略密碼驗證，導致密碼保護文件的標籤名稱與使用次數會回傳給未輸入密碼的讀者，洩漏專案名稱、人名等後設資料。

CVSS 8.6 分的 GHSA-h4v5-crx2-3cv4（CVE-2026-72793）是 /api/system/getConf 的遮罩清單漏了三個欄位：session cookie 簽章金鑰、含作業系統帳號的絕對路徑、加密筆記本金鑰材料都會回傳給非管理員或公開模式使用者，根因是遮罩清單與另一個「設定匯出」流程各自維護一份機密欄位清單，兩者沒有同步。

同為 8.6 分的 GHSA-h6w7-xxcf-w2mq（CVE-2026-72795）出在區塊嵌入（transclusion）：被請求的區塊本身有做發布權限檢查，但查詢比對出的內嵌區塊完全沒有過濾，函式 resolveEmbedContentInBox 缺少同類端點 getEmbedBlock 已有的權限檢查，只要對外已發布的文件包含嵌入查詢，就能連帶讀出私密、隱藏或密碼保護文件的內容。

受影響版本

修補與緩解

受影響的都是 github.com/siyuan-note/siyuan/kernel 這個 Go module，版本以 commit 對應的偽版本號（pseudo-version）標示，三篇公告的修補版本各不相同，代表三個問題是在相近但不同的 commit 各自修掉的。其餘五篇公告（GHSA-34fj-mwm6-fjfg、GHSA-fgmr-7w36-9qfq、GHSA-f2rw-w22v-54vh、GHSA-mfrj-v65r-979c、GHSA-5w7r-f4cg-rqq7）屬同一波揭露，同樣圍繞發布權限檢查缺漏。曾經公開部署過舊版 kernel 的站台，升級後應一併輪替 session cookie 簽章金鑰，因為舊金鑰在升級前已經可能被讀取過。

原始來源：getConf 金鑰外洩、嵌入區塊未過濾、tag 密碼驗證遺漏、GHSA-34fj、GHSA-fgmr、GHSA-f2rw、GHSA-mfrj、GHSA-5w7r

vLLM 四個新公告：上一版修補被競爭條件繞過，外加 ReDoS 與路徑洩漏

GitHub Advisories · 2026-09-04

推論引擎 vLLM 在 2026 年 9 月 4 日發布四篇 GHSA 資安公告，全部指向 0.26.0 之前的版本。最值得注意的是一個競爭條件缺陷——先前針對 CVE-2025-62164 的修補在並發請求下可被繞過；另外三篇分別是結構化輸出的正規表達式阻斷服務（ReDoS）、解碼端點的資源耗盡，以及錯誤訊息洩漏伺服器內部路徑與使用者名稱。

漏洞機制

GHSA-pr7f-p5mw-fc87（CVE-2026-73557）的根因是一個跨請求共用、未同步的 process-global PyTorch context：當同一個 /v1/chat/completions 請求裡的兩段 prompt-embedding 在不同 executor 執行緒上並發執行時，其中一段可以把驗證旗標重置回「停用」狀態，讓另一段夾帶的無效 sparse tensor 繞過檢查、抵達原本該被擋下的反序列化端點，前提是伺服器開了 --enable-prompt-embeds。

GHSA-48jh-3gj7-fg8v（CVE-2026-73556）出在 backend_lm_format_enforcer.py：其他 structured-output backend 都有 compile_regex_with_timeout 包住正規表達式編譯，唯獨 lm-format-enforcer backend 是同步直接呼叫：

lmformatenforcer.RegexParser(grammar_spec)  # 無 timeout 保護

攻擊者送入類似 (a{1,300}){300} 的病態正規表達式即可在 interegular 函式庫裡觸發指數級 FSM 建構，卡住整個 engine worker，前提是營運端已手動選用 --structured-outputs-config lm-format-enforcer。

GHSA-hwrm-c4cx-rf4j（CVE-2026-73555）則是任何接受 JSON body 的 POST 端點都能觸發：畸形請求讓 FastAPI 丟出 Pydantic RequestValidationError，既有的訊息清洗函式沒有過濾檔案路徑樣式，直接把作業系統帳號、家目錄、虛擬環境路徑與內部程式行號洩漏在錯誤回應裡，攻擊者可藉此精準指紋比對版本。

GHSA-8737-qx52-hjff（CVE-2026-71486）出在 /v1/completions/derender 與 /v1/chat/completions/derender：端點會把呼叫端提供的 GenerateResponse token ID 直接丟進 detokenize，完全不檢查 context length 或 max_tokens 上限，已通過驗證的用戶端可藉此消耗遠超正常生成流程的 CPU 與記憶體。

受影響版本

修補與緩解

四篇公告的受影響版本都是 vllm < 0.26.0，修補版本統一為 0.26.0。其中競爭條件與 ReDoS 兩篇都需要營運端手動開啟特定旗標才會暴露攻擊面，預設設定下的部署只會受到路徑洩漏與解碼端點資源耗盡影響；有開啟 --enable-prompt-embeds 或非預設 structured-outputs backend 的部署應優先升級。

原始來源：競爭條件繞過、ReDoS、路徑洩漏、解碼端點資源耗盡