内容来源：https://blog.n8n.io/how-n8n-handles-vulnerability-disclosure-and-why-we-do-it-this-way/

内容总结：

随着n8n的快速发展，其代码库受到安全社区越来越多的关注与审查。这实际上是一个积极现象。近期我们发布了多项安全通告，用户也自然产生了一些疑问：漏洞公开前我能获得多长的预警时间？为何不能给予更长的修复窗口？在开源模式下，安全漏洞的披露流程如何运作？

我们希望通过公开透明的沟通来解答这些疑问，因为清晰的安全披露流程比封闭的流程更能建立用户信任。

开源模式下的安全挑战
n8n坚持代码开源，这使社区能够审查、扩展和贡献平台功能，但也带来了闭源厂商不会面对的特殊安全挑战。闭源软件的安全更新隐藏在编译后的文件中，攻击者需要逆向工程才能分析漏洞，这为用户争取了修复时间。而对于开源代码库，安全补丁一旦在代码库中可见，任何人（包括潜在攻击者）都能通过分析代码变更直接定位漏洞并快速制作攻击工具。补丁本身可能成为攻击未更新实例的“路线图”。这不是理论风险，现实中攻击者确实会通过“补丁比对”技术，在关键漏洞修复公开后的数小时内开发出利用程序。

因此，我们必须在代码开放与防止攻击者抢占先机之间找到平衡。

48小时提前预警承诺
对于“高危”或“严重”级别的安全通告，我们会在公开发布前至少48小时，通知n8n Cloud用户及已注册的自托管用户。请注意，这是关于更新即将发布的预警，而非提前提供补丁。

我们理解部分用户认为48小时不足，尤其对于那些拥有严格变更管理流程、测试环境和维护窗口的组织。理想情况下我们希望提供更长时间，但在当前模式下，我们在同一天发布已修复的版本和公开安全通告，这意味着不存在“补丁已公开但通告未发布”的有效缓冲期。

我们的核心优先级是：一旦关键漏洞修复准备就绪就立即发布，避免因追求更长的预警期而延迟修复。在开源项目中，我们主要的风险管理集中在发布日前：在修复完成至公开期间，我们会在私有分支中进行开发和测试，仅在发布修复版本和通告时同步公开代码变更（即“协调公开披露”或“发布时合并”模式）。

48小时预警期是我们权衡后的平衡点：既为有准备的组织留出调度人员和维护窗口的时间，又避免因预警流程拖慢关键修复的发布速度。

给自托管用户的实用建议
为帮助您有效利用这48小时预警窗口，我们建议：

1. 订阅安全通知：确保相关联系人已注册接收n8n安全邮件，以便及时接收预警。
2. 建立快速更新通道：为安全补丁制定加急更新流程，即使很少使用，有备无患。
3. 尽可能自动化部署：实现自动或一键式拉取和部署新版本，可极大缩短修复时间。
4. 实施分层防御：通过限制工作流编辑权限、强化部署环境等措施，降低各类漏洞的暴露风险，减少对快速补丁的绝对依赖。

漏洞报告增多恰恰说明模式有效
近期安全通告数量增加可能让人产生“n8n存在安全问题”的疑虑，但我们认为事实恰恰相反。n8n代码库并未突然变得不安全，而是随着项目成长（GitHub星标超17万，被数万组织采用），吸引了更多安全研究人员和机构的审查。这正是开源安全模式的应有之义：更多关注意味着更多漏洞被发现和修复，长期来看产品将更加安全。世界上安全防护最完善的软件（如Linux、Chromium、PostgreSQL）也拥有大量的已公开漏洞记录，这正体现了其透明度、广泛审查和积极修复的承诺。

我们欢迎这种审查，每一份报告都在让n8n对用户更加安全。

我们的主动安全投入
除了社区报告，我们也在大力加强自身安全能力：

• 招聘专职安全工程师，将主动漏洞发现融入开发流程。
• 对高风险组件（如表达式评估、凭证处理、多租户隔离）进行内部安全审查。
• 投资架构级改进（如强化表达式评估安全），从根源消除整类漏洞。
• 增强自动化安全测试，在代码合并前捕获常见漏洞模式，并持续扫描供应链风险。

