半夜被監(jiān)控告警拉起來(lái)說(shuō)是生產(chǎn)環(huán)境的 n8n 實(shí)例正在被人瘋狂拉取執(zhí)行歷史。第一反應(yīng)是有人在調(diào)試再看告警頻率明顯是掃描器在批量探測(cè)。順著源 IP 和請(qǐng)求路徑追下去確認(rèn)是對(duì) CVE-2025-68668 的自動(dòng)化利用。這個(gè)漏洞今天在自動(dòng)化運(yùn)維圈子里討論度很高因?yàn)?n8n 在自托管工作流自動(dòng)化里屬于“基礎(chǔ)設(shè)施級(jí)”的軟件一條業(yè)務(wù)流水線(xiàn)往往依賴(lài)幾十上百條工作流協(xié)作。一個(gè)能繞過(guò)鑒權(quán)拿到工作流數(shù)據(jù)和憑據(jù)密文的漏洞足以讓運(yùn)行在上面的自動(dòng)化流程數(shù)據(jù)裸奔。這篇手冊(cè)是我在這次應(yīng)急響應(yīng)中實(shí)際執(zhí)行過(guò)的處置步驟按 0-24 小時(shí)的時(shí)間線(xiàn)整理順便把排查中踩過(guò)的坑一并記下來(lái)。希望能幫到正在頭疼的同行。1. 漏洞全景先搞明白你面對(duì)的是什么1.1 漏洞基本信息速覽先給張速查表方便你直接對(duì)照自己的環(huán)境。項(xiàng)目?jī)?nèi)容CVE 編號(hào)CVE-2025-68668漏洞類(lèi)型訪(fǎng)問(wèn)控制不當(dāng) 敏感數(shù)據(jù)暴露受影響組件n8n Community Edition 自托管實(shí)例影響版本1.76.2 及之前版本修復(fù)版本1.77.0攻擊復(fù)雜度低是否需要認(rèn)證無(wú)需登錄即可利用臨時(shí)評(píng)分CVSS 9.1以官方最終評(píng)估為準(zhǔn)這里要特別說(shuō)清楚這個(gè)漏洞的核心問(wèn)題出在請(qǐng)求路徑的處理邏輯上。n8n 在反向代理后面運(yùn)行時(shí)依賴(lài)中間件對(duì)內(nèi)部 REST API 做會(huì)話(huà)校驗(yàn)但舊版本中對(duì)特定格式的請(qǐng)求處理不一致攻擊者可以通過(guò)構(gòu)造特殊 URL 或請(qǐng)求頭讓后端認(rèn)為請(qǐng)求已經(jīng)過(guò)了網(wǎng)關(guān)鑒權(quán)從而跳過(guò)登錄校驗(yàn)。繞過(guò)之后訪(fǎng)問(wèn)/rest/workflows、/rest/executions、/rest/credentials這些接口就跟管理員一樣暢通無(wú)阻。我在復(fù)現(xiàn)時(shí)確認(rèn)未授權(quán)狀態(tài)下可以直接讀取工作流列表和執(zhí)行歷史記錄部分部署還能拿到連接器憑據(jù)的密文。這是典型的“訪(fǎng)問(wèn)控制失效”加“敏感信息泄露”組合拳危害非常大。1.2 攻擊鏈條解析公開(kāi)入口怎么變成數(shù)據(jù)泄露攻擊者要利用這個(gè)漏洞并不需要什么復(fù)雜工具普通掃描器加幾段腳本就能完成。完整的攻擊鏈條大概是這樣的通過(guò)端口掃描工具在公網(wǎng)找 n8n 實(shí)例默認(rèn) 5678 端口是最顯眼的指紋有些自動(dòng)化掃描器還會(huì)識(shí)別登錄頁(yè)特征。命中目標(biāo)后直接構(gòu)造繞過(guò)鑒權(quán)的請(qǐng)求訪(fǎng)問(wèn)/rest/workflows拿到全部工作流定義和節(jié)點(diǎn)配置清單。繼續(xù)調(diào)用/rest/executions分頁(yè)拉取執(zhí)行歷史。執(zhí)行歷史里保存著每次工作流運(yùn)行的輸入輸出數(shù)據(jù)快照數(shù)據(jù)庫(kù)接口返回的記錄、CRM 同步的客戶(hù)資料、訂單處理結(jié)果全在里面躺著。訪(fǎng)問(wèn)/rest/settings、/rest/node-types等輔助端點(diǎn)收集更細(xì)的運(yùn)行時(shí)配置、插件信息、特性開(kāi)關(guān)狀態(tài)。如果部署者連加密密鑰都沒(méi)有固定攻擊者還可能從配置信息里拼出憑據(jù)解密的必要條件進(jìn)一步還原第三方連接器的明文密鑰。打個(gè)生活化的比方這就像辦公樓門(mén)禁系統(tǒng)有個(gè)后門(mén)任何人都能刷進(jìn)機(jī)房不光能看到流水線(xiàn)上正在加工的零件數(shù)據(jù)還能拿到鑰匙柜里的備用鑰匙。區(qū)別在于辦公樓的鑰匙最多開(kāi)幾個(gè)門(mén)n8n 里的憑據(jù)鑰匙打開(kāi)的是數(shù)據(jù)庫(kù)、CRM、支付服務(wù)和云存儲(chǔ)的權(quán)限。1.3 影響范圍評(píng)估“千萬(wàn)級(jí)”不是標(biāo)題黨看到“波及千萬(wàn)自動(dòng)化流程”這個(gè)說(shuō)法可能有人覺(jué)得夸張。但只要你算一筆賬就會(huì)明白為什么這次漏洞會(huì)引起這么大關(guān)注。n8n 自托管版在自動(dòng)化領(lǐng)域的使用量非常大Docker 拉取量、GitHub 的 star 數(shù)量、社區(qū)模板數(shù)量都是千萬(wàn)到億級(jí)規(guī)模。很多企業(yè)把 n8n 當(dāng)作內(nèi)部的“自動(dòng)化編排中樞”一個(gè)實(shí)例上掛幾十上百條工作流是常態(tài)每條工作流里再串著數(shù)據(jù)庫(kù)、郵件、云盤(pán)、消息通知等各種連接器。按“實(shí)例數(shù) × 每實(shí)例工作流數(shù)”去估算受影響的自動(dòng)化流程數(shù)量級(jí)確實(shí)能達(dá)到千萬(wàn)級(jí)別。更讓人頭疼的是“影響質(zhì)量”工作流里流轉(zhuǎn)的往往是客戶(hù)信息、訂單數(shù)據(jù)、財(cái)務(wù)數(shù)字這類(lèi)核心業(yè)務(wù)資料一旦泄露后續(xù)的合規(guī)報(bào)告、客戶(hù)通知、公關(guān)應(yīng)對(duì)全是額外成本。這也是為什么我把這篇文章定位成“24 小時(shí)應(yīng)急手冊(cè)”因?yàn)樘幚泶翱谡娴暮芏獭?. 24小時(shí)應(yīng)急時(shí)間線(xiàn)拆成四個(gè)處置窗口2.1 0-2小時(shí)資產(chǎn)盤(pán)點(diǎn)與風(fēng)險(xiǎn)分級(jí)接到通報(bào)或者看到漏洞信息之后第一件事不是急著升級(jí)而是先回答三個(gè)問(wèn)題我們到底有多少個(gè) n8n 實(shí)例哪些暴露在公網(wǎng)上面跑了什么業(yè)務(wù)這三個(gè)問(wèn)題不搞清楚后面的修復(fù)根本沒(méi)有優(yōu)先級(jí)。資產(chǎn)盤(pán)點(diǎn)可以直接用命令掃先按容器和進(jìn)程把已知實(shí)例撈出來(lái)# 找 Docker 里的 n8n 容器 docker ps --filter namen8n --format table {{.Names}}\t{{.Image}}\t{{.Ports}} # 看容器內(nèi)版本 docker exec 容器名 n8n --version # 如果是 npm 或二進(jìn)制方式部署直接執(zhí)行 n8n --version內(nèi)網(wǎng)里還可能存在一些“野實(shí)例”是某個(gè)團(tuán)隊(duì)自己搭的不一定登記在 CMDB 里。這種情況最危險(xiǎn)只能靠端口掃描兜底。比如在 Linux 內(nèi)網(wǎng)環(huán)境做一次快速的 5678 端口探測(cè)for ip in $(seq 1 254); do timeout 1 bash -c echo /dev/tcp/192.168.1.$ip/5678 2/dev/null echo 192.168.1.$ip:5678 open done掃描結(jié)果出來(lái)后立刻做風(fēng)險(xiǎn)分級(jí)。我用的分級(jí)標(biāo)準(zhǔn)很簡(jiǎn)單A 級(jí)公網(wǎng)可直接訪(fǎng)問(wèn)且用戶(hù)管理未開(kāi)啟或沒(méi)有多因素認(rèn)證。這是最高優(yōu)先級(jí)直接進(jìn)入止血流程。B 級(jí)公網(wǎng)不可訪(fǎng)問(wèn)但內(nèi)網(wǎng)多個(gè)網(wǎng)段都能訪(fǎng)問(wèn)上面跑著敏感業(yè)務(wù)。C 級(jí)完全在內(nèi)網(wǎng)且訪(fǎng)問(wèn)受限工作流不涉及敏感數(shù)據(jù)。這里要說(shuō)一句不好聽(tīng)的很多團(tuán)隊(duì)在事件發(fā)生前根本不關(guān)心資產(chǎn)臺(tái)賬等到被攻擊了才發(fā)現(xiàn)“原來(lái)我們還有這么多個(gè) n8n”。所以 0-2 小時(shí)窗口里資產(chǎn)盤(pán)點(diǎn)務(wù)必做徹底寧可多掃幾個(gè)網(wǎng)段也不要漏掉任何一個(gè)潛在入口。2.2 2-6小時(shí)止血措施三件套止血階段的思路不是“徹底修復(fù)”而是“先把傷口按住”。針對(duì)這個(gè)漏洞我建議按順序做三件事。第一件把管理入口從公網(wǎng)撤下來(lái)。n8n 默認(rèn) 5678 端口同時(shí)提供 UI 和 API如果之前直接映射到了公網(wǎng)馬上在防火墻或安全組層面限制來(lái)源 IP。只允許辦公網(wǎng)段或堡壘機(jī)地址訪(fǎng)問(wèn)其他來(lái)源全部拒絕。# 以 Ubuntu UFW 為例放行內(nèi)網(wǎng)管理網(wǎng)段拒絕其他來(lái)源 ufw allow from 10.0.0.0/8 to any port 5678 proto tcp ufw deny 5678/tcp第二件臨時(shí)收緊配置。在 n8n 的.env文件里加上以下設(shè)置并重啟服務(wù)生效N8N_PUBLIC_API_DISABLEDtrue N8N_PERSONALIZATION_ENABLEDfalse N8N_SECURE_COOKIEtrue需要留意的是N8N_PUBLIC_API_DISABLED主要作用于公共 API 模塊對(duì)內(nèi)部 REST API 的覆蓋并不完整。這個(gè)配置的意義在于減少攻擊面能關(guān)的入口先關(guān)掉但你不能關(guān)完就覺(jué)得萬(wàn)事大吉升級(jí)才是最終出路。第三件在反向代理層做最后一道攔截。如果你的 n8n 前面有 Nginx可以臨時(shí)加一段規(guī)則對(duì)/rest/、/api/、/static/這些管理路徑做來(lái)源限制。比如location /rest/ { allow 10.0.0.0/8; deny all; proxy_pass http://n8n:5678; }這里有個(gè)前提你要想清楚如果 n8n 的主要業(yè)務(wù)流程依賴(lài)對(duì)外 webhook比如接收支付平臺(tái)回調(diào)或 GitHub 事件推送那么 webhook 入口不能一刀切封掉否則業(yè)務(wù)就斷了。正確姿勢(shì)是單獨(dú)把 webhook 路徑保留在公網(wǎng)管理后臺(tái)和 REST 接口全部收緊。這個(gè)拆分原則后面第 3.3 節(jié)還會(huì)細(xì)講。注意止血措施只是臨時(shí)方案。防火墻規(guī)則和 Nginx 配置改動(dòng)都要記錄時(shí)間和操作人避免升級(jí)完成后忘了解除造成后續(xù)業(yè)務(wù)莫名不可用。2.3 6-12小時(shí)升級(jí)與補(bǔ)丁落地止血完成馬上進(jìn)入正式修復(fù)階段。n8n 官方已經(jīng)在 1.77.0 里修復(fù)了 CVE-2025-68668所以核心動(dòng)作就是把實(shí)例升到這個(gè)版本或更高。先說(shuō)升級(jí)前必須做的備份。這一步不能省尤其要備份數(shù)據(jù)庫(kù)和.env文件。以 Docker Compose 部署為例cd /opt/n8n tar czf backup-$(date %Y%m%d-%H%M%S).tar.gz ./data ./docker-compose.yml ./.env備份完成后開(kāi)始升級(jí)# 拉取修復(fù)版本鏡像 docker compose pull n8n # 重新創(chuàng)建容器 docker compose up -d # 清理舊鏡像 docker image prune -f如果你是 npm 全局安裝的方式操作更簡(jiǎn)單npm update n8n -g sudo systemctl restart n8n升級(jí)后驗(yàn)證四件事啟動(dòng)日志里有沒(méi)有報(bào)錯(cuò)工作流列表能否正常加載連接器憑據(jù)是否能正常讀取對(duì)外 webhook 能否正常觸發(fā)。這四項(xiàng)都過(guò)了才叫真正修完。這里特別強(qiáng)調(diào)一個(gè)很多人忽略的點(diǎn).env里必須要有固定的N8N_ENCRYPTION_KEY。 n8n 有一個(gè)很坑的默認(rèn)行為如果環(huán)境變量里沒(méi)設(shè)置這個(gè)密鑰它會(huì)在首次啟動(dòng)時(shí)生成一個(gè)隨機(jī)值并存在數(shù)據(jù)庫(kù)里。一旦升級(jí)容器、遷移實(shí)例或者數(shù)據(jù)庫(kù)需要重建數(shù)據(jù)庫(kù)里的加密信息和當(dāng)前環(huán)境對(duì)不上所有連接器憑據(jù)都會(huì)變成“失憶”狀態(tài)全部無(wú)法解密。所以升級(jí)前一定要確認(rèn)這個(gè)變量已經(jīng)顯式配置沒(méi)配置的話(huà)先補(bǔ)上再重啟否則后果很酸爽。2.4 12-24小時(shí)日志審計(jì)與憑據(jù)輪換升級(jí)完成后最不能省的一步是日志審計(jì)。因?yàn)楣粽咭坏┮呀?jīng)進(jìn)過(guò)系統(tǒng)你不僅要修洞還要搞清楚“丟了什么、被動(dòng)了什么”。日志審計(jì)主要看三個(gè)維度。第一個(gè)維度是異常路徑。在訪(fǎng)問(wèn)日志里重點(diǎn)搜索這些特征/rest/workflows、/rest/executions、/rest/credentials這類(lèi)內(nèi)部接口。URL 里帶分號(hào)、路徑參數(shù)、..等特殊字符的請(qǐng)求這是路徑繞過(guò)利用的常見(jiàn)痕跡。X-Forwarded-Host、X-Original-URL等頭部異常的請(qǐng)求。第二個(gè)維度是時(shí)間分布。漏洞公開(kāi)后幾小時(shí)內(nèi)就會(huì)開(kāi)始大規(guī)模掃描所以重點(diǎn)排查漏洞公告發(fā)布前后這幾天的訪(fǎng)問(wèn)記錄。Docker 部署可以用--since參數(shù)快速導(dǎo)出日志docker logs n8n --since 168h | grep -E /rest/(workflows|executions|credentials) | head -n 100第三個(gè)維度是行為特征。正常用戶(hù)訪(fǎng)問(wèn)/rest/executions是低頻的如果某個(gè)源 IP 在幾分鐘內(nèi)連續(xù)翻頁(yè)拉取大量執(zhí)行記錄基本可以斷定是在脫庫(kù)。按源 IP 統(tǒng)計(jì)訪(fǎng)問(wèn)量是識(shí)別這種行為最快的方式docker logs n8n --since 168h | awk {print $1} | sort | uniq -c | sort -rn | head -n 20日志審計(jì)之后憑據(jù)輪換是更麻煩但必須做的事。這個(gè)漏洞可以讓未授權(quán)攻擊者拿到憑據(jù)密文如果加密密鑰也暴露攻擊者就能還原出明文。所以只要你的 n8n 曾經(jīng)暴露在公網(wǎng)不管有沒(méi)有確認(rèn)攻擊者得手所有第三方服務(wù)的密鑰都應(yīng)該輪換。輪換清單至少包括數(shù)據(jù)庫(kù)賬號(hào)密碼既包括 n8n 自己連接庫(kù)的連接串也包括工作流里連接的業(yè)務(wù)數(shù)據(jù)庫(kù)。CRM、ERP、支付、云存儲(chǔ)等連接器的 API Key。SMTP/IMAP 郵箱密碼或應(yīng)用專(zhuān)用密碼。OAuth Token在 n8n 里對(duì)每個(gè)連接器重新授權(quán)。如果 n8n 服務(wù)賬號(hào)在云平臺(tái)有權(quán)限還要輪換對(duì)應(yīng)的 AccessKey。輪換順序也有講究先在第三方平臺(tái)吊銷(xiāo)舊 Key再回到 n8n 里編輯對(duì)應(yīng)的 Credential 填新值最后觸發(fā)一條相關(guān)工作流驗(yàn)證連通性。輪換完順便清理掉不再使用的連接器很多團(tuán)隊(duì)里躺著幾年不動(dòng)的“僵尸憑據(jù)”就是下次應(yīng)急時(shí)最麻煩的雷。3. 應(yīng)急響應(yīng)中的高頻翻車(chē)點(diǎn)與避坑經(jīng)驗(yàn)3.1 升級(jí)后憑據(jù)解密失敗這個(gè)坑我先踩了這次應(yīng)急里我們團(tuán)隊(duì)在升級(jí)到 1.77.0 后踩了一個(gè)大坑所有執(zhí)行記錄里的連接器都提示“Could not decrypt credential”。排查原因才發(fā)現(xiàn)這套 n8n 是早期同事用官方 Docker 默認(rèn)配置部署的環(huán)境變量里從沒(méi)設(shè)置過(guò)N8N_ENCRYPTION_KEY。之前每次重啟都正常是因?yàn)榧用苊荑€存在數(shù)據(jù)庫(kù)里而我們這次升級(jí)時(shí)誤用了清理 volume 的方式導(dǎo)致數(shù)據(jù)庫(kù)文件和密鑰序列對(duì)不上。解決辦法分情況討論如果有完整備份先把舊數(shù)據(jù)庫(kù)恢復(fù)回來(lái)在.env里補(bǔ)充原來(lái)的加密密鑰再重新升級(jí)。如果沒(méi)有備份只能逐個(gè)連接器重新授權(quán)。這個(gè)路徑最痛苦但最干凈相當(dāng)于是把 Credential 全部重建一遍。還有個(gè)辦法是找一臺(tái)還在舊版本的實(shí)例從它的數(shù)據(jù)庫(kù)里讀取加密密鑰移植到新環(huán)境。但應(yīng)急場(chǎng)景下我不推薦因?yàn)槿绻f實(shí)例也有可能被攻擊過(guò)那把舊密鑰搬過(guò)來(lái)就是引狼入室不如老老實(shí)實(shí)輪換。這次經(jīng)歷讓我總結(jié)出一條鐵律從第一天部署 n8n 開(kāi)始就必須在.env里顯式設(shè)置一個(gè)強(qiáng)隨機(jī)的N8N_ENCRYPTION_KEY并且把密鑰保存到公司密碼管理平臺(tái)。這是 n8n 運(yùn)維的第一紀(jì)律誰(shuí)不遵守誰(shuí)在升級(jí)時(shí)吃苦頭。3.2 日志回溯技巧別等日志滾動(dòng)覆蓋才想起查很多團(tuán)隊(duì)在應(yīng)急時(shí)遇到的問(wèn)題不是沒(méi)有日志而是日志已經(jīng)被滾動(dòng)覆蓋了。Docker 默認(rèn)的 json-file 日志驅(qū)動(dòng)會(huì)按大小輪轉(zhuǎn)默認(rèn)配置下可能只保留幾天的歷史。等你想查的時(shí)候關(guān)鍵時(shí)段的日志已經(jīng)沒(méi)了。有兩種處理辦法。一種是救援式的先把現(xiàn)有日志導(dǎo)出再說(shuō)docker logs n8n --since 7d --timestamps n8n-export.log另一種是根治式的給 Docker 配置日志輪轉(zhuǎn)策略讓日志保留更長(zhǎng)時(shí)間services: n8n: logging: driver: json-file options: max-size: 50m max-file: 10但我建議更靠譜的方案是把 n8n 日志同步到中央日志平臺(tái)比如自建 Loki、ELK或者云平臺(tái)自帶的日志服務(wù)。這樣就算容器被銷(xiāo)毀重建日志記錄也不會(huì)丟。另外一個(gè)小技巧如果需要反復(fù)檢索日志先導(dǎo)出到文件再處理不要在容器運(yùn)行狀態(tài)下反復(fù)使用docker logs加管道 grep那樣會(huì)占用容器資源并可能撐大磁盤(pán) IO。應(yīng)急時(shí)先把日志文件拉下來(lái)再用文本工具慢慢分析。3.3 webhook 入口和 UI 入口必須分開(kāi)對(duì)待很多 n8n 部署圖很隨意把 5678 端口直接映射到公網(wǎng)然后用 Nginx 反代加個(gè) SSL 就以為安全了。問(wèn)題是n8n 的對(duì)外 webhook 和管理后臺(tái)共用同一個(gè)服務(wù)端口。如果你把公網(wǎng)流量全部放行進(jìn)去等于把管理后臺(tái)也暴露了。正確做法是拆成兩個(gè)入口對(duì)外入口只放行 webhook 路徑比如https://hooks.example.com/webhook/反向代理到 n8n 容器時(shí)禁止轉(zhuǎn)發(fā)/rest/、/api/、/static/等管理路徑。管理入口走堡壘機(jī)或?qū)＞€(xiàn)訪(fǎng)問(wèn)只監(jiān)聽(tīng)內(nèi)網(wǎng) IP不向公網(wǎng)開(kāi)放。Nginx 配置示例# 對(duì)外 webhook 入口 server { listen 443 ssl; server_name hooks.example.com; location /webhook/ { proxy_pass http://n8n:5678; proxy_set_header Host $host; } location / { deny all; return 403; } } # 管理入口限制來(lái)源 IP server { listen 443 ssl; server_name n8n-admin.example.com; allow 10.0.0.0/8; deny all; location / { proxy_pass http://n8n:5678; } }這套架構(gòu)能把這個(gè)漏洞的暴露面縮到最小。即便以后 n8n 再爆出類(lèi)似的訪(fǎng)問(wèn)控制漏洞公網(wǎng)攻擊者能打到的也只剩 webhook 端點(diǎn)拿不到工作流配置和執(zhí)行歷史數(shù)據(jù)后續(xù)危害會(huì)小很多。3.4 數(shù)據(jù)備份與回滾策略應(yīng)急升級(jí)最怕升級(jí)失敗后回不去。備份不能只備數(shù)據(jù)庫(kù)docker-compose.yml、.env、以及導(dǎo)出的工作流定義都要收好。n8n 的工作流數(shù)據(jù)存在數(shù)據(jù)庫(kù)里SQLite 是單文件用sqlite3在線(xiàn)備份比較穩(wěn)PostgreSQL 用pg_dump更可靠。PostgreSQL 備份命令示例docker exec postgres容器名 pg_dump -U n8n n8n_db n8n_db.sqlSQLite 備份命令示例sqlite3 /data/.n8n/database.sqlite .backup /backup/database.sqlite.bak如果升級(jí)后發(fā)現(xiàn)問(wèn)題需要回滾操作不復(fù)雜docker compose stop n8n # 修改 docker-compose.yml 中的鏡像版本號(hào)回舊版本 docker compose up -d但這里有個(gè)隱藏風(fēng)險(xiǎn)版本回退后如果數(shù)據(jù)庫(kù) schema 已經(jīng)被新版升級(jí)舊版可能無(wú)法兼容。所以更穩(wěn)妥的做法是先恢復(fù)到備份的數(shù)據(jù)庫(kù)再啟動(dòng)舊鏡像。這個(gè)回滾過(guò)程要在變更窗口內(nèi)完成不能邊跑業(yè)務(wù)邊折騰。4. 把被動(dòng)應(yīng)急變成日常安全基線(xiàn)4.1 n8n 實(shí)例安全配置對(duì)照表這次應(yīng)急之后我把 n8n 的常用安全配置整理成一張檢查表。以后部署新實(shí)例時(shí)直接對(duì)照著逐項(xiàng)落實(shí)。配置項(xiàng)推薦值說(shuō)明N8N_ENCRYPTION_KEY強(qiáng)隨機(jī)值保存到密碼管理平臺(tái)不設(shè)置就是默認(rèn)隨機(jī)升級(jí)遷移時(shí)會(huì)大坑N8N_SECURE_COOKIEtrue強(qiáng)制 Cookie 走 HTTPSN8N_ENABLE_AUDIT_LOGStrue開(kāi)啟審計(jì)日志N8N_USER_MANAGEMENT_DISABLEDfalse必須開(kāi)啟用戶(hù)管理N8N_PUBLIC_API_DISABLEDtrue不需要公共 API 時(shí)關(guān)閉N8N_BLOCK_ENV_ACCESS_IN_NODEtrue防止工作流節(jié)點(diǎn)讀取宿主機(jī)環(huán)境變量N8N_PERSONALIZATION_ENABLEDfalse減少遙測(cè)和額外攻擊面N8N_METRICStrue開(kāi)啟監(jiān)控指標(biāo)這里面有一條要提醒N8N_BLOCK_ENV_ACCESS_IN_NODE設(shè)置后部分代碼節(jié)點(diǎn)里讀取環(huán)境變量的邏輯可能會(huì)受影響。上線(xiàn)前要回歸測(cè)試幾條核心工作流確認(rèn)沒(méi)有兼容性問(wèn)題再全量推廣。4.2 網(wǎng)絡(luò)層防護(hù)與訪(fǎng)問(wèn)控制自托管工具的防護(hù)思路要轉(zhuǎn)變不要把它當(dāng)成公網(wǎng)應(yīng)用來(lái)設(shè)計(jì)而是當(dāng)成內(nèi)網(wǎng)應(yīng)用。把這個(gè)觀(guān)念轉(zhuǎn)變過(guò)來(lái)很多漏洞的威脅都降一大半。建議的做法n8n 管理端口只監(jiān)聽(tīng)內(nèi)網(wǎng) IP不在公網(wǎng)暴露。webhook 入口單獨(dú)用反代暴露不直接把 5678 端口映射到公網(wǎng)。控制工作流的出網(wǎng)請(qǐng)求。很多 n8n 工作流里有 HTTP Request 節(jié)點(diǎn)如果被攻擊者篡改這些節(jié)點(diǎn)可能變成 SSRF 跳板。能在宿主機(jī)防火墻限制容器出網(wǎng)目標(biāo)最好做不了的話(huà)至少對(duì)必須訪(fǎng)問(wèn)的外部接口建白名單。對(duì) webhook 消息做簽名校驗(yàn)。GitHub、支付平臺(tái)、企業(yè)微信這些回調(diào)都支持簽名或密鑰驗(yàn)證工作流第一個(gè)節(jié)點(diǎn)一定要校驗(yàn)簽名開(kāi)發(fā)階段圖省事跳過(guò)的生產(chǎn)環(huán)境遲早要還債。4.3 監(jiān)控告警與定期演練只修好這一個(gè) CVE 不夠要把升級(jí)、監(jiān)控、審計(jì)固化成流程否則下一次漏洞出現(xiàn)還是手忙腳亂。我建議至少建立四類(lèi)監(jiān)控異常訪(fǎng)問(wèn)檢測(cè)/rest/路徑出現(xiàn)非辦公網(wǎng)段來(lái)源時(shí)觸發(fā)告警。憑據(jù)變化告警Credential 被修改、刪除或新增連接器時(shí)通知管理員。工作流變更告警工作流被導(dǎo)出、導(dǎo)入、編輯尤其是新增 webhook 觸發(fā)的工作流。版本跟蹤每周檢查一次 n8n release notes 和公開(kāi)漏洞庫(kù)訂閱官方安全公告。告警要接入企業(yè) IM 和工單系統(tǒng)明確負(fù)責(zé)人和響應(yīng)時(shí)限。同時(shí)建議每季度做一次小規(guī)模演習(xí)故意把一臺(tái)測(cè)試 n8n 暴露到公網(wǎng)讓安全團(tuán)隊(duì)在規(guī)定時(shí)間內(nèi)發(fā)現(xiàn)并處置。沒(méi)有演練過(guò)的應(yīng)急手冊(cè)到了真出事時(shí)大概率用不上。4.4 團(tuán)隊(duì)協(xié)作與應(yīng)急手冊(cè)維護(hù)應(yīng)急響應(yīng)不是一個(gè)人的戰(zhàn)斗而是團(tuán)隊(duì)協(xié)作。我建議把本文里的時(shí)間線(xiàn)、命令、配置項(xiàng)整理成團(tuán)隊(duì)內(nèi)部應(yīng)急手冊(cè)在手冊(cè)里注明誰(shuí)是 n8n 負(fù)責(zé)人誰(shuí)是備份責(zé)任人。備份文件放在哪里如何恢復(fù)。管理員賬號(hào)如何接管。需要聯(lián)系哪些外部服務(wù)商聯(lián)系方式是什么。n8n 的版本迭代比較快安全配置也會(huì)跟著變化。每次大版本升級(jí)后建議把默認(rèn)配置重新核對(duì)一遍更新手冊(cè)里的對(duì)照表。團(tuán)隊(duì)里可以指定一位 n8n 負(fù)責(zé)人專(zhuān)門(mén)跟蹤版本更新和安全公告這個(gè)人不需要每天盯著但至少每周掃一眼 release notes遇到安全相關(guān)版本第一時(shí)間通報(bào)。我在處置 CVE-2025-68668 的過(guò)程中最大的體會(huì)是漏洞本身不可怕可怕的是你根本不知道自己有哪些 n8n 實(shí)例、上面跑了哪些數(shù)據(jù)、密鑰存在哪里。等攻擊者幫你找到答案的時(shí)候代價(jià)早就翻倍了。最后再分享一個(gè)小技巧n8n 社區(qū)版和企業(yè)版在審計(jì)、單點(diǎn)登錄、權(quán)限管理這些能力上有差異。如果你所在團(tuán)隊(duì)對(duì)安全要求很高建議評(píng)估一下官方企業(yè)版的功能很多手工加固都可以在產(chǎn)品層面解決。即便不采購(gòu)也可以按這個(gè)思路對(duì)比社區(qū)版的差距優(yōu)先補(bǔ)齊最薄弱的環(huán)節(jié)。這次的 24 小時(shí)應(yīng)急經(jīng)歷就當(dāng)是給團(tuán)隊(duì)做了一次免費(fèi)的安全壓力測(cè)試。