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