Is n8n Safe? n8n Security, Recent Vulnerabilities, Hardening and the HIPAA and GDPR Questions

Is n8n safe? It can be, with discipline. n8n runs a SOC 2-aligned security programme with an annual independent audit, offers a GDPR Data Processing Agreement for n8n Cloud and documents a detailed hardening guide for self-hosters. It has also had serious vulnerabilities: four advisories rated critical between December 2025 and January 2026, one of which (CVE-2025-68613) CISA added to its Known Exploited Vulnerabilities catalog, and a steady stream of fixes through 2026. Whether n8n is safe for you depends mostly on how fast you patch and who can edit workflows.

Search interest in “n8n security” comes from two directions. Engineers who already run n8n want to know which versions are affected by the latest advisory. Security and compliance teams want to know whether a tool that holds credentials for half the company’s SaaS estate belongs in a regulated environment. This article tries to answer both without exaggeration.

Every advisory, version and date below was read from GitHub’s advisory database for the n8n-io/n8n repository, the US National Vulnerability Database or CISA’s catalog on 29 October 2026 (verified October 2026). Statements about n8n’s controls come from its security page, trust center and documentation. Treat n8n’s advisories as authoritative for your own version; this page will age. If you are weighing cost as well as risk, our companion guide to n8n plans, licences and enterprise pricing covers which tier unlocks which control.

Why an automation platform deserves extra scrutiny

A workflow automation tool concentrates risk in a way few applications do. An n8n instance typically stores OAuth tokens and API keys for CRM, email, finance, cloud storage and databases. It accepts inbound webhooks from the internet. It lets users write expressions and code that run on the server. And it increasingly runs AI agents that decide which of those connected tools to call.

None of that is unique to n8n; Zapier, Make, Power Automate and every agent platform face the same shape of problem. The point is that a single flaw in expression evaluation, file handling or webhook processing can expose every credential in the instance. That is why the advisories below matter more than a comparable bug in, say, a note-taking app.

How n8n describes its own security

n8n’s security page and trust center set out the following, as of 29 October 2026.

Compliance. n8n says it aligns its security programme to SOC 2 and undergoes annual audits by an independent auditor. The SOC 2 report is available to enterprise customers; a SOC 3 report is downloadable for everyone. The trust center, run on SafeBase, lists GDPR, SOC 2 Type 2 and SOC 3, along with a penetration test report and Consensus Assessment Initiative Questionnaires (CAIQ) for cloud and for self-hosted customers.

n8n Cloud. Cloud runs on Microsoft Azure with data hosted in the European Union; the pricing FAQ specifies Frankfurt. n8n says credentials and the instance database sit on disks encrypted at rest with AES-256, backups are encrypted and replicated to another region in the same country, traffic is encrypted in transit, and customer instances are logically isolated.

Testing. n8n states that it runs third-party vulnerability scans of production at least every 90 days and third-party penetration tests at least once a year, uses static application security testing in its build pipeline, and operates intrusion detection.

Self-hosted. Here n8n is explicit that responsibility shifts. Passwords are salted and hashed, but self-hosters must set up a reverse proxy to terminate TLS and must handle encryption at rest themselves.

Access. Users sign in with a username and password, with optional MFA. SSO through SAML or OIDC, and LDAP, require a paid plan (self-hosted Business or Enterprise, or Cloud Enterprise according to n8n’s SSO documentation). n8n reports vulnerabilities through a public disclosure programme linked from its repository’s security policy.

n8n security vulnerabilities: the critical advisories

Four advisories rated critical by GitHub stand out. Each is listed with its identifiers, publication date in GitHub’s advisory database, score and the affected and fixed versions exactly as the advisory gives them.

The NVD entry for CVE-2026-21858 explains the mechanism in plain terms: certain form-based workflows let an attacker read files on the underlying server, a vulnerable workflow could expose this to an unauthenticated remote attacker, and the exposure “may enable further compromise depending on deployment configuration and workflow usage”.

CVE-2025-68613 carries the strongest signal. CISA added it to the Known Exploited Vulnerabilities catalog on 11 March 2026, which means CISA had evidence of exploitation in the wild, and set a remediation due date of 25 March 2026 for US federal agencies. If you run any n8n release older than 1.120.4, treat that as an incident-response question, not only a patching one.

