n8n CVE-2025-68668漏洞应急响应：24小时处置手册与安全加固指南

半夜被监控告警拉起来，说是生产环境的 n8n 实例正在被人疯狂拉取执行历史。第一反应是有人在调试，再看告警频率，明显是扫描器在批量探测。顺着源 IP 和请求路径追下去，确认是对 CVE-2025-68668 的自动化利用。这个漏洞今天在自动化运维圈子里讨论度很高，因为 n8n 在自托管工作流自动化里属于“基础设施级”的软件，一条业务流水线往往依赖几十上百条工作流协作。一个能绕过鉴权拿到工作流数据和凭据密文的漏洞，足以让运行在上面的自动化流程数据裸奔。这篇手册是我在这次应急响应中实际执行过的处置步骤，按 0-24 小时的时间线整理，顺便把排查中踩过的坑一并记下来。希望能帮到正在头疼的同行。

1. 漏洞全景：先搞明白你面对的是什么

1.1 漏洞基本信息速览

先给张速查表，方便你直接对照自己的环境。

这里要特别说清楚，这个漏洞的核心问题出在请求路径的处理逻辑上。n8n 在反向代理后面运行时，依赖中间件对内部 REST API 做会话校验，但旧版本中对特定格式的请求处理不一致，攻击者可以通过构造特殊 URL 或请求头，让后端认为请求已经过了网关鉴权，从而跳过登录校验。绕过之后，访问/rest/workflows、/rest/executions、/rest/credentials这些接口就跟管理员一样畅通无阻。

我在复现时确认，未授权状态下可以直接读取工作流列表和执行历史记录，部分部署还能拿到连接器凭据的密文。这是典型的“访问控制失效”加“敏感信息泄露”组合拳，危害非常大。

1.2 攻击链条解析：公开入口怎么变成数据泄露

攻击者要利用这个漏洞，并不需要什么复杂工具，普通扫描器加几段脚本就能完成。完整的攻击链条大概是这样的：

1. 通过端口扫描工具在公网找 n8n 实例，默认 5678 端口是最显眼的指纹，有些自动化扫描器还会识别登录页特征。
2. 命中目标后，直接构造绕过鉴权的请求访问/rest/workflows，拿到全部工作流定义和节点配置清单。
3. 继续调用/rest/executions，分页拉取执行历史。执行历史里保存着每次工作流运行的输入输出数据快照，数据库接口返回的记录、CRM 同步的客户资料、订单处理结果，全在里面躺着。
4. 访问/rest/settings、/rest/node-types等辅助端点，收集更细的运行时配置、插件信息、特性开关状态。
5. 如果部署者连加密密钥都没有固定，攻击者还可能从配置信息里拼出凭据解密的必要条件，进一步还原第三方连接器的明文密钥。

打个生活化的比方：这就像办公楼门禁系统有个后门，任何人都能刷进机房，不光能看到流水线上正在加工的零件数据，还能拿到钥匙柜里的备用钥匙。区别在于，办公楼的钥匙最多开几个门，n8n 里的凭据钥匙打开的是数据库、CRM、支付服务和云存储的权限。

1.3 影响范围评估：“千万级”不是标题党

看到“波及千万自动化流程”这个说法，可能有人觉得夸张。但只要你算一笔账，就会明白为什么这次漏洞会引起这么大关注。n8n 自托管版在自动化领域的使用量非常大，Docker 拉取量、GitHub 的 star 数量、社区模板数量都是千万到亿级规模。很多企业把 n8n 当作内部的“自动化编排中枢”，一个实例上挂几十上百条工作流是常态，每条工作流里再串着数据库、邮件、云盘、消息通知等各种连接器。

按“实例数 × 每实例工作流数”去估算，受影响的自动化流程数量级确实能达到千万级别。更让人头疼的是“影响质量”：工作流里流转的往往是客户信息、订单数据、财务数字这类核心业务资料，一旦泄露，后续的合规报告、客户通知、公关应对全是额外成本。这也是为什么我把这篇文章定位成“24 小时应急手册”，因为处理窗口真的很短。

