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.