我们的目标不仅是快速响应已报告问题，更要在问题被发现前就将其解决，最终使外部漏洞报告成为例外而非主要发现渠道。

如需了解更多安全实践，请访问n8n安全页面。有关合规文档和政策，请查阅我们的信任门户。如对具体安全通告有疑问，或怀疑n8n生态中存在漏洞及安全事件，请联系security@n8n.io。

中文翻译：

随着n8n的发展，我们的代码库也受到安全社区越来越多的审视。这是一件好事。过去几个月，我们发布了多份安全公告，用户随之也产生了一些疑问：漏洞公布前我能获得多少提前通知时间？为什么不能给我更长的准备时间？当源代码公开时，这一切又是如何运作的？

我们希望公开回答这些问题，因为我们相信清晰透明的披露流程比隐秘的流程更能建立信任。

开源安全的核心矛盾

n8n的源代码是公开的。这是我们核心理念的基石——它让社区能够审查、扩展并为平台做出贡献。但这同时也带来了闭源厂商不会面临的特殊挑战。

当闭源厂商发布安全更新时，修复内容隐藏在编译后的二进制文件或打包资源中。攻击者需要逆向工程分析补丁才能了解修复了什么。这个过程需要时间和技能，为用户提供了应用更新的时间窗口。

但对于开放的代码库，情况则不同。安全修复在代码仓库中可见的那一刻，任何人——包括恶意攻击者——都可以查看提交记录，了解漏洞所在，并制作攻击程序。补丁本身就成了攻击者针对尚未更新实例的路线图。

这并非理论上的担忧。补丁差异分析（Patch-diffing）正是通过分析公开的代码变更来推导攻击手段的做法。这是现实世界中攻击者有据可查的常用技术。对于严重漏洞，从修复代码可见到野外出现攻击程序的时间间隔可能以小时而非天数计算。

这就是我们必须应对的根本矛盾：既要保持代码开放，又不能给攻击者领先于用户的先机。

我们48小时提前通知的承诺

对于评级为"高危"或"严重"的公告，我们会在公告发布前至少48小时通知n8n Cloud用户和已注册的自托管用户。这是关于即将发布更新的提前通知——而非提前获取补丁的权限。

我们知道有些用户反馈48小时不够。我们理解这种担忧，特别是对于拥有变更管理流程、预发布环境和维护窗口的组织而言。在理想情况下，我们希望给所有人一周或更长时间。

在我们目前的模式中，我们在同一天发布已修复的版本和公开公告。这意味着不存在修复已公开而公告未发布的实质窗口期。

真正的首要任务是：关键漏洞的修复一旦准备就绪就立即发布，避免因追求更长的通知周期而被迫延迟发布。

在开源项目中，我们管理的主要风险在发布日之前：一旦修复完成，我们会保密至发布时刻，以防其成为攻击者的路线图。实际上，这意味着在私有分支中开发和测试关键修复，仅在发布修复版本和公告时才公开代码变更（有时称为"协调公开披露"或"发布时合并"）。

48小时窗口期是我们权衡后的最佳平衡点：既为有准备的组织留出安排人员和维护窗口的时间，又避免让提前通知成为阻碍关键修复发布的绊脚石。

给自托管用户的实用建议

我们希望帮助您让48小时窗口期适用于您的组织。以下是一些具体步骤：

• 订阅安全通知：确保正确的联系人已注册接收n8n安全邮件，以便及时收到48小时提前通知。如需更改联系人或订阅，请联系n8n支持，或在GitHub或我们的社区论坛操作。
• 准备快速更新通道：对于关键安全更新，您标准的月度维护窗口可能不够快。我们建议为安全补丁制定有文档记录的快速处理流程。即使很少使用，提前准备能让48小时从"紧张"变为"充裕"。
• 尽可能自动化：应用安全补丁最快的方式是完全无需人工干预。如果您的部署流程能自动或仅需一步审批即可拉取和部署新n8n版本，您将处于有利地位。
• 分层防御：正如我们在表达式沙箱公告中指出的，将工作流编辑权限限制给受信任用户，并强化部署环境，可以减少您面临多类漏洞的风险，无论您打补丁的速度有多快。