2. 24小时应急时间线：拆成四个处置窗口

2.1 0-2小时：资产盘点与风险分级

接到通报或者看到漏洞信息之后，第一件事不是急着升级，而是先回答三个问题：我们到底有多少个 n8n 实例？哪些暴露在公网？上面跑了什么业务？这三个问题不搞清楚，后面的修复根本没有优先级。

资产盘点可以直接用命令扫，先按容器和进程把已知实例捞出来：

# 找 Docker 里的 n8n 容器 docker ps --filter "name=n8n" --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}" # 看容器内版本 docker exec <容器名> n8n --version # 如果是 npm 或二进制方式部署，直接执行 n8n --version

内网里还可能存在一些“野实例”，是某个团队自己搭的，不一定登记在 CMDB 里。这种情况最危险，只能靠端口扫描兜底。比如在 Linux 内网环境做一次快速的 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

扫描结果出来后，立刻做风险分级。我用的分级标准很简单：

• A 级：公网可直接访问，且用户管理未开启或没有多因素认证。这是最高优先级，直接进入止血流程。
• B 级：公网不可访问，但内网多个网段都能访问，上面跑着敏感业务。
• C 级：完全在内网且访问受限，工作流不涉及敏感数据。

这里要说一句不好听的：很多团队在事件发生前根本不关心资产台账，等到被攻击了才发现“原来我们还有这么多个 n8n”。所以 0-2 小时窗口里，资产盘点务必做彻底，宁可多扫几个网段，也不要漏掉任何一个潜在入口。

2.2 2-6小时：止血措施三件套

止血阶段的思路不是“彻底修复”，而是“先把伤口按住”。针对这个漏洞，我建议按顺序做三件事。

第一件：把管理入口从公网撤下来。n8n 默认 5678 端口同时提供 UI 和 API，如果之前直接映射到了公网，马上在防火墙或安全组层面限制来源 IP。只允许办公网段或堡垒机地址访问，其他来源全部拒绝。

# 以 Ubuntu UFW 为例，放行内网管理网段，拒绝其他来源 ufw allow from 10.0.0.0/8 to any port 5678 proto tcp ufw deny 5678/tcp

第二件：临时收紧配置。在 n8n 的.env文件里加上以下设置，并重启服务生效：

N8N_PUBLIC_API_DISABLED=true N8N_PERSONALIZATION_ENABLED=false N8N_SECURE_COOKIE=true

需要留意的是，N8N_PUBLIC_API_DISABLED主要作用于公共 API 模块，对内部 REST API 的覆盖并不完整。这个配置的意义在于减少攻击面，能关的入口先关掉，但你不能关完就觉得万事大吉，升级才是最终出路。

第三件：在反向代理层做最后一道拦截。如果你的 n8n 前面有 Nginx，可以临时加一段规则，对/rest/、/api/、/static/这些管理路径做来源限制。比如：

