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 advance notice commitment
In a shift from our original 48-hour advance notice, from May 13 2026 we are moving to a standardized bi-weekly update cadence. This means that every two weeks on Wednesday you will receive an update of all security advisories published since the last update.
As volume of findings has increased due to regular security testing, so has the number of emails we have been sending. This new cadence gives you one place to keep track of everything on a predictable schedule.
Our priority remains shipping fixes for critical vulnerabilities as soon as they are ready — here’s what you can expect:
- Bi-weekly update emails on Wednesdays with all recent advisories, affected versions, and fix information
- Cloud customers: your instances will be patched automatically — these updates are informational for your awareness
- Self-hosted customers: updates include specific version guidance so you can plan your upgrades
- Critical vulnerabilities: if something can't wait for the next cycle, we will still notify you immediately
Practical guidance for self-hosted users
Subscribe to security notifications. Make sure the right contacts are registered for n8n security emails. 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.
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 are 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.