The 2026 pattern: frequent, mostly node-level fixes

After January the advisories kept coming, at a different scale. The 100 most recent advisories in n8n’s repository were all published between 5 August and 28 October 2026, usually in batches every two weeks; twelve appeared on 28 October alone. GitHub rates every one of those 100 as high or medium, in roughly equal numbers. They fall into a few recurring groups:

• Sandbox and expression isolation. For example GHSA-gx3v-3x3v-f8r5, “Insufficient Isolation in Workflow Expression Evaluation” (28 October; fixed in 1.123.89, 2.45.5, 2.46.1 and 3.0.1), and GHSA-9p7v-45m2-wxgj, where deprecated Code nodes allowed code execution in the main process (fixed in 2.42.6, 2.43.3 and 3.0.1).
• Credential exposure between users. Several advisories describe shared-workflow editors reaching credentials they did not own through sub-workflows or agent tool parameters, such as GHSA-x25p-9mr6-cwgp (30 September; fixed in 2.41.4 and 2.42.1).
• Injection in individual nodes. SQL, NoSQL, PostgREST and OData injection in nodes for Microsoft SQL, MongoDB, Supabase, Oracle and others.
• Approval and authentication flows. GHSA-728h-pmr2-7cgh, a Send-and-Wait signature bypass that allowed unauthenticated approval of waiting executions (fixed in 2.41.4 and 2.42.1), and CVE-2026-86084, where disabled OIDC SSO endpoints remained active and issued valid sessions (fixed in 1.123.76, 2.37.7 and 2.38.2).

Two readings of this list are both fair. On one side, n8n is finding, disclosing and fixing issues in the open, across several supported release lines at once, which is what a responsible vendor should do. On the other, a large node library and a powerful expression engine give a large attack surface, and an instance that falls a few weeks behind accumulates real exposure. Neither reading supports the claim that n8n is uniquely unsafe; both support treating it as tier-one infrastructure for patch management.

Hardening a self-hosted n8n instance

n8n’s own documentation provides most of what a hardening baseline needs. The checklist below follows it.