location /rest/ { allow 10.0.0.0/8; deny all; proxy_pass http://n8n:5678; }

这里有个前提你要想清楚：如果 n8n 的主要业务流程依赖对外 webhook，比如接收支付平台回调或 GitHub 事件推送，那么 webhook 入口不能一刀切封掉，否则业务就断了。正确姿势是单独把 webhook 路径保留在公网，管理后台和 REST 接口全部收紧。这个拆分原则后面第 3.3 节还会细讲。

注意：止血措施只是临时方案。防火墙规则和 Nginx 配置改动都要记录时间和操作人，避免升级完成后忘了解除，造成后续业务莫名不可用。

2.3 6-12小时：升级与补丁落地

止血完成，马上进入正式修复阶段。n8n 官方已经在 1.77.0 里修复了 CVE-2025-68668，所以核心动作就是把实例升到这个版本或更高。

先说升级前必须做的备份。这一步不能省，尤其要备份数据库和.env文件。以 Docker Compose 部署为例：

cd /opt/n8n tar czf backup-$(date +%Y%m%d-%H%M%S).tar.gz ./data ./docker-compose.yml ./.env

备份完成后，开始升级：

# 拉取修复版本镜像 docker compose pull n8n # 重新创建容器 docker compose up -d # 清理旧镜像 docker image prune -f

如果你是 npm 全局安装的方式，操作更简单：

npm update n8n -g sudo systemctl restart n8n

升级后验证四件事：启动日志里有没有报错；工作流列表能否正常加载；连接器凭据是否能正常读取；对外 webhook 能否正常触发。这四项都过了，才叫真正修完。

这里特别强调一个很多人忽略的点：.env里必须要有固定的N8N_ENCRYPTION_KEY。 n8n 有一个很坑的默认行为，如果环境变量里没设置这个密钥，它会在首次启动时生成一个随机值并存在数据库里。一旦升级容器、迁移实例或者数据库需要重建，数据库里的加密信息和当前环境对不上，所有连接器凭据都会变成“失忆”状态，全部无法解密。所以升级前一定要确认这个变量已经显式配置，没配置的话先补上再重启，否则后果很酸爽。

2.4 12-24小时：日志审计与凭据轮换

升级完成后，最不能省的一步是日志审计。因为攻击者一旦已经进过系统，你不仅要修洞，还要搞清楚“丢了什么、被动了什么”。

日志审计主要看三个维度。

第一个维度是异常路径。在访问日志里重点搜索这些特征：

• /rest/workflows、/rest/executions、/rest/credentials这类内部接口。
• URL 里带分号、路径参数、..等特殊字符的请求，这是路径绕过利用的常见痕迹。
• X-Forwarded-Host、X-Original-URL等头部异常的请求。

第二个维度是时间分布。漏洞公开后几小时内就会开始大规模扫描，所以重点排查漏洞公告发布前后这几天的访问记录。Docker 部署可以用--since参数快速导出日志：

docker logs n8n --since 168h | grep -E "/rest/(workflows|executions|credentials)" | head -n 100

第三个维度是行为特征。正常用户访问/rest/executions是低频的，如果某个源 IP 在几分钟内连续翻页拉取大量执行记录，基本可以断定是在脱库。按源 IP 统计访问量是识别这种行为最快的方式：

docker logs n8n --since 168h | awk '{print $1}' | sort | uniq -c | sort -rn | head -n 20

日志审计之后，凭据轮换是更麻烦但必须做的事。这个漏洞可以让未授权攻击者拿到凭据密文，如果加密密钥也暴露，攻击者就能还原出明文。所以只要你的 n8n 曾经暴露在公网，不管有没有确认攻击者得手，所有第三方服务的密钥都应该轮换。

轮换清单至少包括：

• 数据库账号密码，既包括 n8n 自己连接库的连接串，也包括工作流里连接的业务数据库。
• CRM、ERP、支付、云存储等连接器的 API Key。
• SMTP/IMAP 邮箱密码或应用专用密码。
• OAuth Token，在 n8n 里对每个连接器重新授权。
• 如果 n8n 服务账号在云平台有权限，还要轮换对应的 AccessKey。

轮换顺序也有讲究：先在第三方平台吊销旧 Key，再回到 n8n 里编辑对应的 Credential 填新值，最后触发一条相关工作流验证连通性。轮换完顺便清理掉不再使用的连接器，很多团队里躺着几年不动的“僵尸凭据”，就是下次应急时最麻烦的雷。

3. 应急响应中的高频翻车点与避坑经验

3.1 升级后凭据解密失败，这个坑我先踩了

这次应急里，我们团队在升级到 1.77.0 后踩了一个大坑：所有执行记录里的连接器都提示“Could not decrypt credential”。排查原因，才发现这套 n8n 是早期同事用官方 Docker 默认配置部署的，环境变量里从没设置过N8N_ENCRYPTION_KEY。之前每次重启都正常是因为加密密钥存在数据库里，而我们这次升级时误用了清理 volume 的方式，导致数据库文件和密钥序列对不上。

解决办法分情况讨论：

• 如果有完整备份，先把旧数据库恢复回来，在.env里补充原来的加密密钥，再重新升级。
• 如果没有备份，只能逐个连接器重新授权。这个路径最痛苦但最干净，相当于是把 Credential 全部重建一遍。
• 还有个办法是找一台还在旧版本的实例，从它的数据库里读取加密密钥，移植到新环境。但应急场景下我不推荐，因为如果旧实例也有可能被攻击过，那把旧密钥搬过来就是引狼入室，不如老老实实轮换。

这次经历让我总结出一条铁律：从第一天部署 n8n 开始，就必须在.env里显式设置一个强随机的N8N_ENCRYPTION_KEY，并且把密钥保存到公司密码管理平台。这是 n8n 运维的第一纪律，谁不遵守谁在升级时吃苦头。

3.2 日志回溯技巧：别等日志滚动覆盖才想起查

很多团队在应急时遇到的问题，不是没有日志，而是日志已经被滚动覆盖了。Docker 默认的 json-file 日志驱动会按大小轮转，默认配置下可能只保留几天的历史。等你想查的时候，关键时段的日志已经没了。

有两种处理办法。一种是救援式的，先把现有日志导出再说：

docker logs n8n --since 7d --timestamps > n8n-export.log

另一种是根治式的，给 Docker 配置日志轮转策略，让日志保留更长时间：

services: n8n: logging: driver: json-file options: max-size: "50m" max-file: "10"

但我建议更靠谱的方案是把 n8n 日志同步到中央日志平台，比如自建 Loki、ELK，或者云平台自带的日志服务。这样就算容器被销毁重建，日志记录也不会丢。

另外一个小技巧：如果需要反复检索日志，先导出到文件再处理，不要在容器运行状态下反复使用docker logs加管道 grep，那样会占用容器资源，并可能撑大磁盘 IO。应急时先把日志文件拉下来，再用文本工具慢慢分析。

3.3 webhook 入口和 UI 入口必须分开对待

很多 n8n 部署图很随意：把 5678 端口直接映射到公网，然后用 Nginx 反代加个 SSL 就以为安全了。问题是，n8n 的对外 webhook 和管理后台共用同一个服务端口。如果你把公网流量全部放行进去，等于把管理后台也暴露了。

正确做法是拆成两个入口：

• 对外入口：只放行 webhook 路径，比如https://hooks.example.com/webhook/，反向代理到 n8n 容器时，禁止转发/rest/、/api/、/static/等管理路径。
• 管理入口：走堡垒机或专线访问，只监听内网 IP，不向公网开放。

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; } }

