n8n Security: How to Check Vulnerabilities and Run It Safely

This article was checked against n8n's official documentation, website and GitHub on October 2, 2026. Vulnerability information and settings change. Before use, check the latest information through the sources at the end.

When you think about n8n security, look separately at the safety of the n8n product itself and the safety of your own operations. Vulnerabilities do get found in the product. When that happens, the level of risk depends on whether you are set up to update right away.

What determines n8n's safety: Cloud vs. self-hosted

n8n comes as n8n Cloud, run by n8n, or as a self-hosted install on your own server. The official documentation explains that with self-hosting, maintenance is the user's responsibility.

n8n Cloud

According to n8n's security page, n8n Cloud runs on Microsoft Azure, and as of October 2026 data is stored within the European Union. Stored data is encrypted with AES256, and each customer's instance is logically separated. n8n says it has third-party penetration tests done at least once a year.

The same page says customer and system data is backed up daily and replicated to another region in the same country. Server logs are centralized, and audit log history is kept for at least 12 months. Employee access to sensitive data is limited to what their job requires and reviewed quarterly.

About SOC 2

The same page explains that n8n aligns its security program with the SOC 2 framework and is audited once a year by an independent auditor. The SOC 2 report is provided to Enterprise customers, and anyone else can read the SOC 3 report. n8n's Trust Center also gathers security and compliance information.

Self-hosted

When self-hosting, n8n hashes passwords, but encrypting other data at rest is the user's responsibility. For encrypting traffic, the recommended approach is to put a reverse proxy in front of n8n and let it handle TLS.

How to check vulnerability information

Information on n8n vulnerabilities is published on the Security page of the n8n repository on GitHub. Each advisory lists the severity, affected versions and patched versions.

For example, one advisory published on September 30, 2026 concerns SQL injection in the Microsoft SQL node. Its severity is High, and the patched versions are 2.42.1 and later and 2.41.4 and later. If your n8n version is older than this range, you need to update.

n8n's update documentation recommends updating often, at least once a month. Skipping many versions at once raises the risk that something breaks during the update. It also recommends checking release notes for breaking changes before updating and trying the update in a test environment first.

If you find a vulnerability, you can report it through n8n's Vulnerability Disclosure Program.

Settings you need when self-hosting

The security chapter of the official documentation lists ways to protect a self-hosted instance, including security audits, SSL, SSO, blocking nodes, disabling the public API and redacting execution data. Here are the first ones to check.

Run a security audit

n8n has a security audit feature that finds common problems. Run n8n audit from the CLI, or trigger it through the public API or the n8n node. The audit results are split into these five reports.

• Credentials: for example, credentials not used in any workflow
• Database: for example, places where expressions are used in SQL node queries
• File system: nodes that read or write files
• Nodes: official, community and custom nodes that could be risky
• Instance: unprotected webhooks, missing security settings and outdated versions

Block nodes that could be risky

The NODES_EXCLUDE environment variable lets you block nodes you do not want used. The documentation names the Execute Command node and nodes that read or write files on disk as the first candidates to block. The Execute Command node is blocked by default.

Other settings

• SSL: handling TLS with a reverse proxy is recommended
• Public API: can be disabled if you do not use it
• Execution data redaction: hides workflow inputs and outputs. An Enterprise plan feature
• Two-factor authentication: can be set up with an authenticator app
• SSO: connect with SAML or OIDC. For self-hosting, a Business and Enterprise feature

Overall self-hosting preparation is explained in Self-hosting n8n.

Cautions when installing community nodes

Community nodes are nodes built by people outside n8n and published on npm. The official documentation explains that installing a community node from npm means adding unverified code to your instance. It lists these three risks.

• System: community nodes have full access to the machine n8n runs on and can do anything, including malicious actions
• Data: any community node you use can access the data in your workflows
• Compatibility: a new version may introduce breaking changes that stop workflows from running

If you are worried about malware, this is the most important point. n8n inspects some community nodes and shows them in the nodes panel as verified nodes. Verified nodes must meet data and system security requirements.

When self-hosting, set the N8N_COMMUNITY_PACKAGES_ENABLED environment variable to false to disable community nodes. In n8n Cloud, you can turn them off from the admin panel. Problematic community nodes can be reported to security@n8n.io.

Storing credentials

n8n stores API keys and passwords for connected services as credentials. When self-hosting, an encryption key is created automatically on first launch and saved in the .n8n folder in the home directory. n8n encrypts credentials with this key before saving them to the database.

• You can also set the encryption key yourself with the N8N_ENCRYPTION_KEY environment variable
• In queue mode, set the same key on every worker
• Self-hosted instances can also rotate the keys that encrypt credentials. Only the instance owner can do this
• Connecting to an external secrets management service is included in the Enterprise plan on the pricing page

According to the security page, in n8n Cloud credentials are loaded when a workflow runs and, by default, are not logged or exported. Unused credentials can be found in the credentials report of the security audit.

Pre-adoption checklist

Whether you use n8n in-house or adopt an AI agent built with n8n, check the following. If you are asking the builder of the AI you are adopting, you can use this list as is.

1. Is it n8n Cloud or self-hosted? If self-hosted, whose server is it on?
2. What is the current version, and who updates it and how often?
3. Who checks the vulnerability information on GitHub?
4. Does it use community nodes? If so, are they verified?
5. Whose account issued the credentials for connected services?
6. Where is the encryption key stored, and who holds it?
7. Has a security audit been run?
8. Do execution logs retain personal or confidential information?

Security for AI agents in general is covered in AI agent security, and the basics of n8n in How to use n8n.

Employee Store also lists AI employees built with n8n workflows. Buyers and sellers can message each other in a deal room created for each transaction. Confirming the checklist above with the seller in the deal room before adoption gives you peace of mind.