1. Patch on a schedule measured in days. Subscribe to the repository’s security advisories and n8n’s security update mailing list, and test upgrades in a staging instance so production can follow quickly.
2. Run the built-in audit. n8n audit (or the /audit API endpoint, or the n8n node) produces five risk reports: unused credentials, SQL expressions in database nodes, nodes that touch the file system, risky official, community and custom nodes, and instance issues such as unprotected webhooks or an outdated version.
3. Block dangerous nodes. Use NODES_EXCLUDE to stop n8n loading nodes such as Execute Command and Read/Write Files from Disk; n8n notes that Execute Command is already blocked by default.
4. Enable SSRF protection. From n8n 2.12.0, N8N_SSRF_PROTECTION_ENABLED=true checks outbound requests from user-controllable nodes against blocked ranges that include private, loopback and link-local addresses. n8n is clear that this supplements network firewalls rather than replacing them.
5. Isolate code execution. Run task runners in external mode as separate containers, use the distroless image, run as the unprivileged nobody user, mount a read-only root filesystem and apply an AppArmor profile that denies reads of /proc/*/environ.
6. Terminate TLS and encrypt at rest. Put a reverse proxy in front of n8n, store the database on encrypted volumes, set your own encryption key and rotate it using n8n’s key-rotation guidance.
7. Limit who can build. Treat workflow-editing rights like production deployment rights. Restrict community node installation, disable the public API if nobody uses it, and require 2FA.
8. Reduce stored data. Prune execution data automatically and, on Enterprise, redact execution data so payloads containing personal or regulated data are not kept in plain view.
9. Use a secrets manager. External secret stores such as HashiCorp Vault keep credentials out of n8n’s database, though n8n’s pricing page lists this as an Enterprise feature.
10. Ship logs out. Standard logging is available in every edition; streaming logs and audit events to a SIEM is an Enterprise feature.

Steps 8 to 10 show a practical point: several controls that a regulated security team will expect, including audit logging, log streaming, external secrets, execution redaction and instance-wide 2FA enforcement, sit in n8n’s Enterprise tier.

Questions to ask before n8n handles sensitive data

A hardening list covers your side. These questions cover n8n’s side, and the answers belong in your vendor risk file.

• Which release lines get security fixes, and for how long? Recent advisories list fixes on the 1.123.x line, several 2.x lines and 3.0.1 at the same time. Find out which line you should standardise on and when it stops receiving patches.
• How will you hear about a critical fix? Decide who watches the repository’s advisories and n8n’s security mailing list, and what your target time to patch is for a critical rating.
• What does the SOC 2 report cover? Ask for the Type 2 report under NDA and check that its scope and period include the n8n Cloud services you will use.
• Who at n8n can see your data on Cloud? n8n’s security page describes least-privilege access with quarterly reviews; ask how support access to a customer instance is granted and logged.
• Where do AI steps send data? An AI Agent node calls whichever model provider you configure. Your data-protection assessment has to cover that provider as well as n8n.
• What is the exit path? Agree in advance how workflows, credentials, execution history and audit logs would move to another system if you leave.

None of these questions is unusual. They are the same ones a careful buyer should put to any automation or agent vendor, including us.

n8n HIPAA and GDPR: what n8n actually publishes

GDPR. n8n’s privacy documentation says that for n8n Cloud it is both a controller and a processor, that its Data Processing Agreement includes the European Commission’s Standard Contractual Clauses, and that its sub-processor list is public. For self-hosted n8n, it says it is neither controller nor processor of the data in your workflows, so deletion requests are yours to handle; it recommends setting EXECUTIONS_DATA_MAX_AGE so execution data is pruned every few days.

Telemetry deserves a separate check in a GDPR review. n8n says it collects pseudonymous usage events, error diagnostics, truncated IP addresses and the registrable domain of services you call, but not workflow data or credential contents. Telemetry is on by default; self-hosters switch it off with N8N_DIAGNOSTICS_ENABLED=false and related variables. On a paid licence, usage counts and the licence identifier keep being reported, because billing depends on them.

HIPAA. n8n’s trust center lists GDPR, SOC 2 Type 2 and SOC 3. It does not list HIPAA as a compliance item. The CAIQ self-assessments describe their questions as aligned with frameworks including HIPAA, which is a questionnaire format, not an attestation. We found no published statement from n8n about signing business associate agreements. If protected health information will pass through n8n Cloud, get n8n’s position on a BAA in writing before any data flows. If you self-host, the HIPAA Security Rule safeguards are your organisation’s to implement and document.

SOC 2 for your own audit. n8n’s SOC 2 Type 2 report covers n8n as a vendor. A self-hosted instance inherits none of it; your auditors will test your deployment, access controls and change management.

Where a governed agent platform differs

n8n is a general automation engine that has added AI agents. A governed agent platform starts from the agent and the data it touches. The practical differences are in where control sits:

• Tool access by role. Instead of any workflow editor wiring any credential into any node, each agent receives specific tools, and each role is granted specific agents.
• Permission-aware retrieval. When an agent reads documents, it should see only what the requesting user may see in the source system.
• Human approval as a platform primitive. Sending, filing or changing records waits for a named approver, and the approval is recorded with the action.
• Audit by default. Every model call and tool call is logged with user, model, inputs, sources and outputs, without a separate enterprise tier for the audit trail.

No platform is immune to vulnerabilities, including ours, so the same patching discipline applies. The difference is how much an attacker or a careless editor can reach when something goes wrong. Our AI agent governance resource sets out the control model, and the article on sandboxing AI agents that execute code covers isolation patterns that apply to any platform.

How VDF AI fits

VDF AI is an enterprise AI agent platform deployed on-premises, in a private cloud or air-gapped, with VDF AI Cloud as a hosted alternative. Agent Hub builds agents without code and grants tools from an MCP registry per role; the MCP gateway controls which servers and tools agents may call. Approval steps hold high-impact actions for a person, Private RAG keeps source-system permissions, and audit logs capture the user, model, sources and tool calls for each interaction, which supports EU AI Act record-keeping.

On-premises installations use native Microsoft Entra ID sign-in, with other identity providers connected through an SSO-aware reverse proxy; role-based access control is on every plan. VDF AI holds no SOC 2, ISO 27001 or HIPAA certification of its own, so a regulated deployment is assessed under your controls like any self-hosted system. For a side-by-side view, see our VDF AI vs n8n comparison.