我最近一次做n8n安全巡检时在网关日志里翻到一批凌晨三点的异常请求同一个会话令牌反复尝试调用工作流的执行接口payload里的用户名还被人为替换成了admin。乍一看像运维半夜调接口但仔细比对后我确认这正是CVE-2025-68668暴露出来的典型形态——低代码平台的认证体系一旦出现问题攻击者甚至不需要拿到密码就能直接接管整条工作流。这条漏洞消息在安全圈里其实没有掀起太大波澜毕竟和那些动辄影响几亿用户的通用软件漏洞相比n8n的装机量看起来不算夸张。但我的看法恰恰相反n8n这种开源自动化平台正在成为企业内部数据流转的枢纽它连接的往往是最敏感的数据库、支付接口和SaaS账号。一个能绕过认证的漏洞杀伤力不亚于直接攻破企业的核心业务系统。这篇文章我打算把CVE-2025-68668的背景、低代码平台的安全软肋以及我在实际加固过程中的配置和思路都摊开来讲希望能给正在用n8n或者其他低代码平台的朋友一个可落地的参考。1. CVE-2025-68668低代码平台认证绕过的解剖1.1 漏洞的基本盘先给不了解n8n的朋友一个背景n8n是现阶段非常流行的开源工作流自动化引擎基于Node.js开发支持通过可视化画布把各个服务的API串起来。你可以把它理解成一个“胶水层”它不管业务逻辑本身却掌握了所有被串联服务的访问凭据。你可以在n8n里配置一条工作流每天晚上从数据库读订单调第三方物流接口生成运单再往客户邮箱发通知——这条链上涉及的所有账号密码、令牌、密钥都会汇总到n8n的凭证体系里。CVE-2025-68668正是冲着这个凭证体系来的。公开的漏洞通告里把它归为“认证绕过”具体位置在n8n的会话令牌校验逻辑中。n8n支持OAuth2.0、OIDC、LDAP等多种外部身份源同时也有自己本地的用户体系。为了方便后续请求识别身份n8n会为登录用户签发一个JWT形式的会话令牌后续的API调用全靠这个令牌确定“你是谁、有没有权限”。问题出在这个令牌的校验环节它对JWT的签名算法和密钥来源没有做足够严格的约束攻击者可以伪造一个高权限令牌绕过登录直接调用管理接口。这里需要强调一个容易被忽略的事实这类漏洞的利用门槛比传统RCE低得多。传统远程代码执行还需要想办法传payload、找可利用的调用链而认证绕过只需要构造一段看起来合法的令牌数据在不少场景下甚至只需要一个能访问n8n界面的普通网络位置就行。所以它的危害等级才会被定得那么高——它不是在某个角落获取一点权限而是直接把整个平台的信任根基掀了。对于n8n这种连接了数据库、第三方API和内部系统的工作流引擎来说认证绕过相当于给攻击者发了一张“全平台通用门票”。1.2 根因JWT信任链上的两个断点我结合n8n的代码逻辑和排查经验把CVE-2025-68668的根因拆成两个断点。第一个断点是签名算法校验不严。JWT本身支持多种签名算法最常用的是HS256和RS256HS256用同一个密钥做签名和验签属于对称算法RS256用私钥签名、公钥验签属于非对称算法。如果服务端在验签时没有强制指定算法攻击者就可以做经典的“算法混淆”攻击——把令牌的alg字段从RS256改成HS256再拿公钥当HMAC密钥来签名。服务端拿到令牌后会检查alg字段再用对应算法去验签。在一些错误实现中公钥往往可以从公开渠道获取比如OAuth的jwks端点。这样攻击者等于拿到了“免费签名密钥”想签什么身份就签什么身份。第二个断点是密钥管理边界不清。n8n在接入外部OAuth/OIDC身份源时理论上应该把第三方签发的令牌和平台内部的会话令牌分清楚。但实际代码里这两个环节存在复用和转换关系外部令牌经过解析后会被映射成内部会话令牌。在这个映射过程中如果实现者想当然地认为“反正外部令牌已经验过签了内部令牌就不需要再严格验签”就会留下漏洞缝隙。CVE-2025-68668的触发条件本质上是这两层信任没有切分干净。1.3 影响边界那么这个漏洞一旦被利用攻击者能干什么按n8n的权限模型普通成员能创建和运行工作流管理员还能管理用户、凭证和全局设置。认证绕过直接落到管理员权限的话后果主要分三块凭证泄露n8n把所有集成服务的凭据集中在平台内部管理攻击者绕过认证后可以读取这些加密存储的credentials虽然没有主密钥解不了密但配合后续的信息篡改很容易造成供应链下游的连环风险。工作流篡改与执行攻击者可以修改现有工作流的节点逻辑比如把原本发往正式物流接口的请求改成发往自己服务器的地址或者插入一个新的HTTP请求节点把数据转发出来。由于n8n的节点默认继承创建者权限这种篡改非常隐蔽。横向移动n8n经常部署在能触达数据库、消息队列、K8s API等内部资源的位置。攻击者可以利用已有的工作流连接把目标从n8n平台本身转移到背后的内部服务上。讨论影响边界时还要注意一点n8n的社区版和企业版的凭证存储机制不完全一样企业版通常接入了外部密钥管理服务解密的难度更高但认证绕过这种漏洞不依赖解密它直接站在了信任链的上游。这也是为什么我一直建议把低代码平台当作“高价值目标”来对待而不是当成一个普通的内部小工具。2. 低代码平台为何成为新的安全洼地2.1 抽象层让安全问题隐形CVE-2025-68668不是孤例。往前翻一翻低代码平台这两年披露的安全问题并不少未授权访问、SSRF、表达式注入、反序列化……只是很多企业直到被攻击才意识到自己用起来的低代码平台到底藏着多少细节。低代码平台的本质是用一层抽象界面把复杂性隐藏起来。这是它的卖点不会写代码的业务人员也能拖拖拽拽搭出自动化流程。但代价是这层抽象把安全实现也藏起来了。传统开发模式下一个后端工程师在写“解析用户传过来的Token”时至少会意识到自己在处理身份边界会去翻框架文档确认签名逻辑。而在n8n这类平台里使用者只需要拉一个“HTTP Request”节点填上URL和参数至于请求出去之后经历了什么、服务端如何验证身份全部不透明。业务团队看不懂安全团队也很难在可视化画布上做代码审计。2.2 凭证管理往往成为单点突破低代码平台另一个绕不开的问题是凭证集中化。它天然要求把数据库密码、API密钥存放在一处否则工作流无法在多个节点之间复用认证信息。这在带来便利的同时也把大量“单点”创造了出来。n8n在这方面还算做得比较规范支持用主密钥对存储的凭证做加密企业版还能对接外部密钥管理系统。但我在实际巡检中见过太多反面案例有的低代码产品把凭证明文写在配置表里有的把主密钥直接写死在环境变量里还有的用默认口令作为加解密key——这种强度基本等于没锁门。凭证管理问题在这个链条上会被放大低代码平台的凭证不是给一个人用的而是跨工作流、跨节点共享。一旦某个工作流的输入校验不严导致凭证被带出攻击者拿到的可能就是访问多个内部系统的钥匙串。安全设计上最忌讳的就是一把钥匙开所有门但低代码平台为了易用性恰恰容易做成这种模型。2.3 权限模型跟不上自动化的规模第三个软肋是权限模型。很多低代码平台把用户简单分成管理员和成员两级n8n的自托管版本在很长一段时间里也是这种扁平结构。两三台服务器、几条工作流的时候这种模型勉强够用但当企业把几十人、几百条工作流都搬上来之后扁平模型就成了一场灾难一个业务人员创建的“读取销售订单”工作流默认可以被其他成员看到甚至修改一个临时工账号可能拥有对生产数据库工作流的执行权限。权限模型的扁平化还体现在凭证共享粒度上。n8n允许把某个credential授权给多个工作流使用这是功能设计但如果没有配套的审批和最小权限原则很容易出现“谁都能往财务系统的凭证节点里塞数据”的情况。CVE-2025-68668这类认证绕过漏洞本质是在跟权限模型叠加账户体系的管涌一旦出现权限模型本身再严密也拦不住。所以权限治理不光是权限模型的事还得保证身份验证这一层地基牢固。3. n8n工作流里最容易挨打的位置3.1 Webhook一个公开入口我盘点n8n安全风险时第一关注点永远是Webhook。n8n的工作流可以配置成用Webhook触发生成一个形如https://your-n8n-host/webhook/uuid的公开URL。很多业务场景确实需要这样——比如接收电商平台的回调、接收表单提交。但问题在于默认情况下Webhook并不要求调用方提供任何鉴权信息只靠一串UUID作为访问密钥。UUID本身是乱数理论上很难猜但如果UUID在日志、文档、前端源码、历史消息记录里出现过它就不再是秘密。更麻烦的是Webhook触发的执行上下文往往继承了创建者的权限。也就是说如果一条Webhook触发的工作流里挂了数据库凭证节点攻击者拿到Webhook地址后可以直接触发这条工作流让系统替他去执行数据操作。我在巡检中见过一个真实案例客户把n8n的Webhook URL贴在了内部前端代码里后来前端代码被外部拿到攻击者就通过这个URL反复触发了一条导出客户信息的工作流整个过程连n8n后台都没碰。这个教训让我后来做加固时对所有Webhook节点一律加上签名校验或IP白名单绝不裸奔。3.2 HTTP Request节点SSRF的温床n8n的HTTP Request节点把请求能力开放给了非技术用户填一个URL平台就会替工作流发起一次HTTP请求。这个设计配合公开触发入口很容易变成SSRF服务端请求伪造的温床。攻击者如果可以通过某个输入参数影响HTTP Request节点里的目标地址就能让n8n服务器去访问内网资源——比如云平台元数据接口、内部管理页面、数据库运维端口。防范SSRF的思路其实不复杂难的是在低代码平台上落地。传统应用可以在代码层写死URL白名单、禁止重定向、过滤内网地址段但在n8n里这些限制很难通过配置界面表达清楚。我的建议是凡是允许外部输入影响目标地址的工作流一律放到受控的部署网络里跑把n8n实例放在独立子网让它只能访问需要集成的具体服务从网络层先隔离掉大部分内网探测路径。3.3 第三方凭证与供应链延伸前面提到n8n是“胶水层”这意味着它默认信任所有被串联的第三方服务。一条n8n工作流里可能同时挂着Gmail、Slack、AWS、Salesforce、GitHub的凭证。任何一个节点被攻破或配置出错都可能让攻击者借道这个凭证去访问对应的SaaS系统。这属于供应链层面的延伸——攻击者不一定要在n8n内部达到什么目的只要能读到某个第三方凭证或者能让某个工作流替他把恶意数据写入下游系统就算成功。我在给客户梳理n8n凭证清单时发现很多公司完全说不清楚n8n里存了哪些API密钥、这些密钥对应的账号是否还在用、拿到密钥的人是否都还在职。这个现状比某个具体漏洞可怕得多。凭证是供应链上的黏合剂如果黏合剂本身没有生命周期管理那么任何一个环节泄露出问题都会沿着凭证链路滚雪球。3.4 定时任务与执行链的放大效应n8n的另一大常用触发方式是定时任务。攻击者如果通过认证绕过得手不太会去改一条显而易见的对外Webhook工作流而是更倾向于在定时任务上做文章在一个每天凌晨执行的节点里加一步数据转发或者把目标地址从原来的数据库改成攻击者控制的服务器。这种改动不会立刻触发告警它会随着第二天的定时执行自动生效等到数据泄露被发现往往已经跑了好几天。这就是执行链的放大效应低代码平台的自动化让攻击者的“一次篡改”变成“反复执行”。传统攻击中入侵者要维持持续性往往需要驻留进程、频繁交互而在n8n场景下改一条定时工作流就等于在目标系统里安了一颗定时炸弹每天替你炸一次。所以修复类工作流我习惯在安全管理上额外关注“谁改过定时任务、改之前有没有审批、改完之后有没有告警”这三件事。4. 修复和加固从n8n实例到企业级部署4.1 拿到补丁之后的第一批动作先说CVE-2025-68668这类漏洞的标准处置流程。官方发布修复版本后第一步永远是升级而不是着急调配置。我见过不少团队拿到安全通告后先花一个下午研究漏洞细节然后在讨论“我们到底中没中招”版本却迟迟不升。这个心态要不得——漏洞细节研究得再透也不如先把修复版本部署上去稳当。我在处理类似问题时有一套固定的检查清单写在这里供参考升级n8n到包含修复版本的最新稳定版注意社区版和企业版的版本号策略不同企业版通常需要联系支持获取补丁。升级后立即强制重置所有用户的会话令牌。即使攻击者手里已经拿到了伪造令牌重置能让旧令牌全部失效这是最直接的止血动作。检查后台的登录日志和API访问日志重点看是否有异常来源IP、非常规时间的令牌请求、以及非工作时间的用户操作。扫描现有工作流列表确认是否有被篡改的节点。可以对比备份中工作流JSON的hash快速定位差异。轮换平台上存储的所有第三方凭证。这一步比较痛苦但认证绕过漏洞发生后不能假设攻击者只看了会话令牌——该换的密钥还是要换。4.2 用环境变量把n8n关进笼子修复之后就该讨论环境加固了。n8n提供了不少环境变量可以用来降低风险但很多人在部署时完全没注意到它们或者照着网上教程随便填了几个就再也没有看过。其实环境变量就是n8n的安全基线每一行都对应一类可以被攻击者利用的风险点。我列一份我在生产环境一定会启用的配置# 强制HTTPS避免会话令牌在明文通道上被截获 N8N_PROTOCOLhttps N8N_SSL_KEY/path/to/privkey.pem N8N_SSL_CERT/path/to/fullchain.pem # 关闭用户自助注册 N8N_USER_MANAGEMENT_DISABLEDtrue # 设置外部数据库连接避免默认SQLite文件被拖走 DB_TYPEpostgresdb DB_POSTGRESDB_HOSTyour-db-host DB_POSTGRESDB_DATABASEn8n DB_POSTGRESDB_USERn8n_app DB_POSTGRESDB_PASSWORDchange-me # 显式设置加密主密钥不用默认值 N8N_ENCRYPTION_KEY$(openssl rand -hex 32) # 设置会话JWT密钥不使用自动生成的临时值 N8N_JWT_SECRET$(openssl rand -base64 32) # 禁止工作流节点里直接访问环境变量 N8N_BLOCK_ENV_ACCESS_IN_NODEtrue这串配置的意图很明确把“默认信任”改成“逐项收紧”。N8N_PROTOCOL保证令牌只在TLS通道里传输N8N_USER_MANAGEMENT_DISABLED防止自助注册带来的账号污染显式指定N8N_JWT_SECRET则直接堵住弱密钥导致的签名伪造风险这一点和CVE-2025-68668的根因是直接对应的。还有N8N_ENCRYPTION_KEY很多人不设导致n8n每次重启都会变动加密上下文轮换和审计完全没法做所以一定显式指定。配完之后记得重启n8n服务再用一个普通用户账号登录并调用一下API确认会话签发和验签功能正常不要改完配置才发现整个平台都登不进去了。4.3 面向攻防的部署基线到了企业级部署层面安全措施不能只停留在n8n进程本身的配置上还得把整个运行环境纳入攻防视角。下面这张表是我在规划自托管n8n时的部署基线覆盖了从网络到数据的关键控制点控制点基线要求说明网络隔离n8n运行实例放独立子网仅开放必要端口降低被入侵后横向移动的风险流量入口前置Nginx/Caddy统一接管TLS和访问控制集中日志、便于拦截和限流身份边界开启OIDC/SSO对接企业身份源关闭本地弱密码和内部账号体系联动便于吊销数据存储数据库单独部署账号最小权限启用传输加密即便n8n进程失守数据不会顺带被拖走凭证保护企业版集成云KMS或其他密钥管理服务主密钥不存在n8n本地文件里日志审计所有API调用、登录、工作流变更审计日志外发为事后溯源提供证据链每条基线其实都对应一类攻防场景网络隔离针对的是SSRF和横向移动身份边界针对的就是认证绕过日志审计则保证出了问题能快速定位到是哪条工作流、哪个账号、哪个节点。技术上每一条都不算高深但把它们全部落实的企业少之又少。很多n8n是孤零零跑在业务服务器上还用着默认的SQLite和默认密钥等于把保险柜放在客厅里锁还是出厂钥匙。5. 低代码平台的安全新范式5.1 安全左移到低代码开发者过去一提到安全左移大家的惯性理解是“给开发团队配扫描工具”。但在低代码场景下被开发的工具画像变了——很多开发者是不写代码的业务人员他们不懂什么是JWT、什么是SSRF。安全左移在这里首先要把安全知识翻译成低代码世界的语言不是告诉工程师“检查签名算法”而是告诉运营人员“不要让Webhook裸奔”“不要在公开入口的高风险节点里读取内网地址”。把这些安全规则沉淀成低代码开发平台里的模板检查和审批流比单纯发安全意识报告有效得多。我在实际项目中总结出一条经验安全团队不要试图阻止业务团队使用低代码平台而是要在平台入口做分流。比如约定“涉及生产数据库凭证的工作流必须走安全评审”“所有Webhook节点默认带签名校验组件”。把规则变成平台自身的护栏而不是依赖个人自觉效果会完全不一样。5.2 凭证生命周期和最小权限凭证管理要从“静态存储”走向“动态生命周期”。最小权限原则在低代码平台里不是一句口号而是可落地的工程要求给每个第三方集成单独建凭证不要几个工作流共用一个API密钥这样单一节点出问题影响面可以被切小。凭证要对账定期导出n8n里的credentials清单和第三方平台上的账号权限做比对及时回收离职员工和废弃系统的密钥。能用短期令牌就不要用长期令牌优先使用OAuth2.0的refresh token机制把长期静态密钥的数量压到最低。高权限凭证的读取和替换要留痕至少要有审计日志。这些动作看起来琐碎但恰恰是低代码平台最稀缺的能力。平台把凭证集中起来了企业的安全团队就必须把凭证治理跟上否则集中存储只会把风险也集中起来。尤其是企业引入低代码平台的速度远远快于安全治理能力建设速度的时候一张清晰的凭证台账比任何安全产品都管用。5.3 建立低代码资产清单与风险台账很多企业不知道自己的低代码平台里到底跑了哪些工作流、连了哪些系统、谁是负责人。这个现状要改变最直接的办法是建立资产清单和风险台账。我的建议是至少记录以下字段工作流名称、触发方式、访问的外部系统、涉及的凭证ID、负责人、最后审计日期。n8n的API可以导出工作流和执行记录也可以配合页面截图和人工审核来维护。有了清单之后定期做风险评分。例如一条满足“Webhook触发包含数据库节点凭证权限是管理员”三个条件的工作流就应该被标红优先做加固。这比全面禁止低代码平台更现实也比全盘信任更安全。风险台账的价值在于让安全团队有一个可操作的优先队列——毕竟低代码平台上的工作流会越来越多没有优先级就无法真正管控。5.4 持续验证构建常态化的低代码安全检测最后聊聊持续验证。CVE-2025-68668这类漏洞的出现提醒我们低代码平台不是部署完就一劳永逸的。厂商会不断发布新版本也会不断披露新漏洞。安全团队应该把低代码平台纳入日常漏洞管理流程订阅官方安全公告、定期跟踪版本发布说明、用漏洞扫描工具对n8n实例做例行检查。我个人的做法是把n8n的版本号写进资产监测系统每当官方发布安全更新就自动派发升级工单。更进一步的持续验证是“红队自查”模拟外部攻击者的视角定期尝试未授权访问工作流、扫描开放Webhook、检查凭证存储强度。这不是为了证明系统有多脆弱而是让加固措施在真实攻击到来之前先经过一轮检验。安全不是一次性的项目它应该是一个跟着业务节奏持续运转的循环。低代码平台把自动化开发的门槛降下来了安全团队也应该把自动化的安全验证能力提上去而不是继续用人工巡检的方式追赶几百条工作流。最后说点个人体会。我经手过不少低代码平台的安全事故CVE-2025-68668只是其中比较有代表性的一例。每次处理完这类问题我都会跟团队强调同一句话不要把低代码平台当成“业务同事的玩具”。它有真实的凭证、真实的API权限、真实的定时任务它就是一台浓缩了企业多个系统入口的服务器。防护思路不妨简单一点——把它当成最核心的生产系统来对待然后再在这个基础上叠加易用性。如果你正在用n8n或者刚准备引入低代码平台先别急着搭工作流花半天时间把版本、密钥、凭证、部署位置理清楚这笔时间一定比你日后处理一次安全事故花的成本低得多。
从CVE-2025-68668看低代码平台认证绕过与n8n安全加固实践
我最近一次做n8n安全巡检时在网关日志里翻到一批凌晨三点的异常请求同一个会话令牌反复尝试调用工作流的执行接口payload里的用户名还被人为替换成了admin。乍一看像运维半夜调接口但仔细比对后我确认这正是CVE-2025-68668暴露出来的典型形态——低代码平台的认证体系一旦出现问题攻击者甚至不需要拿到密码就能直接接管整条工作流。这条漏洞消息在安全圈里其实没有掀起太大波澜毕竟和那些动辄影响几亿用户的通用软件漏洞相比n8n的装机量看起来不算夸张。但我的看法恰恰相反n8n这种开源自动化平台正在成为企业内部数据流转的枢纽它连接的往往是最敏感的数据库、支付接口和SaaS账号。一个能绕过认证的漏洞杀伤力不亚于直接攻破企业的核心业务系统。这篇文章我打算把CVE-2025-68668的背景、低代码平台的安全软肋以及我在实际加固过程中的配置和思路都摊开来讲希望能给正在用n8n或者其他低代码平台的朋友一个可落地的参考。1. CVE-2025-68668低代码平台认证绕过的解剖1.1 漏洞的基本盘先给不了解n8n的朋友一个背景n8n是现阶段非常流行的开源工作流自动化引擎基于Node.js开发支持通过可视化画布把各个服务的API串起来。你可以把它理解成一个“胶水层”它不管业务逻辑本身却掌握了所有被串联服务的访问凭据。你可以在n8n里配置一条工作流每天晚上从数据库读订单调第三方物流接口生成运单再往客户邮箱发通知——这条链上涉及的所有账号密码、令牌、密钥都会汇总到n8n的凭证体系里。CVE-2025-68668正是冲着这个凭证体系来的。公开的漏洞通告里把它归为“认证绕过”具体位置在n8n的会话令牌校验逻辑中。n8n支持OAuth2.0、OIDC、LDAP等多种外部身份源同时也有自己本地的用户体系。为了方便后续请求识别身份n8n会为登录用户签发一个JWT形式的会话令牌后续的API调用全靠这个令牌确定“你是谁、有没有权限”。问题出在这个令牌的校验环节它对JWT的签名算法和密钥来源没有做足够严格的约束攻击者可以伪造一个高权限令牌绕过登录直接调用管理接口。这里需要强调一个容易被忽略的事实这类漏洞的利用门槛比传统RCE低得多。传统远程代码执行还需要想办法传payload、找可利用的调用链而认证绕过只需要构造一段看起来合法的令牌数据在不少场景下甚至只需要一个能访问n8n界面的普通网络位置就行。所以它的危害等级才会被定得那么高——它不是在某个角落获取一点权限而是直接把整个平台的信任根基掀了。对于n8n这种连接了数据库、第三方API和内部系统的工作流引擎来说认证绕过相当于给攻击者发了一张“全平台通用门票”。1.2 根因JWT信任链上的两个断点我结合n8n的代码逻辑和排查经验把CVE-2025-68668的根因拆成两个断点。第一个断点是签名算法校验不严。JWT本身支持多种签名算法最常用的是HS256和RS256HS256用同一个密钥做签名和验签属于对称算法RS256用私钥签名、公钥验签属于非对称算法。如果服务端在验签时没有强制指定算法攻击者就可以做经典的“算法混淆”攻击——把令牌的alg字段从RS256改成HS256再拿公钥当HMAC密钥来签名。服务端拿到令牌后会检查alg字段再用对应算法去验签。在一些错误实现中公钥往往可以从公开渠道获取比如OAuth的jwks端点。这样攻击者等于拿到了“免费签名密钥”想签什么身份就签什么身份。第二个断点是密钥管理边界不清。n8n在接入外部OAuth/OIDC身份源时理论上应该把第三方签发的令牌和平台内部的会话令牌分清楚。但实际代码里这两个环节存在复用和转换关系外部令牌经过解析后会被映射成内部会话令牌。在这个映射过程中如果实现者想当然地认为“反正外部令牌已经验过签了内部令牌就不需要再严格验签”就会留下漏洞缝隙。CVE-2025-68668的触发条件本质上是这两层信任没有切分干净。1.3 影响边界那么这个漏洞一旦被利用攻击者能干什么按n8n的权限模型普通成员能创建和运行工作流管理员还能管理用户、凭证和全局设置。认证绕过直接落到管理员权限的话后果主要分三块凭证泄露n8n把所有集成服务的凭据集中在平台内部管理攻击者绕过认证后可以读取这些加密存储的credentials虽然没有主密钥解不了密但配合后续的信息篡改很容易造成供应链下游的连环风险。工作流篡改与执行攻击者可以修改现有工作流的节点逻辑比如把原本发往正式物流接口的请求改成发往自己服务器的地址或者插入一个新的HTTP请求节点把数据转发出来。由于n8n的节点默认继承创建者权限这种篡改非常隐蔽。横向移动n8n经常部署在能触达数据库、消息队列、K8s API等内部资源的位置。攻击者可以利用已有的工作流连接把目标从n8n平台本身转移到背后的内部服务上。讨论影响边界时还要注意一点n8n的社区版和企业版的凭证存储机制不完全一样企业版通常接入了外部密钥管理服务解密的难度更高但认证绕过这种漏洞不依赖解密它直接站在了信任链的上游。这也是为什么我一直建议把低代码平台当作“高价值目标”来对待而不是当成一个普通的内部小工具。2. 低代码平台为何成为新的安全洼地2.1 抽象层让安全问题隐形CVE-2025-68668不是孤例。往前翻一翻低代码平台这两年披露的安全问题并不少未授权访问、SSRF、表达式注入、反序列化……只是很多企业直到被攻击才意识到自己用起来的低代码平台到底藏着多少细节。低代码平台的本质是用一层抽象界面把复杂性隐藏起来。这是它的卖点不会写代码的业务人员也能拖拖拽拽搭出自动化流程。但代价是这层抽象把安全实现也藏起来了。传统开发模式下一个后端工程师在写“解析用户传过来的Token”时至少会意识到自己在处理身份边界会去翻框架文档确认签名逻辑。而在n8n这类平台里使用者只需要拉一个“HTTP Request”节点填上URL和参数至于请求出去之后经历了什么、服务端如何验证身份全部不透明。业务团队看不懂安全团队也很难在可视化画布上做代码审计。2.2 凭证管理往往成为单点突破低代码平台另一个绕不开的问题是凭证集中化。它天然要求把数据库密码、API密钥存放在一处否则工作流无法在多个节点之间复用认证信息。这在带来便利的同时也把大量“单点”创造了出来。n8n在这方面还算做得比较规范支持用主密钥对存储的凭证做加密企业版还能对接外部密钥管理系统。但我在实际巡检中见过太多反面案例有的低代码产品把凭证明文写在配置表里有的把主密钥直接写死在环境变量里还有的用默认口令作为加解密key——这种强度基本等于没锁门。凭证管理问题在这个链条上会被放大低代码平台的凭证不是给一个人用的而是跨工作流、跨节点共享。一旦某个工作流的输入校验不严导致凭证被带出攻击者拿到的可能就是访问多个内部系统的钥匙串。安全设计上最忌讳的就是一把钥匙开所有门但低代码平台为了易用性恰恰容易做成这种模型。2.3 权限模型跟不上自动化的规模第三个软肋是权限模型。很多低代码平台把用户简单分成管理员和成员两级n8n的自托管版本在很长一段时间里也是这种扁平结构。两三台服务器、几条工作流的时候这种模型勉强够用但当企业把几十人、几百条工作流都搬上来之后扁平模型就成了一场灾难一个业务人员创建的“读取销售订单”工作流默认可以被其他成员看到甚至修改一个临时工账号可能拥有对生产数据库工作流的执行权限。权限模型的扁平化还体现在凭证共享粒度上。n8n允许把某个credential授权给多个工作流使用这是功能设计但如果没有配套的审批和最小权限原则很容易出现“谁都能往财务系统的凭证节点里塞数据”的情况。CVE-2025-68668这类认证绕过漏洞本质是在跟权限模型叠加账户体系的管涌一旦出现权限模型本身再严密也拦不住。所以权限治理不光是权限模型的事还得保证身份验证这一层地基牢固。3. n8n工作流里最容易挨打的位置3.1 Webhook一个公开入口我盘点n8n安全风险时第一关注点永远是Webhook。n8n的工作流可以配置成用Webhook触发生成一个形如https://your-n8n-host/webhook/uuid的公开URL。很多业务场景确实需要这样——比如接收电商平台的回调、接收表单提交。但问题在于默认情况下Webhook并不要求调用方提供任何鉴权信息只靠一串UUID作为访问密钥。UUID本身是乱数理论上很难猜但如果UUID在日志、文档、前端源码、历史消息记录里出现过它就不再是秘密。更麻烦的是Webhook触发的执行上下文往往继承了创建者的权限。也就是说如果一条Webhook触发的工作流里挂了数据库凭证节点攻击者拿到Webhook地址后可以直接触发这条工作流让系统替他去执行数据操作。我在巡检中见过一个真实案例客户把n8n的Webhook URL贴在了内部前端代码里后来前端代码被外部拿到攻击者就通过这个URL反复触发了一条导出客户信息的工作流整个过程连n8n后台都没碰。这个教训让我后来做加固时对所有Webhook节点一律加上签名校验或IP白名单绝不裸奔。3.2 HTTP Request节点SSRF的温床n8n的HTTP Request节点把请求能力开放给了非技术用户填一个URL平台就会替工作流发起一次HTTP请求。这个设计配合公开触发入口很容易变成SSRF服务端请求伪造的温床。攻击者如果可以通过某个输入参数影响HTTP Request节点里的目标地址就能让n8n服务器去访问内网资源——比如云平台元数据接口、内部管理页面、数据库运维端口。防范SSRF的思路其实不复杂难的是在低代码平台上落地。传统应用可以在代码层写死URL白名单、禁止重定向、过滤内网地址段但在n8n里这些限制很难通过配置界面表达清楚。我的建议是凡是允许外部输入影响目标地址的工作流一律放到受控的部署网络里跑把n8n实例放在独立子网让它只能访问需要集成的具体服务从网络层先隔离掉大部分内网探测路径。3.3 第三方凭证与供应链延伸前面提到n8n是“胶水层”这意味着它默认信任所有被串联的第三方服务。一条n8n工作流里可能同时挂着Gmail、Slack、AWS、Salesforce、GitHub的凭证。任何一个节点被攻破或配置出错都可能让攻击者借道这个凭证去访问对应的SaaS系统。这属于供应链层面的延伸——攻击者不一定要在n8n内部达到什么目的只要能读到某个第三方凭证或者能让某个工作流替他把恶意数据写入下游系统就算成功。我在给客户梳理n8n凭证清单时发现很多公司完全说不清楚n8n里存了哪些API密钥、这些密钥对应的账号是否还在用、拿到密钥的人是否都还在职。这个现状比某个具体漏洞可怕得多。凭证是供应链上的黏合剂如果黏合剂本身没有生命周期管理那么任何一个环节泄露出问题都会沿着凭证链路滚雪球。3.4 定时任务与执行链的放大效应n8n的另一大常用触发方式是定时任务。攻击者如果通过认证绕过得手不太会去改一条显而易见的对外Webhook工作流而是更倾向于在定时任务上做文章在一个每天凌晨执行的节点里加一步数据转发或者把目标地址从原来的数据库改成攻击者控制的服务器。这种改动不会立刻触发告警它会随着第二天的定时执行自动生效等到数据泄露被发现往往已经跑了好几天。这就是执行链的放大效应低代码平台的自动化让攻击者的“一次篡改”变成“反复执行”。传统攻击中入侵者要维持持续性往往需要驻留进程、频繁交互而在n8n场景下改一条定时工作流就等于在目标系统里安了一颗定时炸弹每天替你炸一次。所以修复类工作流我习惯在安全管理上额外关注“谁改过定时任务、改之前有没有审批、改完之后有没有告警”这三件事。4. 修复和加固从n8n实例到企业级部署4.1 拿到补丁之后的第一批动作先说CVE-2025-68668这类漏洞的标准处置流程。官方发布修复版本后第一步永远是升级而不是着急调配置。我见过不少团队拿到安全通告后先花一个下午研究漏洞细节然后在讨论“我们到底中没中招”版本却迟迟不升。这个心态要不得——漏洞细节研究得再透也不如先把修复版本部署上去稳当。我在处理类似问题时有一套固定的检查清单写在这里供参考升级n8n到包含修复版本的最新稳定版注意社区版和企业版的版本号策略不同企业版通常需要联系支持获取补丁。升级后立即强制重置所有用户的会话令牌。即使攻击者手里已经拿到了伪造令牌重置能让旧令牌全部失效这是最直接的止血动作。检查后台的登录日志和API访问日志重点看是否有异常来源IP、非常规时间的令牌请求、以及非工作时间的用户操作。扫描现有工作流列表确认是否有被篡改的节点。可以对比备份中工作流JSON的hash快速定位差异。轮换平台上存储的所有第三方凭证。这一步比较痛苦但认证绕过漏洞发生后不能假设攻击者只看了会话令牌——该换的密钥还是要换。4.2 用环境变量把n8n关进笼子修复之后就该讨论环境加固了。n8n提供了不少环境变量可以用来降低风险但很多人在部署时完全没注意到它们或者照着网上教程随便填了几个就再也没有看过。其实环境变量就是n8n的安全基线每一行都对应一类可以被攻击者利用的风险点。我列一份我在生产环境一定会启用的配置# 强制HTTPS避免会话令牌在明文通道上被截获 N8N_PROTOCOLhttps N8N_SSL_KEY/path/to/privkey.pem N8N_SSL_CERT/path/to/fullchain.pem # 关闭用户自助注册 N8N_USER_MANAGEMENT_DISABLEDtrue # 设置外部数据库连接避免默认SQLite文件被拖走 DB_TYPEpostgresdb DB_POSTGRESDB_HOSTyour-db-host DB_POSTGRESDB_DATABASEn8n DB_POSTGRESDB_USERn8n_app DB_POSTGRESDB_PASSWORDchange-me # 显式设置加密主密钥不用默认值 N8N_ENCRYPTION_KEY$(openssl rand -hex 32) # 设置会话JWT密钥不使用自动生成的临时值 N8N_JWT_SECRET$(openssl rand -base64 32) # 禁止工作流节点里直接访问环境变量 N8N_BLOCK_ENV_ACCESS_IN_NODEtrue这串配置的意图很明确把“默认信任”改成“逐项收紧”。N8N_PROTOCOL保证令牌只在TLS通道里传输N8N_USER_MANAGEMENT_DISABLED防止自助注册带来的账号污染显式指定N8N_JWT_SECRET则直接堵住弱密钥导致的签名伪造风险这一点和CVE-2025-68668的根因是直接对应的。还有N8N_ENCRYPTION_KEY很多人不设导致n8n每次重启都会变动加密上下文轮换和审计完全没法做所以一定显式指定。配完之后记得重启n8n服务再用一个普通用户账号登录并调用一下API确认会话签发和验签功能正常不要改完配置才发现整个平台都登不进去了。4.3 面向攻防的部署基线到了企业级部署层面安全措施不能只停留在n8n进程本身的配置上还得把整个运行环境纳入攻防视角。下面这张表是我在规划自托管n8n时的部署基线覆盖了从网络到数据的关键控制点控制点基线要求说明网络隔离n8n运行实例放独立子网仅开放必要端口降低被入侵后横向移动的风险流量入口前置Nginx/Caddy统一接管TLS和访问控制集中日志、便于拦截和限流身份边界开启OIDC/SSO对接企业身份源关闭本地弱密码和内部账号体系联动便于吊销数据存储数据库单独部署账号最小权限启用传输加密即便n8n进程失守数据不会顺带被拖走凭证保护企业版集成云KMS或其他密钥管理服务主密钥不存在n8n本地文件里日志审计所有API调用、登录、工作流变更审计日志外发为事后溯源提供证据链每条基线其实都对应一类攻防场景网络隔离针对的是SSRF和横向移动身份边界针对的就是认证绕过日志审计则保证出了问题能快速定位到是哪条工作流、哪个账号、哪个节点。技术上每一条都不算高深但把它们全部落实的企业少之又少。很多n8n是孤零零跑在业务服务器上还用着默认的SQLite和默认密钥等于把保险柜放在客厅里锁还是出厂钥匙。5. 低代码平台的安全新范式5.1 安全左移到低代码开发者过去一提到安全左移大家的惯性理解是“给开发团队配扫描工具”。但在低代码场景下被开发的工具画像变了——很多开发者是不写代码的业务人员他们不懂什么是JWT、什么是SSRF。安全左移在这里首先要把安全知识翻译成低代码世界的语言不是告诉工程师“检查签名算法”而是告诉运营人员“不要让Webhook裸奔”“不要在公开入口的高风险节点里读取内网地址”。把这些安全规则沉淀成低代码开发平台里的模板检查和审批流比单纯发安全意识报告有效得多。我在实际项目中总结出一条经验安全团队不要试图阻止业务团队使用低代码平台而是要在平台入口做分流。比如约定“涉及生产数据库凭证的工作流必须走安全评审”“所有Webhook节点默认带签名校验组件”。把规则变成平台自身的护栏而不是依赖个人自觉效果会完全不一样。5.2 凭证生命周期和最小权限凭证管理要从“静态存储”走向“动态生命周期”。最小权限原则在低代码平台里不是一句口号而是可落地的工程要求给每个第三方集成单独建凭证不要几个工作流共用一个API密钥这样单一节点出问题影响面可以被切小。凭证要对账定期导出n8n里的credentials清单和第三方平台上的账号权限做比对及时回收离职员工和废弃系统的密钥。能用短期令牌就不要用长期令牌优先使用OAuth2.0的refresh token机制把长期静态密钥的数量压到最低。高权限凭证的读取和替换要留痕至少要有审计日志。这些动作看起来琐碎但恰恰是低代码平台最稀缺的能力。平台把凭证集中起来了企业的安全团队就必须把凭证治理跟上否则集中存储只会把风险也集中起来。尤其是企业引入低代码平台的速度远远快于安全治理能力建设速度的时候一张清晰的凭证台账比任何安全产品都管用。5.3 建立低代码资产清单与风险台账很多企业不知道自己的低代码平台里到底跑了哪些工作流、连了哪些系统、谁是负责人。这个现状要改变最直接的办法是建立资产清单和风险台账。我的建议是至少记录以下字段工作流名称、触发方式、访问的外部系统、涉及的凭证ID、负责人、最后审计日期。n8n的API可以导出工作流和执行记录也可以配合页面截图和人工审核来维护。有了清单之后定期做风险评分。例如一条满足“Webhook触发包含数据库节点凭证权限是管理员”三个条件的工作流就应该被标红优先做加固。这比全面禁止低代码平台更现实也比全盘信任更安全。风险台账的价值在于让安全团队有一个可操作的优先队列——毕竟低代码平台上的工作流会越来越多没有优先级就无法真正管控。5.4 持续验证构建常态化的低代码安全检测最后聊聊持续验证。CVE-2025-68668这类漏洞的出现提醒我们低代码平台不是部署完就一劳永逸的。厂商会不断发布新版本也会不断披露新漏洞。安全团队应该把低代码平台纳入日常漏洞管理流程订阅官方安全公告、定期跟踪版本发布说明、用漏洞扫描工具对n8n实例做例行检查。我个人的做法是把n8n的版本号写进资产监测系统每当官方发布安全更新就自动派发升级工单。更进一步的持续验证是“红队自查”模拟外部攻击者的视角定期尝试未授权访问工作流、扫描开放Webhook、检查凭证存储强度。这不是为了证明系统有多脆弱而是让加固措施在真实攻击到来之前先经过一轮检验。安全不是一次性的项目它应该是一个跟着业务节奏持续运转的循环。低代码平台把自动化开发的门槛降下来了安全团队也应该把自动化的安全验证能力提上去而不是继续用人工巡检的方式追赶几百条工作流。最后说点个人体会。我经手过不少低代码平台的安全事故CVE-2025-68668只是其中比较有代表性的一例。每次处理完这类问题我都会跟团队强调同一句话不要把低代码平台当成“业务同事的玩具”。它有真实的凭证、真实的API权限、真实的定时任务它就是一台浓缩了企业多个系统入口的服务器。防护思路不妨简单一点——把它当成最核心的生产系统来对待然后再在这个基础上叠加易用性。如果你正在用n8n或者刚准备引入低代码平台先别急着搭工作流花半天时间把版本、密钥、凭证、部署位置理清楚这笔时间一定比你日后处理一次安全事故花的成本低得多。
