n8n工作流程自動化平臺修補重大漏洞，未更新可能導致遠端執行任意程式碼攻擊
一句話版本
n8n 剛修補兩個可直接變成遠端執行任意程式碼的高風險漏洞，如果仲用受影響版本而未升級，攻擊者有機會直接攞到工作流程主機控制權。
點解重要
風險級別唔係普通漏洞：兩個漏洞嘅 CVSS 都係 9.4，代表一旦條件成立，後果唔只係資料外洩，而係有機會直接由工作流程層打穿去主機層，對自動化平臺特別危險。問題出喺常用功能位：其中一個漏洞來自 Merge 節點嘅「Combine by SQL」模式，呢類資料整合功能好多流程都會用到，所以唔係只影響冷門插件，而係可能踩中日常設計模式。沙箱唔等於安全：AlaSQL 沙箱處理 SQL 指令有缺陷，說明就算系統表面上有隔離機制，實作一錯仍然可以被借位執行任意程式碼，對我哋評估「可執行輸入」功能時係一個直接警號。原型污染可以一路升級成主機接管：GSuiteAdmin 節點嘅 Prototype Pollution 唔只係程式邏輯錯亂，新聞明講可被用嚟觸發 RCE 同控制主機，提醒我哋唔可以低估 JavaScript 類型弱點嘅實際破壞力。受影響版本跨度大：唔係得單一新版中招，2.14.x、2.13.x 同 1.123.x 都受影響，代表如果團隊有多套環境、分批升級、或者長尾舊部署，好容易有人以為自己唔喺風險範圍，其實未必。修補路徑算清楚：官方已經指出安全版本係 2.14.1、2.13.3、1.123.27 之後，對我哋嚟講重點唔係研究 workaround，而係盡快對版本、排升級、驗證流程有冇受影響。自動化平臺一出事會連帶放大：n8n 通常會接住帳號憑證、SaaS API、內部流程同資料流，主機一被拿下，攻擊者通常唔只得到一台機，而係得到一條已經接好權限嘅自動化管道。
我哋點睇
- 如果團隊內部有用 n8n，應該即刻做版本盤點，先確認有冇落喺
2.14.x、2.13.x、1.123.x，唔好等到例行維護先處理。 - 升級時唔好只睇服務有冇起得返，應額外檢查有冇流程用到 Merge 節點嘅 SQL 合併模式，以及涉及 GSuiteAdmin 節點嘅工作流，因為呢兩個位最直接對應今次漏洞。
- 對我哋自己做控制平臺同工作流系統都有啟示：任何可執行查詢、腳本、模板、表達式嘅能力，都要當成高風險邊界設計，唔可以因為包咗沙箱就當安全。