报告增多为何是模式有效的标志

如果您一直关注我们的安全公告，可能会看着近期的发布频率想："n8n存在安全问题。"我们理解这种反应，但我们实际上持相反观点。

n8n已公开可用多年。代码库的安全性并未突然降低。改变的是它所受到的关注度。随着n8n的发展——如今已拥有超过17万GitHub星标，被数万组织采用——它自然吸引了更多来自独立安全研究员和安全公司的审视。

这正是开源安全应有的运作方式。更多眼睛审视代码意味着发现更多漏洞，更多漏洞被发现意味着更多漏洞被修复，更多漏洞被修复意味着产品随着时间的推移更加安全。收到漏洞报告很少的代码库并不代表安全，更多时候是意味着无人关注。

世界上一些安全性最佳的软件（如Linux、Chromium、PostgreSQL）也拥有最长的已公布CVE列表。这不是因为它们不安全，而是因为它们透明、受到广泛审视，并致力于修复和披露发现的问题。

我们欢迎这种审视。我们收到的每一份报告，无论报告者的动机如何，都让n8n对我们的用户更加安全。

我们自身的主动安全工作

社区报告只是拼图的一部分。我们也在大力投入自身的安全能力建设：

• 我们正在积极招聘专业安全工程人才，将主动漏洞发现融入开发流程，而非仅仅依赖外部报告。
• 我们的工程团队对高风险组件进行内部安全审查，特别关注表达式求值、凭据处理、多租户隔离等领域。
• 我们正投资于架构改进（例如更好地保护表达式求值），以消除整类漏洞，而非逐个修补。
• 我们正在改进自动化安全测试，以便在代码合并前捕获常见漏洞模式。同时持续扫描供应链中可能影响n8n的漏洞。

我们的目标不仅是在问题被报告时快速响应，更是在问题被报告之前就发现并修复它们。我们正在构建一种安全态势，使外部报告成为例外，而非主要的发现机制。

有关n8n安全实践的更多信息，请访问 https://n8n.io/security。合规文档和政策请访问我们的信任门户（例如SOC2报告）。对于具体公告的疑问，或如果您怀疑n8n生态系统中存在漏洞或安全事件，请联系 security@n8n.io。

英文来源：