这套架构能把这个漏洞的暴露面缩到最小。即便以后 n8n 再爆出类似的访问控制漏洞，公网攻击者能打到的也只剩 webhook 端点，拿不到工作流配置和执行历史数据，后续危害会小很多。

3.4 数据备份与回滚策略

应急升级最怕升级失败后回不去。备份不能只备数据库，docker-compose.yml、.env、以及导出的工作流定义都要收好。n8n 的工作流数据存在数据库里，SQLite 是单文件，用sqlite3在线备份比较稳；PostgreSQL 用pg_dump更可靠。

PostgreSQL 备份命令示例：

docker exec <postgres容器名> pg_dump -U n8n n8n_db > n8n_db.sql

SQLite 备份命令示例：

sqlite3 /data/.n8n/database.sqlite ".backup '/backup/database.sqlite.bak'"

如果升级后发现问题需要回滚，操作不复杂：

docker compose stop n8n # 修改 docker-compose.yml 中的镜像版本号回旧版本 docker compose up -d

但这里有个隐藏风险：版本回退后，如果数据库 schema 已经被新版升级，旧版可能无法兼容。所以更稳妥的做法是先恢复到备份的数据库，再启动旧镜像。这个回滚过程要在变更窗口内完成，不能边跑业务边折腾。

4. 把被动应急变成日常安全基线

