n8n Security: Vulnerabilities, AI Agent Risks, Self-Hosted Hardening and Enterprise Controls

This is the part of n8n security that patching does not touch, and n8n deserves credit for documenting it without softening. Its community nodes risk page states: "Community nodes have full access to the machine that n8n runs on, and can do anything, including malicious actions." It adds that "Any community node that you use has access to data in your workflows." Those two sentences describe an npm package running with your automation platform's full privileges and your decrypted credentials in reach.

In January 2026 that model was attacked directly. Endor Labs documented a campaign of malicious npm packages published as n8n community nodes, dressed up as ordinary integrations. Their description of why it worked is the clearest statement of the underlying design anyone has published: "Community nodes run with the same level of access as n8n itself. They can read environment variables, access the file system, make outbound network requests, and, most critically, receive decrypted API keys and OAuth tokens during workflow execution." They also note the structural point: "There is no sandboxing or isolation between node code and the n8n runtime."

What left the building was not just a password. Endor Labs reports the stolen material included developer tokens, client IDs and client secrets, refresh tokens, login customer IDs and user-entered license keys, sent to a command and control endpoint hosted on a free application platform under a name designed to look like license validation. Refresh tokens are the ones that matter for incident response, because they survive a password reset and keep working until someone explicitly revokes the grant.

Two operational conclusions follow, and neither is "review the source code." Reviewing helps, but the packages in this campaign shipped minified JavaScript and a maintainer can push a clean version today and a hostile one next Tuesday, at which point your review is a historical artifact. The conclusions that hold up:

• Treat the installed node list as an inventory item with an owner. n8n lets self-hosted instances disable community nodes entirely, and lets you block specific nodes by name. If your workflows do not need community nodes, turning them off removes this section from your threat model completely. If they do, the list should be short, named and pinned to exact versions.
• Assume the credential is reachable and reduce what it unlocks. A node that receives a decrypted OAuth token cannot be stopped from using it. What can be changed is what that token is scoped to and how long it lives. This is the same argument as least privilege for AI agents, applied to a workflow engine.

n8n does maintain a set of verified community nodes, which it states have to meet data and system security requirements for approval. That is a real improvement over an open registry, and it is the right default for teams that need the ecosystem. It is not a substitute for pinning versions, because verification is a point-in-time judgment about a package that keeps changing.

Everything above is classic application security. This section is the part that is specific to 2026, and it is the reason a lot of n8n instances quietly became the most privileged thing in the company.

A traditional n8n workflow is deterministic. A trigger fires, steps run in the order you drew them, and the set of possible actions is fixed at design time. You can reason about it. An AI Agent node breaks that property on purpose: it is given a set of tools and it decides at runtime which to call, with what arguments, and how many times. That is the feature. It is also the thing that makes a security review of the diagram insufficient, because the diagram no longer enumerates the behavior.

Now add the input. Agent workflows are usually built precisely because the input is messy and unstructured: inbound support email, scraped pages, form submissions, Slack messages, documents, RSS. Every one of those is attacker-influenced text arriving at a component that treats text as instructions. That is indirect prompt injection, and it is a different problem from a user typing a jailbreak into a chat box, a distinction we go through on prompt injection vs jailbreak.

Put the two together and the failure mode is concrete rather than abstract. A support ticket contains text addressed to the agent instead of to you. The agent has an HTTP Request tool, a Gmail tool and a Postgres tool, because that is what made the automation useful. It follows the instruction in the ticket. Nothing in that sequence is a bug in n8n, nobody exploited a CVE, and the workflow did exactly what it was configured to do.

The fix is not a better prompt, and anyone selling you one is overselling. Instructions to ignore instructions are not a boundary, because the model has no reliable way to tell your text from the attacker's text. The controls that survive are containment controls: give the agent its own identity rather than a shared service account, scope each tool credential to the narrowest thing that still works, put a human in front of anything irreversible, and log the calls somewhere the n8n host cannot rewrite. We cover the containment argument in more depth on AI agent guardrails, the identity half on AI agent identity, and the same problem inside a Microsoft tenant on Copilot Studio security.

One n8n-specific control is worth naming because it is free and underused. The built-in audit does part of this inventory for you.

Teams ask which is more secure and expect a winner. There is not one, but the risks are genuinely different, and for a US buyer one row below matters more than most comparisons mention.

The honest summary: Cloud removes the risk that has actually been exploited in the wild, which is running an old version. Self-hosting gives you residency and node control, and hands you the patching duty that the CVE section shows is not optional. Pick on which failure your organization is more likely to make, not on which sounds more secure.

