// 威脅簡報

Roo Code 自動核准繞過:${ command; } 寫法讓被禁止的 shell 指令躲過檢查

CVSS: 7.7 HIGH
CISA KEV: 未列入
弱點類型: CWE-436
主題: AI 安全

PlainCVE 團隊 · 發布 2026-10-18 · AI 輔助 · 媒體簡報 ↓

AI 審稿 2026-10-18(未經人工)指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

Roo Code 3.54.0 及更早版本把 ${ command; } 誤當成無害寫法;在開啟自動核准且 shell 為 bash 5.3+/ksh93 時,遭提示注入的 AI 代理可在未經同意下執行被禁止的指令;目前沒有已知修補。

誰會中	使用 Roo Code 3.54.0 及更早版本、開啟自動核准執行指令的人(CVE 紀錄標題寫 Auto-Approve;設定名稱「always approve execute」出自研究者文章)。依 CVE 紀錄,還要同時符合:代理讀到攻擊者控制的內容(間接提示注入),而且允許清單裡有可以包住被禁止指令的外層指令(例如 echo)。被藏起來的指令只有在 shell 是 bash 5.3 以上或 ksh93 時才會真的執行。
後果	如果 AI 代理讀到含有惡意指示的檔案、網頁、程式庫或 MCP 結果,它可能提出一個看似無害的指令,裡面藏著你明明列入禁止清單的指令;這個指令會以代理自動執行的權限跑起來,不會先問你。
現在該做什麼	沒有已知的修補版本,專案已封存。PlainCVE 的判斷:關閉「always approve execute」應該可以避開自動執行;長期來看,建議改用仍有維護的工具。
受影響版本	3.54.0 及更早的所有版本(研究者測的是 main 分支 commit b867ec9,研究者標為 v3.53.0;依版本庫紀錄,這個 commit 在 v3.54.0 發布之後)
修好的版本	無已知修補版本;專案已封存,v3.54.0 是最後一個擴充套件版本
CVSS 向量	顯示完整向量 `CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`
時間點	首次公開 2026-10-13

藍隊應對手冊

確認、修補 / 緩解、應變、強化。版本符合受影響條件不等於已被入侵;檢查沒有結果也不等於安全,每一項都有能證明與不能證明的範圍。標記的步驟對應下方攻擊流程裡可以擋下攻擊的那一步。

DETECT確認我受影響嗎?有沒有入侵跡象?

