2026年2月，廣受採用的開源工作流程自動化平台 n8n 被公開披露存在一項關鍵的沙箱逃逸漏洞。此漏洞編號為 CVE-2026-25049，可讓經認證的使用者繞過表達式評估沙箱，並在主機伺服器上執行任意系統指令，從而實現完整的遠端程式碼執行，其 CVSS v3.1 分數為 9.9。
作為OPSWAT 計畫的一環，我們的研究員針對 CVE-2026-25049 進行了全面性的技術分析，深入探討其根本原因、利用機制以及對組織造成的影響。
本部落格針對此漏洞進行了詳盡的解析——從 n8n 的表達式處理架構及其分層安全控制機制，到能同時突破所有五層防禦的具體技術。
CVE-2026-25049 是 n8n 中一個嚴重的表達式沙箱逃脫漏洞，歸類於 CWE-913：對動態管理程式碼資源的控制不當。 此漏洞影響所有 1.123.17 之前的 n8n 版本，以及 2.0.0 至 2.5.1 版本，並已在 1.123.17 和 2.5.2 版本中修補。此漏洞使具備工作流程建立權限的已驗證使用者能夠編寫惡意 JavaScript 表達式，繞過平台的表達式沙箱，最終在主機伺服器上實現任意指令執行。
此漏洞的嚴重性尤為突出，因為 n8n 通常在組織的基礎架構中佔據特權地位。作為工作流程自動化樞紐，n8n 通常能直接存取內部 API、資料庫、憑證儲存庫及第三方服務。一旦 n8n 實例遭到入侵，不僅會使自動化伺服器暴露於風險之中，更會成為入侵所有連線系統的跳板，大幅擴大攻擊的影響範圍。
CVE-2026-25049 並非獨立發現的漏洞，而是對 CVE-2025-68613 修補程式的繞過手段，後者是 n8n 表達式評估器中較早出現的沙箱逃逸漏洞。 儘管在最初的漏洞被發現後已實施多層次防禦措施，但由於清理器在處理 JavaScript 抽象語法樹 (AST) 節點類型時存在根本性缺陷，導致原始類型的攻擊得以透過不同的語法途徑再次浮現。這種模式——即修補程式僅針對特定利用技術進行修補，而非解決底層的設計缺陷——凸顯了確保動態程式碼評估環境安全的持續性挑戰。
該漏洞於 2026 年 2 月 4 日與其他十份針對 n8n 的安全公告一併公開，並已由多個安全研究團隊進行了獨立分析。
關於 n8n
n8n 是一個開源的工作流程自動化平台，能協助組織串聯系統、自動化流程，並在數百種服務之間建立整合。憑藉廣泛的採用率以及超過 1,300 種現成的整合方案，n8n 已成為該領域中最受歡迎的工具之一，開發團隊與企業皆藉此自動化各項作業，從內部工具到業務關鍵的資料管線皆涵蓋其中。
該平台同時支援自建伺服器與雲端部署，並提供視覺化工作流程建構器，同時直接支援 JavaScript 以實現自訂邏輯。n8n 的架構基於節點：工作流程由相互連接的節點組成，這些節點會在觸發器、動作和函式步驟之間傳遞 JSON 格式的資料。 執行模式可切換為手動模式進行測試，或切換至生產模式進行實際部署。此架構結合對 JavaScript 運算式的原生支援，以及對內部 API 和憑證儲存庫的存取權限，使 n8n 成為強大的自動化工具——但也使其在出現漏洞時成為高價值的攻擊目標。
技術背景
抽象語法樹
抽象語法樹（AST）是解析器產生的源碼之階層化表示。與其將程式碼視為平面的字串，AST 會將其分解為結構化的節點，這些節點代表其語法元素——變數宣告、函式表達式、成員表達式、識別符以及常數。
了解 AST 節點類型對於本次分析至關重要，因為 n8n 的安全控制機制是在 AST 層級運作的。這些清理程式會檢查特定的節點類型，以偵測並阻擋危險的模式。此漏洞利用了以下事實：相同的語義操作（存取物件的屬性）會因所使用的 JavaScript 語法不同，而產生截然不同的 AST 節點類型。
舉例來說，表達式 `obj.constructor` 會產生一個`MemberExpression`節點，而 `const{ constructor } = obj` 則會產生一個 包含 `ObjectPattern`（其中含有 `Property` 節點）的`VariableDeclaration`。雖然兩者都提取了相同的屬性，但其抽象語法樹（AST）結構卻有根本性的差異——而 n8n 的驗證器僅會檢查第一種模式。
n8n 表達式評估與安全架構
n8n 的架構分為五個層級：前端、命令列介面 (CLI)、Core、工作流程和節點。工作流程層負責處理表達式的評估，而這正是與此漏洞相關的組件。
n8n 允許使用者在工作流程節點參數中嵌入 JavaScript 運算式，以動態處理資料。這些運算式會透過名為 Tournament 的函式庫在伺服器端進行評估，該函式庫會在執行前將運算式解析為抽象語法樹 (AST)。資料淨化鉤子會直接注入 Tournament 的建立流程中，在構建 AST 時執行檢查，以便在任何程式碼執行前攔截危險的模式。
由於這些表達式是在與 n8n 伺服器相同的 Node.js 程序中執行，因此該平台實作了五層獨立的安全防護機制，旨在防止未經信任的程式碼逃離沙箱。
第 1 層 - 全球上下文覆寫
在評估任何表達式之前，n8n 會透過覆寫危險的全域物件和函式，建立一個受限的執行環境。諸如 document、window、globalThis、eval、setTimeout、setInterval 以及 Function 等屬性，都會被替換為空物件，從而防止直接存取這些功能。
這種方法存在一個固有的限制：如果攻擊者能夠逃脫受限的執行環境並存取真正的全域程序物件，那麼被覆寫的屬性便不再具有意義。
第 2 層 - 正規表達式驗證
在表達式傳遞至評估器之前，n8n 會對原始表達式字串進行正規表達式檢查，以阻擋對建構子屬性的存取——這通常是獲取 Function 建構子並實現程式碼執行的常見途徑。
正規表達式/\.\s*constructor/gm可用於偵測對.constructor 的點表示法存取。然而，此檢查存在根本性的限制，因為 JavaScript 提供了多種語法路徑來存取同一個屬性，而並非所有路徑都涉及點表示法。
第 3 層 - AST 執行階段檢查器 – PrototypeSanitizer
最精密的防禦機制是在 AST 建構過程中運作的。PrototypeSanitizer 掛鉤會遍歷 AST，並檢查 MemberExpression 節點，以判定被存取的屬性是否出現在不安全物件屬性的封鎖清單中——包括 constructor、__proto__、prototype、mainModule 以及 binding。
此驗證器處理三種情況：點表示法（obj.prop），此時會檢查識別符名稱；靜態方括號表示法（obj['prop']），此時會檢查字串常數值；以及動態表達式，這些表達式會被封裝在執行時驗證函式中。如圖 10 所示，僅檢查 MemberExpression 節點——不會遍歷解構模式。
第 4 層 - AST 執行階段檢查器 函式 ThisSanitizer
作為針對 CVE-2025-68613 的直接修補程式，FunctionThisSanitizer 會攔截立即執行函式表達式 (IIFE)，並將其重寫為將 `this` 綁定至一個空物件。此舉可防止原始漏洞利用中使用的技術——該技術利用`(function(){ return this })`()透過未綁定的 `this` 參照洩漏全域程序物件。
關鍵在於，此清理程式僅處理 FunctionExpression 節點。對於任何非 FunctionExpression 的被呼叫方（包括箭頭函式），它都會明確地提前返回。
執行上下文中已移除或覆寫了 eval、Function 及 process.mainModule 等危險屬性，即使先前層級遭到繞過，也能防止直接存取程式碼執行原語。
漏洞分析
根本原因
CVE-2026-25049 的根本原因在於所有五個安全層級都存在一個共同的假設：每個層級都假設屬性存取會透過點表示法（obj.constructor）或方括號表示法（obj['constructor']）進行。然而，沒有一個層級考慮到 JavaScript 的解構語法。
JavaScript 的解構功能允許透過一種本質上截然不同的抽象語法樹（AST）結構，從物件中提取屬性：
// Traditional access - produces MemberExpression node
obj.constructor; // Blocked by regex, AST sanitizer, and runtime checks
// Destructuring - produces ObjectPattern → Property node
const { constructor } = obj; // Not checked by any layer
雖然這兩種模式都能達到相同的效果，但它們產生的 AST 表示形式卻截然不同。PrototypeSanitizer 僅檢查 MemberExpression 節點，而正規表達式則僅匹配 .constructor 模式。解構賦值會產生 VariableDeclaration → ObjectPattern → Property 節點，而這些節點均不在任何清理器的遍歷範圍內。
此外，n8n 對箭頭函式的處理方式也加劇了這個問題。FunctionThisSanitizer 僅會攔截 FunctionExpression 節點，並將其重寫為將 this 綁定至安全上下文。箭頭函式會產生 ArrowFunctionExpression AST 節點，而該清理器並不會處理這些節點。由於箭頭函式會從其外圍作用域繼承 this（詞法 this），因此它們會提供對未經清理的全域上下文的存取權限。
這兩項疏漏結合起來，便形成了一種完全的繞過機制：解構會提取 `Function` 建構子，卻不會觸發任何屬性存取檢查；而箭頭函數則提供了一種執行環境，而 `FunctionThisSanitizer` 並未攔截該環境。
開發
此漏洞利用技術結合了這兩項漏洞，同時突破所有安全層。我們的團隊追蹤到了以下攻擊路徑：
步驟 1 - 箭頭函式輸入。載荷以一個包裹在立即執行函式表達式（IIFE）中的箭頭函式開頭：
={{(() => {
// 箭頭函式 - 繞過 FunctionThisSanitizer
...
})()}}
FunctionThisSanitizer 會檢查被呼叫者是否為 FunctionExpression；由於這是 ArrowFunctionExpression，因此該檢查器會在未重寫呼叫的情況下提前返回。箭頭函數在執行時可完全存取真正的全域上下文。
步驟 2 - 解構繞過。在箭頭函數內部，解構會從箭頭函數實例中提取 Function 建構函數：
const { constructor } = () => {};
由於這是解構賦值，AST 中包含的是 ObjectPattern 節點，而非 MemberExpression。正規表達式檢查未偵測到 .constructor 模式，且 PrototypeSanitizer 從不檢查屬性名稱。攻擊者現在持有對 Function 建構函式的引用。
步驟 3 - 動態程式碼執行。取得 Function 建構子後，攻擊者便能編寫並執行任意程式碼：
return constructor(
'return process.mainModule.require("child_process").execSync("whoami").toString()',
)();
該動態建立的函式在沙箱環境之外執行，並能完全存取 Node.js 進程物件，從而可在主機上執行任意的系統指令。
概念驗證
為了展示此漏洞在實際環境中的影響，我們的研究員在受控的實驗室環境中重現了此漏洞的利用方式。攻擊情境包含：架設一個存在漏洞的 n8n 實例，並匯入一個在節點參數中包含惡意載荷的工作流程——特別針對允許表達式評估的「編輯欄位」節點。
一旦工作流程被觸發，載荷便會繞過所有五層安全過濾機制，並在主伺服器上執行反向殼層，從而使攻擊者獲得完整的命令執行權限。
Webhook 漏洞升級為未經身份驗證的遠端程式碼執行
當此漏洞與 n8n 的 webhook 功能結合時，其嚴重性將大幅提升。n8n 允許工作流程將 HTTP 端點作為 webhook 公開，並提供可配置的驗證選項，包括 bearer 憑證、基本驗證，以及——最關鍵的是——完全不進行驗證。 擁有工作流程建立權限的攻擊者，可設定一個驗證選項為「無」的公開 webhook，將 RCE 有效載荷嵌入相連的節點中，並啟動該工作流程。此時，任何來自網際網路任何位置的 HTTP 請求，只要傳送至該 webhook URL，便會觸發主伺服器上任意指令的執行。
此權限提升途徑將 CVE-2026-25049 從一個需經身份驗證的內部漏洞，轉變為一個實質上無需身份驗證、且暴露於整個網際網路的攻擊途徑。
解決之道
n8n 團隊已在 1.123.17 及 2.5.2 版本中修復 CVE-2026-25049 漏洞，具體措施包括在清理函式中實作適當的執行時類型檢查，並擴展抽象語法樹 (AST) 的覆蓋範圍以處理解構模式。運行受影響版本的組織應立即進行升級。
若無法立即進行升級，系統管理員應將工作流程的建立與編輯權限僅限於完全可信用的使用者，並在具備強化安全措施的環境中部署 n8n，該環境應限制作業系統權限及網路存取權限。
鑒於此漏洞的嚴重性及易受攻擊的特性——特別是當其與公開的 Webhook 結合使用時——組織還應審查現有工作流程中是否存在可疑表達式，監控源自 n8n 進程的異常系統指令執行，並檢視 Webhook 配置，以確認是否有未經身份驗證即暴露的端點。
透過OPSWAT進行風險緩解
透過運用OPSWAT ，企業能夠迅速識別基礎架構中存在漏洞的 n8n 元件，並在漏洞遭到利用之前採取行動。OPSWAT 作為 MetaDefender® 平台的核心技術，可提供企業環境中所有正在使用的軟體元件、函式庫及依賴項的完整清單。
如圖 15MetaDefender 掃描了包含 n8n 依賴項的 package.json 檔案，並自動將 CVE-2026-25049 標記為「嚴重」級別，同時顯示受影響的版本範圍以及建議的修復版本。這使資安團隊能夠在其部署環境中快速識別並優先處理此漏洞。
OPSWAT 已整合至MetaDefender 和MetaDefender Software Chain™ 中，讓資安團隊能夠：
- 快速定位 易受攻擊的元件——立即識別受沙箱逃脫及程式碼執行漏洞影響的開源依賴項，以便迅速進行修復或移除。
- 確保主動進行修補程式安裝與更新— 持續監控開源元件，以偵測過時或存在安全漏洞的套件，從而實現及時更新並降低風險。
- 維持合規與報告機制——隨著相關框架日益要求軟體供應鏈具備透明度，務必符合監管要求。