4.1 n8n 实例安全配置对照表

这次应急之后，我把 n8n 的常用安全配置整理成一张检查表。以后部署新实例时，直接对照着逐项落实。

这里面有一条要提醒，N8N_BLOCK_ENV_ACCESS_IN_NODE设置后，部分代码节点里读取环境变量的逻辑可能会受影响。上线前要回归测试几条核心工作流，确认没有兼容性问题再全量推广。

4.2 网络层防护与访问控制

自托管工具的防护思路要转变：不要把它当成公网应用来设计，而是当成内网应用。把这个观念转变过来，很多漏洞的威胁都降一大半。

建议的做法：

• n8n 管理端口只监听内网 IP，不在公网暴露。
• webhook 入口单独用反代暴露，不直接把 5678 端口映射到公网。
• 控制工作流的出网请求。很多 n8n 工作流里有 HTTP Request 节点，如果被攻击者篡改，这些节点可能变成 SSRF 跳板。能在宿主机防火墙限制容器出网目标最好，做不了的话至少对必须访问的外部接口建白名单。
• 对 webhook 消息做签名校验。GitHub、支付平台、企业微信这些回调都支持签名或密钥验证，工作流第一个节点一定要校验签名，开发阶段图省事跳过的，生产环境迟早要还债。

4.3 监控告警与定期演练

只修好这一个 CVE 不够，要把升级、监控、审计固化成流程，否则下一次漏洞出现还是手忙脚乱。

我建议至少建立四类监控：

• 异常访问检测：/rest/路径出现非办公网段来源时触发告警。
• 凭据变化告警：Credential 被修改、删除，或新增连接器时通知管理员。
• 工作流变更告警：工作流被导出、导入、编辑，尤其是新增 webhook 触发的工作流。
• 版本跟踪：每周检查一次 n8n release notes 和公开漏洞库，订阅官方安全公告。

告警要接入企业 IM 和工单系统，明确负责人和响应时限。同时建议每季度做一次小规模演习：故意把一台测试 n8n 暴露到公网，让安全团队在规定时间内发现并处置。没有演练过的应急手册，到了真出事时大概率用不上。

4.4 团队协作与应急手册维护

应急响应不是一个人的战斗，而是团队协作。我建议把本文里的时间线、命令、配置项整理成团队内部应急手册，在手册里注明：

• 谁是 n8n 负责人，谁是备份责任人。
• 备份文件放在哪里，如何恢复。
• 管理员账号如何接管。
• 需要联系哪些外部服务商，联系方式是什么。

n8n 的版本迭代比较快，安全配置也会跟着变化。每次大版本升级后，建议把默认配置重新核对一遍，更新手册里的对照表。团队里可以指定一位 n8n 负责人，专门跟踪版本更新和安全公告，这个人不需要每天盯着，但至少每周扫一眼 release notes，遇到安全相关版本第一时间通报。

我在处置 CVE-2025-68668 的过程中最大的体会是：漏洞本身不可怕，可怕的是你根本不知道自己有哪些 n8n 实例、上面跑了哪些数据、密钥存在哪里。等攻击者帮你找到答案的时候，代价早就翻倍了。

最后再分享一个小技巧：n8n 社区版和企业版在审计、单点登录、权限管理这些能力上有差异。如果你所在团队对安全要求很高，建议评估一下官方企业版的功能，很多手工加固都可以在产品层面解决。即便不采购，也可以按这个思路对比社区版的差距，优先补齐最薄弱的环节。这次的 24 小时应急经历，就当是给团队做了一次免费的安全压力测试。