Guide

n8n security: risks, known vulnerabilities and hardening

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

n8n is an attractive target because a single instance stores credentials for many other systems, can execute code and is reachable from the internet through webhooks. Running n8n securely means keeping it up to date, keeping the editor off the public internet, protecting accounts with two-factor authentication, authenticating every webhook, blocking code and command nodes you do not need and storing the encryption key separately. Germany's federal cyber security agency, the BSI, has published several advisories on n8n since January 2026, one of them rated critical.

Why n8n is worth attacking

n8n connects applications and automates the work that flows between them. To do that, it needs credentials: API keys, OAuth tokens, database passwords, SMTP logins. To an attacker, an n8n instance is therefore less a single system than a collection point for access to many systems. Three properties make it especially attractive:

• It holds credentials. n8n stores credentials encrypted in its database. Anyone who controls the instance can use them in their own workflows without ever seeing them in plain text.
• It runs code. The Code node, expressions in fields and, if enabled, the Execute Command node all run on the server. A flaw in that execution path quickly turns into a full host compromise.
• It is reachable from outside. Webhooks, forms and chat triggers are public by design so that other services can start workflows. Every one of these endpoints is a way in.

Then there is the execution data. Depending on its settings, n8n keeps the data of every run: customer records, job applications, invoices, chat transcripts. Losing that data often means losing personal data, which can trigger a breach notification duty under Article 33 GDPR. Whether it does in a given case is a legal question, and this article is not legal advice.

Which n8n vulnerabilities are known

n8n publishes vulnerabilities as security advisories in its GitHub repository. Since 2025 well over a hundred advisories have appeared there, more than twenty of them rated critical (as of 28 Oct 2026). The volume partly reflects a vendor that discloses and fixes issues. For operators, though, the takeaway is simple: an n8n instance that has not been updated for a few months very likely has known flaws open.

What the BSI has published on n8n

Yes, the BSI has issued advisories on n8n through the CERT-Bund warning and information service (WID). The first, WID-SEC-W-2026-0040 from January 2026, is rated critical. It covers three vulnerabilities, including CVE-2026-21858 and CVE-2025-68613, and states that an attacker can execute arbitrary code, disclose confidential information and bypass security controls. Further advisories rated high followed in January, February, March and May 2026, among others (WID-SEC-W-2026-0144, -0318, -0532, -0877 and -1519). The advisories are publicly available on the CERT-Bund portal.

Selected vulnerabilities

The selection below shows the range, from flaws exploitable without logging in to flaws that require an authenticated account. Version ranges are taken from the vendor advisories and the NVD.

The table carries two lessons. First, for several of these flaws, one authenticated account or one stolen password is enough to take over the server. If you do not fully trust every user of your instance, you need to restrict roles and nodes. Second, fixes are shipped to older release lines as well. As of 28 Oct 2026, 2.45.5 is the stable release and the 1.123.x line still receives security fixes. Always check the current advisories for your instance rather than relying on a version number from an article.

Common misconfigurations

Many successful attacks need no new vulnerability, just an open door in day-to-day operations. The following issues show up often in self-hosted installations. All settings named here come from the official n8n documentation.

The editor is exposed to the internet

The n8n web interface is an administration tool. It does not have to be reachable by the whole world just because your webhooks are. Put the editor behind a VPN, access control on the reverse proxy or an IP allowlist, and serve it over HTTPS only. Webhook paths can be exposed separately at the proxy. N8N_SECURE_COOKIE makes sure session cookies are only sent over HTTPS. It defaults to true and should stay that way.

A weak owner account

The owner account controls the instance, every workflow and every credential. A guessable or reused password is all it takes to exploit the flaws in the table above. Turn on two-factor authentication for every account. n8n supports it through an authenticator app, and N8N_MFA_ENFORCED_ENABLED enforces it for all users. Where available, single sign-on via SAML or OIDC beats local passwords. Grant roles on a need-to-have basis: someone who only views workflows does not need edit rights.

Webhooks without authentication

An unprotected webhook starts the workflow for anyone who knows or guesses the URL. The n8n Webhook node offers several methods to prevent that: Basic Auth, Header Auth, JWT Auth and authentication with n8n user accounts. You can also set an IP allowlist, in which case requests from other addresses get a 403 response. Then look at what the workflow does with incoming data. If a request field ends up unchecked in a database query, a file path or a command, authentication protects you from strangers but not from manipulated input.

The Code node and the Execute Command node

The Execute Command node runs commands directly on the server. Since n8n 2.0, it and the Local File Trigger are blocked by default, controlled through NODES_EXCLUDE. If you have lifted that block, for example with NODES_EXCLUDE="[]", check whether you actually need the node. The documentation also suggests the Read/Write Files from Disk node as a candidate for the block list.

