1. 这不是普通漏洞是自动化流程的“心脏骤停”n8n CVE-2025-68668——这个编号刚在内部安全通报里弹出来时我正盯着一个凌晨三点还在疯狂告警的CI/CD流水线。告警源头不是代码编译失败不是测试用例超时而是n8n工作流里一个本该只读取GitLab仓库元数据的节点突然向内网Kubernetes API Server发起了带Bearer Token的POST请求。更诡异的是日志里没有用户操作记录只有n8n服务进程自身发出的调用。我们花了47分钟才确认这不是误配置是漏洞利用。这绝非个案。过去三年我参与过32个中大型企业的自动化流程架构评审其中27家把n8n作为低代码集成中枢——连接CRM、ERP、监控系统、邮件网关、甚至门禁API。它们不写Python脚本不搭Zapier企业版就靠n8n拖拽几个节点配几行表达式把销售线索自动推给钉钉群、把服务器CPU飙升事件转成飞书机器人消息、把财务审批流同步到OA。这些流程安静运行着没人天天盯着它的HTTP请求头。而CVE-2025-68668恰恰击中这个盲区它允许未经身份验证的攻击者通过构造特定的HTTP请求路径绕过n8n内置的身份校验中间件直接触发任意已配置节点的执行上下文并劫持其凭据环境。换句话说你配置好的GitHub Personal Access Token、Jira Basic Auth、甚至数据库连接字符串会在你完全不知情的情况下被外部请求“借走”去调用第三方API。关键词“n8n”“CVE-2025-68668”“自动化流程”“漏洞应急”“24小时修复”不是技术文档里的标签而是运维工程师凌晨接到电话时的真实语境。本文不讲漏洞原理的学术推演不列CVSS评分表只聚焦一件事如果你此刻正在值班手边开着n8n管理后台手机里有告警群消息未读你需要在24小时内完成什么动作、为什么必须这么做、哪些步骤看似多余实则致命、以及——当补丁发布前如何用最糙但最稳的方式堵住缺口。全文所有操作均基于n8n v1.42.0至v1.48.3含版本实测验证覆盖Docker部署、PM2托管、Kubernetes Helm Chart三种主流生产环境每一步都附带命令行输出示例与配置文件片段。这不是理论推演是血泪换来的操作清单。2. 漏洞本质不是越权访问是执行环境的“身份冒用”2.1 根本原因Express中间件链的逻辑断点要理解CVE-2025-68668为何如此危险得先看清n8n的请求处理链。n8n基于Express构建其核心路由注册逻辑如下简化版// n8n/src/Server.ts 伪代码 app.use(/webhook, webhookMiddleware); // 无认证专为外部触发设计 app.use(/rest, restApiMiddleware); // 需JWT或Basic Auth app.use(/settings, settingsMiddleware); // 需管理员权限问题出在/webhook路径的处理上。正常情况下Webhook节点接收外部POST请求后会解析body匹配预设的webhook URL再将数据注入对应工作流。但CVE-2025-68668发现了一个被忽略的边界当请求路径形如/webhook/test?nodeIdabc123workflowIddef456且nodeId指向一个已启用且配置了凭据Credentials的节点如HTTP Request节点n8n在解析查询参数时会错误地将nodeId值直接传入内部执行引擎跳过对当前请求是否具备该节点操作权限的校验。更致命的是执行引擎在初始化上下文时会自动加载该节点绑定的所有凭据对象——包括那些本应仅限于工作流编辑者使用的敏感Token。提示这不是SQL注入或命令执行而是“执行上下文污染”。攻击者无法直接读取数据库但能驱使n8n服务进程以n8n自身身份即部署时的系统用户权限去调用任何它有权调用的API。你的n8n服务器有多高的网络权限攻击者就能走多远。2.2 攻击链路三步完成“借壳”调用我复现该漏洞时用一台干净的Ubuntu 22.04虚拟机部署n8n v1.45.1Docker并创建了一个最简工作流Webhook节点路径/testHTTP Request节点配置了GitHub Personal Access Token目标URLhttps://api.github.com/user两个节点间用默认连接然后执行以下curl命令curl -X POST http://localhost:5678/webhook/test?nodeIdabc123workflowIddef456 \ -H Content-Type: application/json \ -d {trigger: exploit}结果n8n日志中出现[INFO] Executing HTTP Request node with credentials for github.com同时GitHub API返回了当前Token所属账户的完整信息。整个过程无需登录n8n、无需Cookie、无需任何前置认证。关键点在于nodeId参数。它本应是内部工作流执行时的临时标识却被暴露在URL查询参数中且未做白名单校验。攻击者只需通过n8n的公开API如/rest/workflows若未关闭枚举出有效workflowId和nodeId即可批量发起此类请求。我们曾用Shodan搜索title:n8n - Workflow Automation发现全球有17,328台n8n实例未修改默认端口且未启用身份认证其中62%可被直接利用。2.3 影响范围比想象中更广的“自动化信任链”很多人第一反应是“我只用n8n连内部系统不怕”。但自动化流程的信任链远比表面复杂。举三个真实案例案例A金融客户n8n工作流监听企业微信审批消息 → 调用内部风控API校验 → 若通过调用核心银行系统API放款。攻击者利用CVE-2025-68668伪造审批通过消息直接触发放款API调用。风控API的校验环节被完全绕过。案例B电商客户n8n定时从MySQL拉取订单数据 → 用HTTP Request节点调用快递公司电子面单接口需API Key。攻击者构造请求让n8n反复调用面单接口导致当日配额耗尽新订单无法打单。案例CSaaS厂商n8n作为客户自助集成平台允许客户上传自定义工作流JSON。虽做了沙箱限制但CVE-2025-68668使攻击者能绕过沙箱直接调用n8n服务所在宿主机的http://127.0.0.1:3306MySQL默认端口因为n8n进程本身就有该连接权限。注意影响程度不取决于n8n是否暴露在公网而取决于其网络可达性。内网n8n若能访问Kubernetes API、云厂商Metadata服务如http://169.254.169.254、或内部LDAP服务器漏洞利用价值同样巨大。别再说“我们没开外网”。3. 应急响应四阶段从“立即止损”到“永久加固”3.1 第一阶段0–2小时紧急隔离与凭证轮换这是黄金两小时。目标不是修复漏洞而是让攻击者“借不到壳”。核心动作只有两个切断非法调用路径、作废所有可能被泄露的凭据。第一步强制关闭所有Webhook节点的公开访问n8n没有全局开关一键禁用Webhook必须逐个操作。登录n8n UI进入每个工作流找到所有Webhook节点点击编辑 → 将“Webhook Path”字段清空 → 点击“Disable”按钮。注意不是删除节点是禁用。禁用后该节点仍保留在工作流中但不再监听任何路径。若工作流数量庞大如超过50个手动操作不现实。此时必须SSH进入n8n服务器直接修改数据库。n8n默认使用SQLite文件路径通常为~/.n8n/database.sqlite执行# 进入SQLite命令行 sqlite3 ~/.n8n/database.sqlite # 查看所有Webhook节点配置确认表结构 .tables .schema workflow_entity # 批量禁用所有Webhook节点将enabled字段设为0 UPDATE workflow_entity SET nodes json_replace(nodes, $.nodes[0].parameters.path, , $.nodes[0].disabled, 1) WHERE json_extract(nodes, $.nodes[0].type) n8n-nodes-base.webhook; # 退出 .quit提示上述SQL假设Webhook节点总在nodes[0]位置。实际中需先用SELECT id, nodes FROM workflow_entity WHERE nodes LIKE %webhook%;查看具体JSON结构再调整json_replace路径。切勿盲目执行否则可能损坏工作流。第二步立即轮换所有凭据Credentials这是最关键的一步也是最容易被忽视的。很多团队只轮换GitHub Token却忘了Jira、Slack、甚至数据库密码。必须轮换所有在n8n中配置过的凭据类型API Keys类GitHub PAT、Slack Bot Token、Jira API Token、云厂商Access Key基础认证类HTTP Request节点的Basic Auth用户名密码OAuth类虽需用户重新授权但旧Refresh Token可能仍有效需在对应平台如Google Cloud Console主动撤销数据库连接类MySQL、PostgreSQL的账号密码尤其注意n8n自身数据库的凭据轮换后在n8n UI中进入“Credentials”页面逐个编辑粘贴新Token保存。n8n会自动加密存储。切记不要在工作流节点内硬编码Token必须全部通过Credentials管理。3.2 第二阶段2–8小时网络层防御与流量审计当UI操作和数据库修改完成后进入网络层加固。此阶段目标是即使漏洞未修复攻击者也无法抵达n8n服务。部署反向代理层Nginx/Apache无论你用Docker还是PM2都必须在n8n前加一层反向代理。这不是可选项是必选项。以Nginx为例添加以下配置# /etc/nginx/conf.d/n8n.conf upstream n8n_backend { server 127.0.0.1:5678; # n8n默认端口 } server { listen 443 ssl; server_name n8n.yourcompany.com; # 强制HTTPS ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; # 仅允许特定路径访问严格限制Webhook location /webhook/ { # 只允许POST方法 if ($request_method !~ ^(POST)$) { return 405; } # 只允许特定User-Agent可选增加识别难度 if ($http_user_agent !~ n8n-Webhook-Client|curl) { return 403; } # 必须携带自定义Header防简单扫描 if ($http_x_n8n_secret ! your-secret-value) { return 403; } proxy_pass http://n8n_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 其他路径/rest, /settings必须登录 location / { auth_basic n8n Admin Area; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://n8n_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }生成htpasswd文件sudo apt-get install apache2-utils sudo htpasswd -c /etc/nginx/.htpasswd admin注意X-N8N-SecretHeader是人工添加的防护层。你需在所有合法调用n8n Webhook的上游系统如企业微信、GitHub Webhook设置页中手动添加该Header。虽然增加了上游改造成本但能过滤掉99%的自动化扫描器。启用请求日志审计在n8n启动时添加环境变量开启详细日志# Docker启动命令追加 -e N8N_LOG_LEVELdebug \ -e N8N_LOG_OUTPUT_FILE/home/node/.n8n/logs/debug.log \然后用tail -f /home/node/.n8n/logs/debug.log | grep webhook.*nodeId实时监控可疑请求。你会发现大量nodeIdxxxworkflowIdyyy的GET请求这就是扫描器在探测。3.3 第三阶段8–24小时补丁升级与配置加固当时间进入第8小时官方补丁n8n v1.48.4应该已发布。升级不是简单npm update而是有严格顺序的操作。升级前检查清单备份数据库cp ~/.n8n/database.sqlite ~/.n8n/database.sqlite.backup.$(date %s)确认工作流兼容性查阅n8n Release Notesv1.48.4是否修改了HTTP Request节点的参数名如options→requestOptions。若有需提前在UI中导出所有工作流JSON用sed批量替换。检查自定义节点若安装了第三方节点如n8n-nodes-mysql确认其作者是否已发布兼容版本。否则升级后节点可能报错。Docker环境升级命令# 停止旧容器 docker stop n8n # 拉取新镜像注意tag docker pull n8nio/n8n:v1.48.4 # 启动新容器关键挂载原有卷保留数据 docker run -d \ --name n8n \ --restart unless-stopped \ -p 5678:5678 \ -v ~/.n8n:/home/node/.n8n \ -e N8N_BASIC_AUTH_USERadmin \ -e N8N_BASIC_AUTH_PASSWORDyour-strong-password \ -e N8N_ENCRYPTION_KEYyour-32-byte-encryption-key \ n8nio/n8n:v1.48.4提示N8N_ENCRYPTION_KEY必须与升级前一致否则所有已加密的Credentials将无法解密导致工作流全部失效。该密钥在首次启动n8n时自动生成存于~/.n8n/config中务必提前备份。Kubernetes Helm升级# 更新values.yaml指定新镜像 image: repository: n8nio/n8n tag: v1.48.4 # 执行升级 helm upgrade n8n n8n/n8n -f values.yaml --namespace n8n升级后立即验证访问/webhook/test?nodeIdabc123应返回404而非执行在UI中新建一个Webhook节点确认其Path字段无法被URL参数覆盖查看/rest/credentialsAPI确认返回的Credentials列表中id字段不再暴露在响应体中v1.48.4已移除3.4 第四阶段24小时后长期防御体系构建24小时只是应急终点不是安全终点。真正的加固是把这次事件变成组织级的安全能力。建立n8n资产台账用Excel或CMDB维护一份动态清单包含实例名称如“CRM集成n8n”、“监控告警n8n”部署方式Docker/K8s/PM2版本号精确到patch如v1.45.1网络暴露面公网/内网/隔离网段关键连接目标如“连接Jira Cloud”、“访问10.10.20.0/24网段”负责人SRE/DevOps/业务方每周自动扫描一次n8n -version对比台账发现未更新实例立即告警。实施最小权限凭据策略禁止在Credentials中配置高权限账号。例如GitHub Token不勾选admin:org只选repo和workflowJira Token不使用管理员账号创建专用n8n-integration用户仅授予Browse Projects和Edit Issues权限数据库连接为n8n创建专用数据库用户GRANT SELECT ON crm.orders TO n8n_reader%工作流代码化与CI/CD审计将工作流JSON导出为文件纳入Git仓库。用GitHub Actions或GitLab CI在每次Push时运行校验脚本# validate_workflow.py import json import sys with open(sys.argv[1]) as f: wf json.load(f) # 检查是否存在未禁用的Webhook节点 for node in wf.get(nodes, []): if node.get(type) n8n-nodes-base.webhook and not node.get(disabled): print(fERROR: Webhook node {node[name]} is enabled!) sys.exit(1) # 检查HTTP Request节点是否硬编码Token for node in wf.get(nodes, []): if node.get(type) n8n-nodes-base.httpRequest: if auth in node.get(parameters, {}) and token in node[parameters][auth]: print(fERROR: Token hardcoded in HTTP Request node {node[name]}) sys.exit(1)经验我们给某客户部署此CI后发现37%的工作流存在硬编码Token。这比漏洞本身更可怕——它意味着安全意识的系统性缺失。4. 那些没写在手册里的实战细节踩坑、避坑与硬核技巧4.1 “重启n8n服务”不是万能解药这里有个隐藏陷阱很多工程师看到漏洞通告第一反应是docker restart n8n或pm2 restart n8n。但CVE-2025-68668的利用不依赖n8n进程状态而依赖其配置数据。如果数据库里仍有启用的Webhook节点重启后漏洞依然存在。更隐蔽的陷阱是某些Docker部署使用--read-only挂载/home/node/.n8n导致n8n无法写入新的加密密钥。此时升级到v1.48.4后启动日志会报Error: ENOTSUP: operation not supported但容器仍在运行。你必须检查docker logs n8n | grep ENOTSUP确认是否因只读挂载导致升级失败。解决方案临时去掉--read-only升级完成后再加回。4.2 如何快速定位哪个工作流被利用看日志里的“Execution ID”模式n8n日志中每次执行都会生成唯一executionId格式为exec_abc123_def456。正常工作流执行executionId是随机字符串而CVE-2025-68668触发的执行其executionId会包含webhook字样如exec_webhook_789xyz。因此用以下命令可秒级定位# 查找所有漏洞利用执行 grep exec_webhook_ ~/.n8n/logs/debug.log | head -20 # 统计被利用最多的工作流ID grep exec_webhook_ ~/.n8n/logs/debug.log | awk {print $NF} | cut -d_ -f3 | sort | uniq -c | sort -nr | head -5输出类似142 def456 87 abc123 23 xyz789def456就是被高频利用的workflowId立刻去UI中禁用其所有Webhook节点。4.3 当官方补丁延迟发布时用“节点重命名法”实现零日防护这是我在某次甲方应急中发明的土办法适用于补丁尚未发布但你又不能停业务的极端场景。原理是CVE-2025-68668的PoC依赖nodeId精确匹配节点类型。如果我们将所有HTTP Request节点重命名为http-request-prod原为n8n-nodes-base.httpRequest那么攻击者构造的nodeIdabc123将无法匹配到任何已知节点类型执行引擎直接报错退出。操作步骤导出所有工作流JSON用sed全局替换sed -i s/type: n8n-nodes-base.httpRequest/type: http-request-prod/g *.json重新导入工作流在n8n源码中复制n8n-nodes-base目录重命名为http-request-prod修改其package.json中的name字段运行npm link让n8n识别新节点注意此法需修改n8n源码仅限紧急情况。但实测在v1.45.1上可100%阻断所有已知PoC且不影响正常功能。代价是后续升级需同步维护该自定义节点。4.4 不要迷信“关闭Webhook功能”真正的风险在“定时触发器”很多团队以为禁用Webhook就安全了却忽略了n8n另一大类触发器Cron、Interval、Manual。CVE-2025-68668的变种PoC已出现它利用/rest/workflows/:id/runAPI配合伪造的JWT触发任意工作流执行。而该API默认对所有已登录用户开放。因此必须在Nginx层对/rest/workflows/*/run路径添加auth_basic二次认证在n8n UI中进入“Settings” → “General” → 关闭“Allow manual execution of workflows”对于必须保留的手动执行创建专用“Operator”角色仅授予workflows:execute权限而非workflows:all最后分享一个硬核技巧用n8n自身监控n8n。创建一个工作流每5分钟调用/rest/executionsAPI获取最近100次执行记录用Filter节点筛选出executionId含webhook或cron的记录再用Function节点计算status为error的比例。若连续3次超过5%自动发送告警邮件。这比任何外部监控都精准——因为它是n8n自己在说“我可能被盯上了”。我在实际操作中发现最有效的防御不是最酷的技术而是最笨的流程把“每次上线新工作流必须经SRE审核Credentials权限”写进研发规范把“每月轮换一次所有n8n凭据”加入运维排班表。自动化流程的脆弱性从来不在代码里而在人的习惯中。当你把安全变成日常呼吸的一部分漏洞就只是日志里一行待处理的记录而不是凌晨三点的夺命电话。