01確認是否使用 Roo Code 3.54.0 以前版本
在哪裡執行:在裝有 VS Code 的電腦上開終端機(bash 或 zsh)執行,只會列出這台電腦 VS Code 已安裝的擴充套件與版本。3.54.0 及更早都受影響。發布頁面顯示 v3.54.0 是最新的擴充套件版本,因此 PlainCVE 判斷已安裝的版本很可能都在受影響範圍內;是否真的會被利用,仍取決於自動核准設定與 shell 版本。限制:這個指令只查得到 VS Code 的 `code` 命令列工具;如果你在其他相容 VS Code 的編輯器裡用 Roo Code,這個指令查不到,要改用該編輯器自己的命令列工具或擴充套件頁面確認。
唯讀查詢
```
code --list-extensions --show-versions | grep -i roo
```
02確認自動核准設定與 shell 版本
「always approve execute」開啟,且代理使用的 shell 是 bash 5.3 以上或 ksh93 時,藏起來的指令才會自動執行。在哪裡執行:在 Roo Code 實際執行指令的那台電腦上,開 VS Code 的整合終端機執行;只讀取版本,不會修改環境。限制:這個指令只顯示 PATH 裡找到的 bash 版本,不一定是代理實際使用的 shell,也查不到 ksh93,更查不到自動核准設定。Roo Code 官方文件把「Use Inline Terminal」標為建議(recommended);原始碼中兩處預設值寫法不一致,無法確認預設是否開啟。依官方文件,開啟「Use Inline Terminal」時會用背景的 execa 執行指令,繞過 shell 設定檔與 VS Code 的 shell integration,文件沒有說明這時用的是哪個 shell;只有關掉 Inline Terminal 時,才會使用 VS Code 整合終端機與你的 shell 設定檔(可在命令選擇區執行「Terminal: Select Default Profile」查看預設設定檔)。因此代理實際用哪個 shell 需要另外確認,不能只看預設設定檔;自動核准是否開啟,要到 Roo Code 的自動核准設定裡看。
唯讀查詢
```
bash --version | head -n 1
```
步驟 3 步驟 4
03檢查代理曾執行過的終端機指令
PlainCVE 的建議:回頭看代理自動執行的指令,留意允許清單內的指令中是否夾帶 ${ 開頭、裡面還有另一個指令的寫法。來源沒有提供偵測指引。
步驟 2 步驟 4

MITIGATE修補 / 緩解先修補;還不能修補時先擋住

01關閉「always approve execute」
這是 PlainCVE 的判斷,不是廠商指引:繞過需要自動核准開啟,關閉後每個指令都會先問你。
步驟 3
02不要在 bash 5.3+/ksh93 環境搭配自動核准
PlainCVE 的判斷:研究者指出不支援這種寫法的 shell 不會執行藏起來的指令,但解析器缺陷仍在,這只是降低風險,不是修補。
步驟 4

RESPOND應變發現入侵跡象時

01假設代理能碰到的東西都可能被動過
PlainCVE 的建議:如果發現被禁止的指令曾被執行,檢查代理權限範圍內的檔案與憑證,必要時輪替憑證。來源沒有提供事件回應指引。
步驟 4

HARDEN強化長期避免同類問題

01改用仍有維護的工具
CVE 編號核發時產品已被標記為不再支援,專案也已封存;PlainCVE 認為不太可能出現修補版。
02不要把允許/禁止清單當成唯一防線
PlainCVE 的建議:清單依賴解析器正確理解 shell 語法,一旦解讀不一致就會失效;搭配最小權限與隔離環境。
步驟 1 步驟 4

完整修復步驟與說明

沒有任何來源提到修補版本、修補 commit 或廠商公告。廠商的發布頁面顯示 v3.54.0 是最後一個擴充套件版本,儲存庫也已封存,因此 PlainCVE 判斷不太可能出現修補版。以下都是 PlainCVE 的判斷,不是廠商指引:

先看 shell 版本。 在 Roo Code 執行指令的那台電腦上,開 VS Code 整合終端機執行 bash --version(這只看得到 PATH 裡的 bash。Roo Code 官方文件把「Use Inline Terminal」標為建議(recommended);原始碼中兩處預設值寫法不一致,無法確認預設是否開啟。依官方文件,開啟它時會用背景 execa 執行、繞過 shell 設定檔,文件沒說明這時用哪個 shell;只有關掉 Inline Terminal 才會使用 VS Code 整合終端機的預設設定檔。代理實際用哪個 shell 需要另外確認,不能因為預設設定檔是 zsh 就認定不會實際執行);若是 5.3 以上,或代理使用 ksh93,而且你開著自動核准,就屬於會實際執行的情境。
關閉自動核准是最直接的做法。 繞過的前提是「always approve execute」開啟;關閉後每個指令都要你親自同意。只換成 zsh 或舊版 bash 只是讓指令不執行,解析器缺陷仍在,不算修好。
規劃移轉。 產品已不受支援,長期應改用仍有維護的工具。

攻擊流程

從左到右是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

由上到下是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。

攻擊者
在代理會讀到的內容裡藏入惡意指示
這叫「間接提示注入」:攻擊者不用直接操作你的電腦,只要把指示放進代理會讀的檔案、網頁、程式庫或 MCP 結果。
防禦: 不要讓開啟自動執行的代理處理不受信任的內容。
你的系統
代理提出一個允許清單內的指令,裡面藏著被禁止的指令
外層是像 echo 這類允許清單內的指令,被禁止的指令包在 ${ ...; } 這種寫法裡。
你的系統
parseCommandLine() 把它當成無害的參數展開,沒有檢查裡面的指令
解析器用一條規則把所有 ${...} 換成佔位符,所以裡面的指令不會被拿去比對允許/禁止清單。
防禦: PlainCVE 的判斷:關閉「always approve execute」,讓每個指令都要你親自同意。
你的系統
指令被自動核准,shell 執行藏起來的指令
只有 bash 5.3 以上或 ksh93 會執行它,以代理自動執行的權限運行。研究者指出 zsh 或 bash 5.2 以前不會執行,但解析器的缺陷仍然存在。
防禦: 讓代理在權限最小的環境執行,限制它能碰到的檔案與憑證。

影響範圍

條件	是否受影響
Roo Code 3.54.0 及更早 + 開啟自動核准(研究者文章稱為「always approve execute」)+ shell 為 bash 5.3 以上或 ksh93 + 允許清單內有可包住被禁止指令的外層指令(例如 echo)+ 代理讀到攻擊者控制的內容(間接提示注入)	受影響,被禁止的指令可能未經同意自動執行(依 CVE 紀錄)
Roo Code 3.54.0 及更早 + 開啟自動核准 + shell 為 zsh 或 bash 5.2 以前	研究者指出指令不會執行,但解析器缺陷仍存在
Roo Code 3.54.0 及更早 + 沒有開啟自動核准	指令會先詢問你;PlainCVE 判斷不會被自動執行
有修補的版本	沒有任何來源提到修補版本

本頁提到的「研究者文章」是發現者 Minqiang Gui、Siyu Lou 在 GitHub 發表的漏洞說明(CVE 紀錄列為 Researcher Disclosure);該頁含攻擊程式,本站不連結。研究者測試的是 main 分支的 commit b867ec9,研究者把它標為 v3.53.0;但依版本庫紀錄,v3.53.0 的發布 commit 不是它,b867ec9 是 2026 年 5 月 15 日、在 v3.54.0 發布 commit(f49f0ce)之後的第 2 個 commit。CVE 的核發單位 VulnCheck 把它標記為 unsupported-when-assigned,意思是核發 CVE 時產品已不再受支援。廠商的 GitHub 儲存庫已封存(唯讀),封存日期來源說法不一:儲存庫橫幅寫 2026 年 5 月 15 日,研究者文章引用的是 5 月 16 日。另有第三方新聞追蹤網站指出 Roo Code 整套服務(Extension、Cloud、Router)在 2026 年 5 月 15 日停止營運。

原理

Roo Code 是一個 AI 程式設計助手(「代理」),可以替你在終端機執行 shell 指令。開啟自動核准(研究者文章稱這個設定為「always approve execute」,本頁沿用這個名稱;CVE 紀錄只寫 auto-approve)後,它不再逐一詢問你,而是把每個指令拿去比對允許清單和禁止清單,自動決定放不放行。

要做這個比對,它得先把一行指令拆開,找出裡面所有真正會被執行的指令,這由 parseCommandLine() 負責。問題出在它對 ${...} 的處理:

在舊的 shell 裡,${NAME} 這類寫法叫「參數展開」,只是讀取變數值,不會執行任何東西。
bash 5.3(2025 年)新增了 ${ command; } 這種寫法(稱為 funsub 指令替換),它會執行裡面的指令。

Roo Code 的解析器用一條正規表示式把所有 ${...} 都當成參數展開,換成佔位符藏起來,於是藏在裡面的指令完全沒被拿去比對清單。外層只剩一個像 echo 這種允許清單內的指令,就被自動核准了。解析器和 shell 對同一段文字的理解不一樣,這類問題對應 CWE-436(解讀衝突)。

真正的觸發者通常不是使用者本人,而是「間接提示注入」:代理讀到的檔案、網頁、程式庫或 MCP 結果裡藏了指示,引導它提出這樣的指令。指令會以代理自動執行的權限運行。

有問題的思路(概念示意,不是原始程式碼):

展開程式碼範例(ts)

// 所有 ${...} 都當成「只是變數」,換成佔位符
cmd = cmd.replace(/\$\{[^}]+\}/g, () => PLACEHOLDER)
// 之後只檢查剩下的外層指令 → 在允許清單內 → 自動核准

