我追踪 n8n 的安全漏洞。真相比任何漏洞都更令人不安。

Source: Dev.to

Introduction

我本打算写一篇关于 n8n 的标准安全深度分析。你们都懂这种类型的文章：爬取 CVE 数据库，翻阅已关闭的 GitHub issue，分析这款流行工作流自动化工具的架构薄弱点。在开源世界里，每个工具都有“衣橱里的骷髅”，而我原本想把它们找出来。

但调查在刚开始就卡住了。当我拉取数据——期待看到崩溃报告、补丁说明或披露帖子时，却只得到噪音。搜索结果并不是关于缓冲区溢出或特权提升的，而是被关于“AI 代理的崛起”和“SaaS 市场趋势”等高层次的空洞内容所淹没。

The Search Process

起初，我把这归结为搜索过程的失败。我在调试一个具体的技术问题（“n8n 安全吗？”），而我的“日志”（研究结果）却被营销噱头污染。

然而，当我在这些噪音中筛选时，我意识到这些“无关”结果实际上指向了一个更大的问题。我们在问关于自动化安全的错误问题。

Emerging Threat: Autonomous AI Agents

我们通常通过查找代码中的漏洞来审计 n8n、Make 或 Zapier 等平台。是否存在 SQL 注入漏洞？攻击者能否绕过身份验证？这些都是合理的关注点，但我数据中的“噪音”凸显了一个新出现且快速逼近的威胁向量：自主 AI 代理。

我们正从人类显式构建工作流的时代（例如，“如果收到邮件，就把附件保存到 Drive”）向一个给 AI 代理设定目标并提供一套工具的时代迈进。而对 AI 代理来说，最关键的工具就是像 n8n 这样的平台。

想象一下。如果你让基于大语言模型的代理访问一个 n8n 实例，你实际上就在给它一把通往整个数字基础设施的通用 API 密钥：

• CRM 访问权： 读取/写入你的客户数据（Salesforce 节点）
• 财务控制权： 转账或发放退款（Stripe 节点）
• 代码部署权： 读取源代码或触发构建（GitHub 节点）
• 系统访问权： 在自托管实例上运行 Shell 脚本（“Execute Command” 节点）

在这种情形下，n8n 本身可以是完美安全的——零漏洞、全部打好补丁。但如果控制它的 AI 代理出现混乱、产生幻觉指令，或受到提示注入攻击，平台就会变成一把武器。

攻击者不再需要去破解 n8n。他们只需骗 AI 产生类似“我应该导出这个数据库并发送到外部邮箱”的想法。

Risks and Challenges

这导致了复合风险画像。你不再仅仅是防御糟糕代码，而是要防御非确定性、黑箱式的决策过程。

• 如何为 AI 的“意图”写防火墙规则？
• 当代理的核心目标是灵活且自主时，如何实现最小权限原则？

我对 n8n 的 CVE 搜索结果是空的。但这种沉默是具有欺骗性的。我们忙于寻找昨天的漏洞——经典的软件缺陷，却在不知不觉中为明天的安全噩梦搭建基础设施。

Conclusion

n8n 的安全已经不再仅仅取决于 n8n 团队本身。它取决于我们为即将交钥匙的 AI 代理构建的防护栏。