Two things are identical either way, and they are the ones this page keeps returning to. The credentials n8n holds are equally powerful in both models, and an AI Agent node reading untrusted input behaves the same on both. Neither deployment choice touches those. If you are documenting this for an auditor or a customer security questionnaire, the framing that holds up is on AI compliance.

Ordered by risk removed per hour spent. The first five are n8n configuration and cost close to nothing.

1. Set a version floor of 1.123.17 or 2.5.2 and verify it by query. This closes all three critical remote code execution flaws, including the one CISA lists as actively exploited. Verify against the running instance, not against the deployment doc.
2. Run the built-in audit and act on it. n8n ships an n8n audit command that reports across five categories: credentials, database, file system, nodes and instance. It flags credentials not used in any workflow or not used in a recently active one, expressions used in SQL node query fields, nodes that touch the file system, risky official nodes alongside community and custom nodes, and instance-level problems including unprotected webhooks, missing security settings and an outdated version. Most teams have never run it. The unused-credential list alone is usually the fastest cleanup available.
3. Decide the community node policy explicitly. Disable them outright if workflows do not need them. If they do, allowlist by name, pin exact versions, prefer n8n's verified nodes, and give the list an owner. n8n also supports blocking specific nodes, which is the right home for the ones that read the file system or execute code.
4. Turn on the settings n8n already ships. Its own guidance is to "Conduct a security audit to identify security risks," "Set up SSL to enforce secure connections," "Set up Single Sign-On for user account management," "Use two-factor authentication (2FA) for your users," and "Enable encryption key rotation to periodically replace the key that encrypts credentials." Add SSRF protection, disable the public API if nothing uses it, and require verified emails for account registration. SSO, SAML and LDAP sit on the Enterprise plan; RBAC is on all paid plans.
5. Redact execution data. n8n can "Redact execution data to hide input and output data from workflow executions." Execution history is a full copy of everything that moved through the workflow, including whatever the CRM returned, and it sits in a database that more people can read than can call the CRM. This is a common quiet source of exposure, discussed further on AI data leak prevention.
6. Protect every webhook. An n8n webhook is an unauthenticated internet-facing entry point into your automation unless you gave it authentication. The audit flags unprotected ones. Ni8mare was reachable through form-based workflows, which is the same category of exposure.
7. Scope the credentials down. The Salesforce credential in n8n usually has whatever the person who created it had. Issue a dedicated integration user per workflow with the narrowest role that works, and prefer short-lived tokens where the provider supports them. This is the control that decides how bad a community node compromise gets. See AI agent access control.
8. Give agent traffic its own identity. When an n8n step calls your internal API with a shared service token, the request is indistinguishable from every other automation in every log you own. Separating identity per workflow is what makes the rest of this investigable at all.
9. Gate irreversible actions on a human. Deletions, refunds, outbound email to customers, production writes, anything that cannot be undone by rerunning the workflow. n8n has a wait-for-approval pattern, and where that pattern breaks down is on human in the loop AI agents.
10. Log tool calls off the n8n host. Execution history lives in the same database as the thing you are investigating and is editable by anyone with instance admin. If you need to answer what a workflow touched during an incident window, that record has to be somewhere else. See agent audit trail.

Items one through six are n8n configuration and belong to whoever operates the instance. Items seven through ten are infrastructure, they apply identically to every agent platform in your estate, and they are the reason a review scoped to "is n8n secure" tends to commission the wrong project. The same split showed up in a coding agent on Cursor AI security, in an agent framework on OpenClaw security, in a low-code enterprise builder on Copilot Studio security, and at infrastructure scale in the Hugging Face security incident.

We sell a policy gateway, so read this skeptically. It is written to be accurate rather than flattering, and half the rows say no or partly.

Two flat no, two partial, two yes. If you are running a vendor evaluation, ask every vendor in this market for the same table and treat an all-green answer as a reason to look harder rather than a reason to shortlist. Our survey of who actually does what is in AI agent security companies.

The honest summary of n8n security is that n8n has been forthright about the risks it hands you, ships more hardening than most teams switch on, and had a rough two months of expression-engine disclosures that it patched. None of that is the hard part. The hard part is that n8n is where your credentials live, and adding an AI Agent node turned a deterministic pipeline into something that decides at runtime which of those credentials to use. That change is not visible in a workflow diagram and it is not covered by a patch. It is the same shape as the problem on LangChain security and multi-agent security: constrain what an agent can reach, and keep the record somewhere it cannot rewrite.