研究者建議的思路(依研究者文章,該頁含攻擊程式,本站不連結;概念示意,不是廠商修補):

展開程式碼範例(ts)

// ${ ...; } 這種 funsub 形式不是參數展開,
// 要把裡面的指令取出來,像其他指令替換一樣比對允許/禁止清單
if (isFunsub(segment)) {
  checkAgainstLists(innerCommand(segment))
}

時間軸

日期	事件
2025(依研究者文章)	bash 5.3 新增 `${ command; }` 寫法;bash 發布說明確認了此新語法
2026-05-15	第三方新聞追蹤網站指出 Roo Code 整套服務停止營運
2026-05-15 或 05-16	儲存庫封存(儲存庫橫幅寫 15 日,研究者文章引用 16 日)
2026-10-13	CVE 公開;NVD 收錄;GitHub 公告 GHSA-mfc9-vhw7-f5w9 發布(GitHub 未審查)
2026-10-14	截至本日未列入 CISA KEV
2026-10-15	NVD 完成分析(狀態「Analyzed」),但沒有給自己的分數,只列核發單位 VulnCheck 的分數

驗證紀錄 AI 依審稿規則逐項核對來源,全部通過;未經人工審稿,也尚未在我們的環境重現

AI 審稿	2026-10-18 · 審稿規則

