n8n 沙箱漏洞再遭繞過：流程編輯者或可控制自架主機

有登入門檻，風險一樣唔細

n8n 公開咗一個 CVSS 8.7 高風險漏洞。攻擊者要先登入，兼且有建立或修改自動化流程嘅權限，先至有條件利用；所以呢件事唔代表任何街外人都可以直接攻入一部 n8n server。不過成功繞過沙箱之後，對方可以用 n8n 服務 process 嘅身份執行主機指令，原有嘅流程編輯權限亦隨即升級成主機層面嘅控制能力。

圖片：Wikimedia Commons — Rissy123（Public domain）

沙箱漏咗一種 JavaScript 寫法

n8n 容許用戶喺節點參數加入 JavaScript expression，用嚟整理上一個步驟傳入嘅資料。呢類程式碼理應留喺受限制嘅沙箱入面，接觸唔到真正嘅 Node.js 執行環境。今次漏洞同精簡寫法嘅 arrow function 有關：部分變數冇跟足原有檢查，結果有機會掂到沙箱外嘅物件，再一路去到系統指令層。完整利用碼涉及直接攻擊用途，呢度唔展開。

舊修補俾人換個角度再繞過

iThome 報道指，Security Joes 研究員重新檢視今年 2 月漏洞 CVE-2026-27577 嘅修補方法，逐種檢查 JavaScript 語法點樣經 n8n 處理，最後發現直接傳回單一 expression 嘅 arrow function 冇套用完整限制。呢個背景幾關鍵：今次唔似一個完全獨立嘅小錯，而係研究員沿住舊沙箱邊界繼續測，搵到修補未覆蓋嘅路徑。

受影響版本包括 1.x

GitHub 官方公告列出嘅受影響範圍係 低過 2.31.5 嘅所有版本，另加 2.32.0；修補版就係 2.31.5 同 2.32.1。換句話講，仍然留喺 1.x 嘅自架部署同樣中招，而官方冇列出獨立嘅 1.x 修補版。管理員應先備份資料同核對升級相容性，再升上 2.31.5、2.32.1 或更新版本，唔好只靠限制登入頂住。

流程編輯權限其實相當敏感

好多團隊會覺得「editor」只係改下節點、API request 同資料格式，權限自然低過 server admin。今次漏洞正好提醒大家，低代碼平台本身會執行用戶編排嘅邏輯，仲連住唔同內部服務；**有得改 production workflow 嘅帳戶，權限管理應該跟有得 deploy production code 嘅帳戶睇齊。**外判人員、短期項目成員同 AI agent 共用帳戶，做完項目就要收權，亦要定期重查 project membership 同共享流程。

API key 同 OAuth token 都要計入風險

成功利用之後可以攞到幾多資料，要睇 n8n process 本身有咩權限、容器掛載咗咩目錄、可以連去邊啲內部服務，同 secrets 點樣存放。自架 n8n 常見會用到 API key、OAuth token、資料庫帳密同 webhook secret；一旦有可疑修改、陌生登入或者異常指令痕跡，就應該當相關憑證可能外洩，查清楚使用紀錄，再撤銷同換新。

升級之外，亦要減低出事時嘅影響範圍

官方話未能即時升級嘅部署，可以暫時只准完全可信嘅人登入同編輯流程，但亦明講呢個方法未能徹底修補漏洞。管理員仲應檢查近期流程版本、執行紀錄同主機 log，移除過期帳戶，限制 n8n 服務帳戶權限，同埋收窄容器可讀嘅目錄，同埋可連接嘅內部服務範圍；冇實際用途就唔好掛入 Docker socket。n8n 內置 security audit 亦可以協助搵出過期版本、危險節點同檔案系統相關風險。

參考來源

• iThome — 工作流程自動化平臺n8n表達式沙箱再遭繞過，工作流程編輯者可執行主機命令 — original report
• n8n 官方安全公告 GHSA-gv7g-jm28-cr3m — 核對受影響版本、修補版本、利用前設、CVSS 8.7 同暫時緩解方法
• n8n 2.31.5 官方發布頁 — 確認 2.31 分支可用嘅已修補版本
• n8n 2.32.1 官方發布頁 — 確認 2.32 分支可用嘅已修補版本
• n8n 官方權限及流程共享文件 — 核對 creator、editor 同共享憑證之間嘅權限關係
• n8n 官方 Security Audit 文件 — 補充管理員檢查過期版本、危險節點、憑證同檔案系統風險嘅方法

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。