As for the Code node: since version 2.0, code runs in so-called task runners, separate from the main process, and the documentation recommends external mode for stronger isolation. Also set N8N_BLOCK_ENV_ACCESS_IN_NODE=true so code and expressions cannot read environment variables, which often hold secrets. N8N_RESTRICT_FILE_ACCESS_TO limits which directories file nodes can touch.

Community nodes as a supply chain risk

Community nodes are extensions pulled from the npm registry. The n8n documentation is clear that they have full access to the machine n8n runs on and to the data in the workflows that use them. A malicious package, or one that is taken over later, is a direct route into your instance. Install only what you need, prefer nodes verified by n8n and turn off unverified packages with N8N_UNVERIFIED_PACKAGES_ENABLED=false. If you use no community nodes at all, set N8N_COMMUNITY_PACKAGES_ENABLED=false.

The encryption key

n8n encrypts credentials with a key it generates at first launch and stores in the ~/.n8n folder. You can set it yourself through N8N_ENCRYPTION_KEY instead; in queue mode, every worker needs the same key. Two rules follow. First, keep the key out of the backup or repository that holds the database, because anyone with both can decrypt every credential. Second, without the key, a database backup is useless for restoring credentials. Store it separately and securely, for example in a password vault. n8n now also supports key rotation, which you should use after any suspected compromise.

Requests into the internal network

The HTTP Request node can call any address the server can reach, including internal services and cloud metadata endpoints. From version 2.12.0, n8n offers protection against this kind of server-side request forgery (SSRF). Enable it with N8N_SSRF_PROTECTION_ENABLED=true, and it blocks private address ranges and loopback, among others. The documentation stresses that it complements network firewalls rather than replacing them.

No fixed update routine

Given the number of published flaws, a fixed update routine is the most effective single control. Follow the advisories in the GitHub repository and the BSI WID notices, apply security updates promptly and test your key workflows afterwards. If you are stuck on an old major release line, plan the move before it stops receiving fixes.

Self-hosted or n8n Cloud

On n8n Cloud, n8n runs the server and applies platform updates, which takes much of the server hardening off your plate. It does not make your instance secure by default: flaws such as CVE-2026-21877 affected Cloud instances too, according to the vendor, and everything you configure yourself remains your job.

AI agents in n8n and prompt injection

n8n ships nodes for AI agents that connect a language model to tools, as well as nodes for the Model Context Protocol (MCP). Such an agent reads emails, tickets or web pages and then decides which tool to call. That is exactly the weak spot: text inside the data it reads can carry instructions the model will follow. Prompt injection cannot be filtered out completely. What works is limiting the agent's tools so that a planted instruction cannot do much damage, and requiring human approval for actions with consequences, such as payments, deletions or outbound email.

We explain how prompt injection and tool poisoning work in detail in Prompt Injection and Tool Poisoning in MCP Servers. The trust boundaries of an agent and how to secure them are covered in AI Agent Security: A Practical Overview.

n8n hardening checklist

What the built-in security audit covers, and what it does not

n8n includes its own security audit, available from the command line as n8n audit, through the API or through the n8n node. Among other things, it lists unused credentials, expressions in SQL queries, nodes with file system access, risky built-in nodes, installed community nodes, unprotected webhooks and an outdated n8n version. That makes it a good regular starting point.

The audit, however, assesses configuration, not the logic of your workflows. Whether a webhook field lands unchecked in a database query, whether an AI agent can be talked into an action by a crafted email, or whether a connected account holds far more permissions than it needs only becomes visible in a review that attacks the workflows the way an attacker would.

Frequently asked questions

Further reading

• AI Agent Security: A Practical Overview
• Prompt Injection and Tool Poisoning in MCP Servers
• The OWASP Top 10 for Agentic AI, Explained
• Service: AI and MCP security testing

Sources

• n8n on GitHub: Security Advisories
• GHSA-v4pr-fm98-w9pg (CVE-2026-21858)
• GHSA-v98v-ff95-f3cp (CVE-2025-68613)
• GHSA-v364-rw7m-3263 (CVE-2026-21877)
• GHSA-62r4-hw23-cc8v (CVE-2025-68668)
• GHSA-365g-vjw2-grx8 (Execute Command node)
• NVD: CVE-2025-68613
• CISA: Known Exploited Vulnerabilities Catalog
• BSI CERT-Bund: WID-SEC-W-2026-0040
• n8n Docs: Security environment variables
• n8n Docs: v2.0 Breaking changes
• n8n Docs: Block specific nodes
• n8n Docs: Community nodes risks
• n8n Docs: Set a custom encryption key
• n8n Docs: Enable SSRF protection
• n8n Docs: Run security audits
• EUR-Lex: General Data Protection Regulation (EU) 2016/679