驗證紀錄只寫環境與結果,不公開重現步驟或可攻擊他人系統的程式。詳見政策.

來源

CVE / NVD / OSVCVE-2026-110204 Record (CVE API) · CVE Program / VulnCheck (CNA), 2026-10-13 · 查閱 2026-10-14
CVE / NVD / OSVNVD - CVE-2026-110204 · NIST, 2026-10-13 · 查閱 2026-10-14
安全公告Roo Code through 3.54.0 Auto-Approve Bypass via Funsub Command Substitution · VulnCheck · 查閱 2026-10-14
安全公告GitHub Advisory Database: GHSA-mfc9-vhw7-f5w9 · GitHub, 2026-10-13 · 查閱 2026-10-14
廠商說明Roo-Code v3.54.0 src/shared/parse-command.ts · RooCodeInc (GitHub) · 查閱 2026-10-14
廠商說明Roo-Code releases · RooCodeInc (GitHub) · 查閱 2026-10-14
廠商說明Roo Code docs - Shell Integration (Use Inline Terminal) · RooCodeInc · 查閱 2026-10-14
廠商說明GitHub compare: Roo-Code v3.54.0...b867ec9 · GitHub · 查閱 2026-10-14
其他Bash NEWS (bash 5.3 changes) · Chet Ramey / Case Western Reserve University · 查閱 2026-10-14
新聞報導Roomote / Roo Code sunset · Distill Intelligence · 查閱 2026-10-14
安全公告Roo Code command injection via parameter expansion parsing (CVE-2026-63108) · VulnCheck · 查閱 2026-10-14

媒體簡報

一句話

Roo Code 是一套能替開發者自動執行 shell 指令的 AI 程式設計助手。它判斷指令是否允許的解析器,會把 bash 5.3 新增的 ${ command; } 寫法誤當成無害內容,因此在開啟「always approve execute」且 shell 為 bash 5.3 以上或 ksh93 時,遭提示注入的代理提出的被禁止指令可在未經使用者同意下執行。CVE 於 2026 年 10 月 13 日公開,影響 3.54.0 及更早版本;專案已於 2026 年 5 月封存,目前沒有已知修補。截至 10 月 14 日,未列入 CISA 已知遭利用漏洞清單。

關鍵數字

嚴重度: CVSS 4.0 7.7;CVSS 3.1 8.8(VulnCheck) cveawg.mitre.org
受影響版本: 3.54.0 及更早 cveawg.mitre.org
公開日期: 2026-10-13 cveawg.mitre.org
GitHub 公告編號: GHSA-mfc9-vhw7-f5w9(GitHub 未審查) api.github.com
發現者: Minqiang Gui、Siyu Lou vulncheck.com

已確認