As n8n grows, so does the scrutiny our codebase receives from the security community. That is a good thing. In the past months we have published many security advisories, and with that comes natural questions from our users: How much notice will I get before a vulnerability is published? Why can't I get more time? And how does all of this work when the source code is publicly available?
We want to answer these questions openly, because we believe that a well-understood disclosure process builds more trust than a secretive one.
The tension at the heart of open-access security
n8n's source code is publicly available. This is core to who we are — it enables our community to inspect, extend, and contribute to the platform. But it also creates a specific challenge for security patches that closed-source vendors do not face.
When a closed-source vendor ships a security update, the fix is hidden inside a compiled binary or bundled assets. Attackers have to reverse-engineer the patch to figure out what was fixed. That process takes time and skill, giving users a window to apply the update.
With an open codebase, the calculus is different. The moment a security fix is visible in the repository, anyone — including malicious actors — can read the commit, understand what was vulnerable, and craft an exploit. The patch itself becomes a roadmap for attackers targeting instances that have not yet updated.
This is not a theoretical concern. Patch-diffing is the practice of analyzing public code changes to derive exploits. It’s a well-documented technique used by attackers in the real world. For critical vulnerabilities, the time between a fix becoming visible and an exploit appearing in the wild can be measured in hours, not days.
This is the fundamental tension we have to manage: being open with our code while not giving attackers a head start over our users.
Our 48-hour advance notice commitment
For advisories rated High or Critical, we notify n8n Cloud and registered self-hosted users at least 48 hours before the advisory is published. This is advance notice that an update is coming — not early access to a patch.
We know some users have told us that 48 hours is not enough. We understand that concern, especially for organizations with change management processes, staging environments, and maintenance windows. In an ideal world, we would give everyone a week or more.
In our current model, we publish the patched release and the public advisory on the same day. That means there is no meaningful window where the fix is public but the advisory is not.
The real priority is shipping a fix for a critical vulnerability as soon as it is ready and avoiding a notice policy that forces us to delay a release just to accommodate a longer notice period.
In an open-access project, the main risk we manage is before release day: once a fix exists, we keep it private until publication so it does not become a roadmap for attackers. In practice, that means developing and testing critical fixes in a private fork and only making the code changes public when we publish the patched release and advisory (sometimes called "coordinated public disclosure" or "merge-at-publish").
Our 48-hour window is our best judgment of the balance point: enough time for prepared organizations to schedule people and a maintenance window, without turning advance notice into a blocker that slows down critical fixes.
Practical guidance for self-hosted users
We want to help you make the 48-hour window work for your organization. Here are some concrete steps:
Subscribe to security notifications. Make sure the right contacts are registered for n8n security emails so the 48-hour advance notice reaches them in time. Reach out to n8n support or to change contacts or subscribe in Github or our community forum.
Prepare an expedited update path. For critical security updates, your standard monthly maintenance window may not be fast enough. We recommend having a documented fast-track process for security patches. Even if it is rarely used, having it ready makes the difference between 48 hours being tight and 48 hours being plenty.
Automate where possible. The fastest way to apply security patches is to not require manual intervention at all. If your deployment pipeline can pull and deploy new n8n versions automatically or with a single approval step, you are in a strong position.
Layer your defenses. As we noted in our expression sandbox advisory, restricting workflow editing permissions to trusted users and hardening your deployment environment reduces your exposure to many vulnerability classes regardless of how quickly you can patch.
Why the increase in reports is a sign the model is working
If you have been following our security advisories, you might look at the recent pace and think: "n8n has a security problem." We understand that reaction, but we would actually argue the opposite.
n8n has been publicly available for years. The codebase has not suddenly become less secure. What has changed is the amount of attention it receives. As n8n has grown — now with over 170,000 GitHub stars and adoption by tens of thousands of organizations — it has naturally attracted more scrutiny from security researchers, both independent and from security firms.
This is exactly how open-access security is supposed to work. More eyes on the code means more bugs found, more bugs found means more bugs fixed, and more bugs fixed means a more secure product over time. A codebase that receives few vulnerability reports is not a sign of security. It is more often a sign that nobody is looking.
Some of the best-secured software in the world (Linux, Chromium, PostgreSQL) also has the longest lists of published CVEs. That is not because they are insecure. It is because they are transparent, widely scrutinized, and committed to fixing and disclosing what is found.
We welcome this scrutiny. Every report we receive, regardless of the reporter's motivations, makes n8n safer for our users.
Our own proactive security work
Community reports are one piece of the puzzle. We are also investing heavily in our own security capabilities:
We are actively hiring dedicated security engineering expertise to build proactive vulnerability discovery into our development process rather than relying solely on external reports.
Our engineering team conducts internal security reviews of high-risk components, with particular focus on areas like expression evaluation, credential handling, and multi-tenant isolation.
We are investing in architectural changes (e.g., to better secure expression evaluations) that eliminate entire classes of vulnerabilities rather than patching individual instances.
We are improving our automated security testing to catch common vulnerability patterns before code is merged. And we continuously scanning our supply chain for vulnerabilities that might affect n8n.
Our goal is not just to respond quickly when issues are reported, but to find and fix them before they are reported at all. We are building toward a security posture where external reports are the exception rather than the primary discovery mechanism.
For more information on security practices at n8n visit https://n8n.io/security. For compliance documentation and policies visit our trust portal (e.g., SOC2 reports). For questions on concrete advisories or in case you suspect a vulnerability or security incident in the n8n ecosystem please contact security@n8n.io.