Start with four things that are simply true, because everything below assumes them.
n8n is a fast and genuinely good way to build. Drag a few nodes together, wire in an API, and you have something working before lunch. That is real engineering leverage, not a beginner’s illusion.
The company is not a side project. The Series C is real, and so is SAP’s strategic stake at a $5.2bn valuation.
2.0 tightened the defaults. On 15 December 2025, n8n shipped task runners on by default, Code-node isolation, and arbitrary command execution off. That landed for every operator at once.
And n8n patches fast. Advisories get disclosed and fixed promptly, which is what good maintenance looks like.
So this is not an article about whether n8n is secure. It is about a narrower question, and one that has nothing to do with the quality of their engineering: who does the standing work of keeping up?
The question underneath the question
When a security reviewer looks at a platform running production automations, the thing they need in writing is specific. Not “is this tool safe.” Rather: when a critical vulnerability is published for this software, who applies the patch, inside what window, and how do we evidence that it happened?
Three specifics. And notice that none of them are answered by how good the build is, or by how quickly upstream ships a fix. They are answered by how the software is operated.
On a self-hosted install, all three answers are your team.
That is not a gotcha. It is the deal, openly stated, and it is the same deal every self-hosted product offers. It is worth being precise about it, though, because “we self-host” and “we own the patch cycle” are the same sentence, and only one of them tends to make it into the project plan.
It is in their own paper
You do not have to take my word for the division of responsibility, which is good, because you should not.
n8n’s Master Enterprise Terms, v04.2026 put the internal cost of implementing updates on the customer, solely. The same document disclaims responsibility where an outdated version is in use. Read those two clauses together and the shape is clear: the fix is theirs to publish, the cost of applying it is yours to carry, and running behind moves the liability to your side as well.
n8n’s own self-hosting documentation lists maintenance of a self-hosted instance as “Your responsibility.” Stated plainly, in their docs. That is the honest way to document a self-hosted product, and it is also the line a security reviewer will find without any help from a competitor.
Neither of those is a criticism. They are what self-hosting means, written down by people not trying to hide it. It just means the answer to the question in the title is already in writing, and it is you.
How to read a CVE count without embarrassing yourself
Here is where most competitive content goes wrong, so let me be careful.
As of 18 August 2026, the NVD carries 129 CVE records in n8n’s own code, published between 15 December 2025 and 18 August 2026.
Now the part that has to travel with that number every single time it is used: published is not the same as affected. That count is by publication date. It is not a count of vulnerabilities in any particular version, and a record inside that window may not apply at all to the version you are running. Anyone who writes “129 CVEs in 2.0” has said something false and made the number arguable, which is the worst of both outcomes.
So what is it good for? Frequency. Not severity, and not exposure. It is a measure of how often the clock starts. That is the thing that lands on a team: not the depth of any one issue, but the arrival rate of work that cannot be scheduled around.
And that is why a single CVE is never the argument. Pick any one of them and the correct answer is “it was patched, quickly.” The pattern is the point.
The one with a deadline
One entry is worth naming, because it is a fixed historical fact rather than a moving number.
On 11 March 2026, CISA added CVE-2025-68613 (CVSS 9.9) to its Known Exploited Vulnerabilities catalogue. KEV listing carries a fourteen-day remediation deadline for federal agencies. Exploited in the wild, not theoretical, with a date attached.
Now the clause that has to come with it, volunteered rather than discovered: that catalogue holds roughly 1,670 entries. One listing out of 1,670 is not evidence that n8n is uniquely exposed, and I am not going to pretend otherwise. Plenty of widely-trusted software is in there.
What it does illustrate is the shape of the work. A catalogue entry with a deadline attached is somebody’s fortnight, and on a self-hosted install that somebody is on your team, alongside everything else they own.
How many instances that lands on
On 7 January 2026, Censys found 26,512 reachable instances running a version an advisory applied to. That figure is version-filtered, which matters: an unfiltered count of every reachable instance would repeat exactly the “published is not affected” error above, so it is not the number to use.
Patch adoption across a self-hosted install base is never instant. Some of those instances belong to teams who did not know which version they were running.
The mitigation behind a paywall
This is the part I find most interesting, because it is where the security question quietly turns into a budget question.
When a national CERT advises on hardening a workflow platform, one recommended mitigation is to limit workflow edit rights to trusted users. Sensible, proportionate, and exactly what you would want to do on hearing about a code-execution issue.
It needs a permissions construct the free edition does not have. Projects and SSO sit on a paid tier. So following the security advice means a licence purchase, and a hardening task becomes a procurement conversation partway through an incident response.
The mitigation is not technically difficult. It is just not available at the tier most teams are on when they first need it.
What actually changes on a managed platform
The honest version of this is not that vulnerabilities stop existing. Any vendor telling you that is telling you something you should not believe.
What changes is where the standing work sits, and whether you can evidence it:
- The platform is patched and monitored for you. When an advisory lands, the response is the vendor’s operational work rather than an unplanned week for whoever on your team understands production best.
- Encryption in transit and at rest is a property of the platform, not something each deployment has to be configured correctly to get.
- Audit logs stream to your SIEM, so your security team keeps visibility without operating the platform.
- Access control does not need buying. RBAC and SSO on every account means restricting who can edit a workflow is a setting, not a quote.
- The evidence is a document. SOC 1 Type 2 and SOC 2 Type 2 reports cover the platform your workflows run on, so the reviewer’s question becomes a document request.
The difference is what the first answer sounds like. Not “us, when we can get to it,” but “the vendor, under contract, and here is the report.”
Where to start
If you are somewhere in this and unsure how exposed you actually are, the useful first move is not a vendor conversation.
The production readiness checklist is 25 checks across security, compliance, agent governance, reliability, cost, and support. Free, ungated, self-serve. The five security checks are the ones a reviewer opens with.
For the shorter version of this argument, see risk and patching. For where it meets the cost question, operational overhead.