Roo Code 3.54.0 及更早版本的 parseCommandLine() 把 ${ command; } 當成參數展開,裡面的指令不會被檢查。
在開啟「always approve execute」時,藏在允許清單指令內的被禁止指令可在 bash 5.3 以上或 ksh93 上未經使用者同意執行。
CISA 的 SSVC 評估標示已有公開概念驗證(poc);截至 2026-10-14 未列入 KEV。

尚未確認 / 說法不一

專案封存日期說法不一:儲存庫橫幅寫 2026-05-15,研究者文章引用的是 2026-05-16。
沒有任何來源指出修補版本、修補 commit 或廠商公告。
沒有來源回報實際遭利用,也沒有來源說它曾被當成零時差漏洞利用。

可引用的一句話

禁止清單只擋得住它看得懂的指令;shell 多學了一種新寫法,守門員卻沒跟上。

圖片

下載分享圖(PNG) · 攻擊流程圖(可下載)

引用時請標示「PlainCVE」並附上本頁連結。完整引用格式見下方「如何引用本頁」。有事實錯誤請回報.

Roo Code 自動核准繞過:${ command; } 寫法讓被禁止的 shell 指令躲過檢查

Roo Code 是一套能替開發者自動執行 shell 指令的 AI 程式設計助手。它判斷指令是否允許的解析器,會把 bash 5.3 新增的 ${ command; } 寫法誤當成無害內容,因此在開啟「always approve execute」且 shell 為 bash 5.3 以上或 ksh93 時,遭提示注入的代理提出的被禁止指令可在未經使用者同意下執行。CVE 於 2026 年 10 月 13 日公開,影響 3.54.0 及更早版本;專案已於 2026 年 5 月封存,目前沒有已知修補。截至 10 月 14 日,未列入 CISA 已知遭利用漏洞清單。

關鍵數字:
- 嚴重度:CVSS 4.0 7.7;CVSS 3.1 8.8(VulnCheck)(https://cveawg.mitre.org/api/cve/CVE-2026-110204)
- 受影響版本:3.54.0 及更早(https://cveawg.mitre.org/api/cve/CVE-2026-110204)
- 公開日期:2026-10-13(https://cveawg.mitre.org/api/cve/CVE-2026-110204)
- GitHub 公告編號:GHSA-mfc9-vhw7-f5w9(GitHub 未審查)(https://api.github.com/advisories?cve_id=CVE-2026-110204)
- 發現者:Minqiang Gui、Siyu Lou(https://www.vulncheck.com/advisories/roo-code-through-3.54.0-auto-approve-bypass-via-funsub-command-substitution)

已確認:
- Roo Code 3.54.0 及更早版本的 parseCommandLine() 把 ${ command; } 當成參數展開,裡面的指令不會被檢查。
- 在開啟「always approve execute」時,藏在允許清單指令內的被禁止指令可在 bash 5.3 以上或 ksh93 上未經使用者同意執行。
- CISA 的 SSVC 評估標示已有公開概念驗證(poc);截至 2026-10-14 未列入 KEV。

尚未確認 / 說法不一:
- 專案封存日期說法不一:儲存庫橫幅寫 2026-05-15,研究者文章引用的是 2026-05-16。
- 沒有任何來源指出修補版本、修補 commit 或廠商公告。
- 沒有來源回報實際遭利用,也沒有來源說它曾被當成零時差漏洞利用。

「禁止清單只擋得住它看得懂的指令;shell 多學了一種新寫法,守門員卻沒跟上。」— PlainCVE
https://plaincve.date/vulns/cve-2026-110204-roo-code-funsub-approval-bypass

如何引用本頁

本文採 CC BY 4.0,轉載請保留署名與連結。

PlainCVE 團隊(2026)。《Roo Code 自動核准繞過:${ command; } 寫法讓被禁止的 shell 指令躲過檢查》。PlainCVE。https://plaincve.date/vulns/cve-2026-110204-roo-code-funsub-approval-bypass(查閱日期:YYYY-MM-DD)

BibTeX

@misc{cve2026110204roocodefunsubapprovalbypass2026,
  title  = {Roo Code 自動核准繞過:${ command; } 寫法讓被禁止的 shell 指令躲過檢查},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-110204-roo-code-funsub-approval-bypass},
  note   = {更新於 2026-10-18}
}