上个月，一个朋友发来消息。他花了一个周末，在一台便宜的云主机上把自托管n8n跑了起来，接上Stripe、Postgres、Slack和几个Google API，一切顺畅得让人心情大好。然后他问了一句让我胃一沉的话： “等等，5678端口是不是应该对整个互联网开放？” 是的，它开着。他照着某篇热门教程做的。教程让他在Docker Compose文件里写 5678:5678 ，跳过加密密钥，然后直接开始搭工作流。第一次就成功了。而这恰恰是问题所在。 它不是自动化工具，是凭证聚合器 有一件事没人说得足够大声：大家把n8n当成自动化工具，它实际上是一个凭证聚合器。一个实例可以同时握着Stripe、数据库、Slack、Google、HubSpot以及十几个其他服务的钥匙。攻破这台n8n主机，你拿到的不是一个API密钥，而是全部，一次性到手。 到了2026年，这不再是理论问题。n8n经历了一个安全上相当糟糕的年份，而且很大一部分直接砸在自托管实例上： 多个严重CVE，其中几个评级为CVSS 10.0，属于沙箱逃逸导致服务器被完全接管。 API令牌泄露，把在线实例暴露在凭证窃取风险中。 从公开产物中恢复出弱加密密钥。研究人员发现，暴露在互联网上的实例正在使用已知的弱密钥运行，也就是说，保护存储凭证的那层“加密”实际上是装饰性的。 CVE-2026-65589：UI里打了码，数据库里是明文 这里要重点说一个漏洞，因为它干净、易懂：CVE-2026-65589。 它的类型是信息泄露（CWE-532，敏感数据被写入记录）。受影响的是1.x线上的 1.123.64 之前版本，修复于1.123.64；2.x线单独修补，修复于2.29.8。所以要先确认自己跑的是哪条大版本线，再升级到对应线的修复版本。 具体发生了什么：当你在某些LLM子节点（OpenAI、Anthropic等）里把凭证作为自定义HTTP头传入时，n8n在界面上会把它们遮住，却把明文API密钥直接写进工作流执行记录。任何有权限查看或导出执行记录的已认证用户都能读到。导出的执行归档同样带着这份暴露。 严重性评级为CVSS 5.1（中危），没有已知的野外利用，也没有公开的概念验证。来源是n8n的公告GHSA-89gh-3pgc-v5h2。 再读一遍：你在界面上把密钥遮住了，感觉安全，而n8n把它以明文记下来，持久化在数据库里。这种漏洞不需要一个穿连帽衫的黑客，它只需要多一个对执行记录有读权限的用户账号。 先看清那个不安全的默认配置 不安全的Compose文件看起来人畜无害，这正是它危险的地方。几个危险信号：镜像用的是旧版本（受CVE影响）；端口写成 5678:5678 ，发布到宿主机就等于对全世界开放；没有设置N8N_ENCRYPTION_KEY；遥测开着，执行记录也不做清理。 在一台全新的Amazon Linux 2023机器上把它跑起来，然后从另一台完全不同的机器执行探测，返回的是 HTTP 200 。这意味着互联网上任何一个跑端口扫描的人都能访问它，换句话说，几小时内就会被互联网上每一个自动化扫描器找到。不要让它继续跑着，立刻拆掉。 需要说明的是，这里描述的是CVE-2026-65589这一类问题的准确性质，目的是识别错误配置并修复它，而不是去搭建一个可用的攻击。 四个修复动作 第一，打补丁，并停止发布5678端口。加固后的Compose文件里，镜像换成1.123.64，端口从 ports 改成 expose 。用expose而不是ports，是很多人会漏掉的一步：它让n8n只对Docker网络内的其他容器可达，宿主机公网接口上什么都不会落。再配合AWS安全组，5678就在两层上被关上了。 第二，把密钥放进AWS Secrets Manager。磁盘上的.env文件离泄露只差一条cat命令。所以加密密钥和数据库密码永远不进仓库，也不以明文形式留在机器上。生成它们，存进Secrets Manager，在运行时注入。N8N_ENCRYPTION_KEY比看起来更重要：没有它，n8n会派生一个默认密钥，意味着你存储的凭证实际上等于未加密。设置它，并单独备份。丢了这把密钥，你就失去了对n8n存储的所有凭证的访问权，没有恢复办法。 第三，收紧网络暴露面。除了用expose替代ports，还要用AWS安全组把5678限制在必要来源，不要对0.0.0.0/0开放。需要外部访问时，走反向代理并加上认证，而不是把端口直接暴露给全世界。 第四，关闭遥测并清理执行记录。执行记录里可能包含敏感数据，包括上面那种被明文写入的凭证。定期清理执行记录，关闭不必要的遥测，减少数据在磁盘上停留的时间和范围。 特别