An n8n instance is a credential vault, a code execution engine and an internet-facing webhook server in one process, so a single weak setting or unpatched release can hand an attacker every API key and OAuth token your automations use. n8n has become a common place to build AI agents and MCP servers as well as classic integrations, which adds prompt-driven tool calls on top of the existing risks. This guide covers identity and access in n8n, the credential encryption key, admin roles, webhooks, MCP and AI Agent nodes, recent critical advisories, logging and a self-hosting hardening baseline. It is written for platform engineers, security architects and SOC teams who run or approve n8n, whether self-hosted or on n8n Cloud.
Key takeaways
- The encryption key is the crown jewel.
N8N_ENCRYPTION_KEYprotects every stored credential; set it explicitly, keep it out of the database host and back it up separately, because losing it means losing the credentials and leaking it with a database dump means losing everything. - Anyone who can edit a workflow is close to code execution. Expressions, the Code node, Git node and file nodes have all featured in critical advisories, so treat workflow editors as privileged users and keep the instance patched within days, not months.
- Webhooks, forms and MCP endpoints are your attack surface. CVE-2026-21858 needed no login at all; authenticate every production trigger, restrict source IPs and keep the editor off the internet.
- Several important defences are opt-in. SSRF protection, environment variable blocking, settings file permissions, MFA enforcement and log streaming all have to be switched on deliberately.
- AI Agent workflows need tool-level controls. Scope each tool's credential, require human review for consequential tools and assume any text the agent reads, from a form, email or web page, may carry instructions.
How identity and access work in n8n
n8n has three overlapping identity layers: the people who log in to the editor, the credentials n8n holds to call other systems, and the callers who reach n8n through webhooks, forms, the public API or MCP. Most incidents involve the second and third layers, because a workflow credential is a non-human identity that usually carries far more access than the person who created it.
| Object | What it is | Security relevance |
|---|---|---|
| Owner account | The first account, created by whoever first opens a new instance's signup screen | Full control. An exposed fresh instance can be claimed by a stranger; from n8n 2.17.0 the owner can be pre-provisioned with environment variables, and N8N_INSTANCE_OWNER_PASSWORD_HASH must be a bcrypt hash. |
| Users, projects and roles | Instance roles (owner, admin, member) plus project membership | Owners and admins can view and share every workflow. Project members inherit access to the project's workflows. |
| Credentials | Stored API keys, OAuth tokens, database passwords and similar secrets | Encrypted at rest with the instance key. An editor of a shared workflow can use every credential that workflow references, even ones not shared with them directly. |
| Triggers | Webhook, Form, Chat Trigger and MCP Server Trigger nodes | Public URLs that start executions. Authentication is per node and frequently left at None. |
| Public REST API and API keys | Programmatic management of workflows, credentials and users | An API key is a standing credential with the creating user's reach. Disable the public API if you do not use it. |
| External secrets | Secrets fetched at runtime from a vault such as HashiCorp Vault or Infisical | Moves secret storage out of the n8n database; refreshed every 300 seconds by default (N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL). |
The encryption key
n8n encrypts credentials before saving them to its database. On first launch it generates a random key and saves it in the ~/.n8n folder unless you set N8N_ENCRYPTION_KEY yourself. Queue mode workers need the same key. A backup of ~/.n8n taken together with the database is a complete credential dump, so store the key in a secrets manager and pass it in with the _FILE suffix variant rather than leaving it on the same volume. The default N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=true stops workflow file nodes reading the .n8n directory; never relax it.
Recent releases add key rotation for self-hosted instances. The instance key now protects data encryption keys, and rotation (Settings > Data Encryption Keys > Rotate key, or POST /encryption/keys with the encryptionKey:manage scope) creates a new data key. Old records are re-encrypted only when next updated, so rotation limits future exposure but does not re-protect a database copy already stolen. n8n documents rotation as on by default from n8n 3.0 and opt-in on 2.x through N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true. Data written in the new format cannot be read by older versions, so back up the database and test in staging before enabling it, and do not downgrade afterwards.
Admin roles and privileged access
A workflow runs with its credentials, not the editor's permissions, so editing rights are effectively the right to use those credentials.
| Role or right | What it allows | Hardening note |
|---|---|---|
| Instance owner | Everything, including security policies, SSO, key rotation and the /audit API | One named, break-glass style account with MFA. Pre-provision it on new instances so the signup screen is never exposed unclaimed. |
| Admin | View and share all workflows in the instance, manage users | Keep the number small and review quarterly. |
| Member | Create workflows and share their own | Members can still write expressions and, where allowed, Code node logic. CVE-2025-68613 showed that an authenticated editor could reach code execution through expressions. |
| Workflow editor (shared) | View, run, update and export a shared workflow; cannot share or delete it | Can use every credential referenced in the workflow. Share credentials, not just workflows, deliberately. |
| Project membership | Access to all workflows in a project | Use projects as the boundary for credential reach: one project per team or data domain, not one per instance. |
- Single sign-on: n8n supports SAML and OIDC SSO. Use it so leavers lose access when the identity provider account is disabled. See the SAML Security Guide.
- MFA enforcement: set
N8N_MFA_ENFORCED_ENABLED=truetogether withN8N_SECURITY_POLICY_MANAGED_BY_ENV=trueso the policy is applied at every start and the UI toggle is locked. - Personal space controls:
N8N_PERSONAL_SPACE_SHARING_ENABLEDandN8N_PERSONAL_SPACE_PUBLISHING_ENABLEDdefault to true. Turning them off forces production work into governed projects.
Integrations, API tokens and service accounts
Every credential in n8n is a non-human identity with an owner, a scope and a lifetime. The common anti-pattern is a single admin-level OAuth connection to Google Workspace, Microsoft 365 or Salesforce reused by dozens of workflows, which turns any workflow bug into tenant-wide access. See the Secrets Management Guide and the SaaS and OAuth App Governance Guide.
- One credential per purpose: create dedicated service accounts or OAuth clients for n8n, scoped to the objects each workflow needs, and record the owning project.
- External secrets for high-value keys: hold cloud keys and database passwords in a vault and reference them, so rotation happens in one place and the n8n database holds fewer secrets.
- OAuth tokens with JWE: n8n can have your identity provider encrypt OAuth 2.0 tokens so only your instance can decrypt them, which reduces the value of an intercepted token.
- Public API keys: issue keys to automation accounts, not to people, and disable the public API entirely where you do not use it.
- Retire unused credentials: the built-in audit flags credentials not used in any workflow or in no recently active workflow; abandoned is 90 days by default (
N8N_SECURITY_AUDIT_DAYS_ABANDONED_WORKFLOW). See the NHI Offboarding and Decommissioning Guide.
Webhooks, forms and MCP endpoints
The Webhook node supports Basic, Header and JWT authentication, or None. It also has an IP(s) Allowlist option that returns HTTP 403 to other sources, and an Allowed Origins (CORS) option that defaults to *. The Only Run If filter is not a security control: if its expression fails to evaluate, the request is let through. Use HMAC-signed payloads where the sender supports them; see the Webhook Secrets Security Guide.
The MCP Server Trigger turns a workflow into an MCP server over SSE or streamable HTTP, exposing connected tool workflows to any MCP client. Its authentication options are None, Bearer and Header, and None is allowed. The default path is random, which is obscurity, not access control. Always set Bearer or Header authentication, keep the token in a client-side secret store, and expose only the tools that client needs. See the MCP Security Guide.
AI Agent workflows
The AI Agent node lets a model choose which connected tools to call and with what parameters, using whatever credentials those tools carry. Three controls matter most:
- Human review for consequential tools. n8n can pause before selected tools run and send the tool name and AI-chosen parameters to a reviewer in n8n Chat, Slack, Microsoft Teams, Gmail, Outlook and other channels; a denial cancels the call and tells the agent. Use it for sending email, payments, record deletion and anything external. See the Human-in-the-Loop for AI Agents Guide.
- Treat inputs as untrusted. Chat Trigger messages, form fields, emails and fetched web pages can carry indirect prompt injection. The ForcedLeak 2025 Agentforce research showed a public web form field steering an agent into exfiltrating CRM data; an n8n agent fed by a Form Trigger with a broad CRM credential and an HTTP Request tool has the same shape. See the Prompt Injection Guide.
- Remove the outbound channel. Enable SSRF protection and limit which hosts the HTTP Request tool can reach, so an injected instruction cannot post data to an arbitrary URL.
Recent critical vulnerabilities
All three advisories below were rated critical by n8n.
| CVE | Issue (per vendor advisory) | Affected and fixed | Preconditions and lesson |
|---|---|---|---|
| CVE-2025-68613 | Workflow expression evaluation not isolated from the runtime, allowing code execution with n8n process privileges (CWE-913) | From 0.211.0; fixed in 1.122.0 | Authenticated user who can edit workflows. Added to the CISA Known Exploited Vulnerabilities catalog on 11 March 2026. Editors are privileged users. |
| CVE-2026-21858 | Form-based workflow handling let an unauthenticated attacker read files on the server (CWE-20), CVSS 10.0 | 1.65.0 up to 1.121.0; fixed in 1.121.0 | No login needed. Interim advice was to restrict or disable public webhook and form endpoints. Exposure of triggers is exposure of the host. |
| CVE-2026-21877 | Authenticated user could cause untrusted code to run on the service (CWE-434), affecting self-hosted and n8n Cloud | From 0.123.0; fixed in 1.121.3 | Workaround was disabling the Git node with NODES_EXCLUDE. Blocking unused nodes reduces attack surface. |
Belgium's CCB advised taking internet-exposed instances offline until patched and rotating secrets where exposure was suspected, noting that patching does not remediate a past compromise. Because the n8n database holds decryptable credentials, any confirmed code execution on the host should trigger rotation of every stored credential and the encryption key. Track n8n in your vulnerability programme with an SLA aligned to KEV due dates; see the Patch Management Guide.
Logging and detection
By default n8n logs to the console at info level in text format. Set N8N_LOG_FORMAT=json for machine parsing and ship the output to your SIEM. On licensed editions, log streaming sends workflow, audit and node events to webhook, syslog or sentry destinations configured through N8N_LOG_STREAMING_DESTINATIONS; set N8N_LOG_STREAMING_MANAGED_BY_ENV=true so an admin cannot quietly remove a destination in the UI.
| Signal | Source | Why it matters |
|---|---|---|
| New or modified workflow containing Code, Execute Command, Git, SSH or file nodes | Log streaming audit events, n8n audit nodes report | Code execution paths used in the 2025 and 2026 advisories |
| Credential created, shared or accessed by a new user | Log streaming audit events | Credential reach expanding beyond its owning project |
| Executions from production webhooks spiking or from unexpected source IPs | Reverse proxy logs, execution history | Probing of unauthenticated triggers |
n8n process spawning shells or reading /proc/*/environ | EDR or container runtime security | Post-exploitation on the host (MITRE ATT&CK T1059, T1552.001) |
| Outbound connections to private or metadata ranges | Egress firewall, SSRF protection blocks | SSRF from HTTP Request or AI tools |
Run n8n audit (or POST /audit as owner) on a schedule. Its five reports cover credentials, database queries, file system nodes, risky and community nodes, and instance issues such as unprotected webhooks and outdated versions. Redact execution data for workflows that process personal data.
Metrics that show the controls are working:
- Days from n8n security release to production upgrade (target inside the KEV-style 14 day window for critical issues).
- Percentage of production webhook, form and MCP triggers with authentication set (target 100%).
- Number of credentials flagged unused by the audit and still present after 30 days.
- Percentage of AI Agent tools with side effects that require human review.
Hardening baseline
For self-hosted instances. On n8n Cloud, user, credential, trigger and AI controls still apply.
| Area | Setting | Default | Baseline |
|---|---|---|---|
| Credential encryption | N8N_ENCRYPTION_KEY (or _FILE) | Random, saved in ~/.n8n | Explicit, from a secrets manager, same on all workers |
| Settings file | N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS | false | true (0600) |
| Environment access from workflows | N8N_BLOCK_ENV_ACCESS_IN_NODE | false | true |
| File access | N8N_RESTRICT_FILE_ACCESS_TO, N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES | unset, true | A single data directory; keep true |
| Dangerous nodes | NODES_EXCLUDE | Execute Command blocked | Also block unused nodes such as n8n-nodes-base.readWriteFile |
| Git node | N8N_GIT_NODE_ENABLE_HOOKS, N8N_GIT_NODE_DISABLE_BARE_REPOS | false, false | Hooks off; bare repos disabled |
| SSRF | N8N_SSRF_PROTECTION_ENABLED (from 2.12.0) | Opt-in | true; allowlist only internal zones you control |
| Cookies | N8N_SECURE_COOKIE, N8N_SAMESITE_COOKIE | true, lax | true; strict where embedding is not used |
| MFA | N8N_MFA_ENFORCED_ENABLED with N8N_SECURITY_POLICY_MANAGED_BY_ENV | false | true, or enforce MFA at the SSO provider |
| Code execution | Task runners | Varies by version | External mode, -distroless image, UID 65532, read-only root filesystem, AppArmor deny on /proc/*/environ |
Roll it out in phases:
- Inventory and patch. List every instance (including test and personal ones), its version, exposure and credential count. Upgrade anything below the fixed versions above first.
- Close the perimeter. Put the editor and
/restAPI behind SSO or a VPN and expose only/webhook/, form and MCP paths through the reverse proxy. Terminate TLS at the proxy. See the Proxies and Forward vs Reverse Proxy Security Guide. - Protect the key and secrets. Move
N8N_ENCRYPTION_KEYto a secrets manager, separate backups of the key from database backups, and move high-value secrets to external secrets. - Apply the baseline in staging. Run representative workflows with env access blocked, nodes excluded and SSRF protection on; fix workflows that break before production. Roll back by reverting the environment variables, which are read at start-up. Encryption key rotation is the exception: it cannot be rolled back by downgrading, so restore from backup if needed.
- Tighten access. Enforce MFA or SSO, move production work into projects, reduce admins and review credential sharing.
- Turn on detection. JSON logs and log streaming to the SIEM, a weekly scheduled audit, and alerts for the signals above.
Small versus large deployments: a small team on a single Docker host should at minimum set the key explicitly, keep the editor off the internet, enable SSRF protection and patch monthly. A large organisation running queue mode should run task runners externally, manage security policy and log streaming through environment variables so configuration is versioned, and use one instance per trust zone rather than one shared instance for everyone. n8n Cloud shifts host patching to the vendor, but CVE-2026-21877 affected Cloud too, so it does not replace access control. See the Container Security Guide for the host side.
Common misconfigurations
- Unclaimed or internet-facing editor. The first visitor to a new public instance becomes owner, and an exposed editor turns authenticated advisories into remote ones.
- Triggers left at None. Webhook, form and MCP Server Trigger endpoints without authentication, with CORS at
*, and with no IP allowlist. - Encryption key stored beside the database. Volume snapshots and backups that contain both
~/.n8nand the database give a complete set of decryptable credentials to anyone who obtains them. - Admin-scoped integration credentials shared broadly. One OAuth connection with full mailbox or CRM rights reused across teams, so any editor can use it. Stale credentials left behind after a pilot are how the Klue OAuth breach 2026 began.
- AI agents with side-effect tools and no review. An agent fed by public input with email-sending or HTTP tools and no human review step or SSRF limits.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| Encryption key and credential storage | SC-12, SC-28, IA-5 | PR.DS-01 | 3 | A.8.24 |
| Roles, projects and credential sharing | AC-2, AC-6 | PR.AA-05 | 5, 6 | A.5.15, A.8.2 |
| Hardening baseline and blocked nodes | CM-6, CM-7 | PR.PS-01 | 4 | A.8.9 |
| Trigger exposure and SSRF | SC-7 | PR.IR-01 | 12, 13 | A.8.20 |
| Patching n8n | SI-2, RA-5 | ID.RA-01 | 7 | A.8.8 |
| Logging and audit | AU-2, AU-6 | DE.CM-09 | 8 | A.8.15, A.8.16 |
Relevant ATT&CK techniques are T1190 Exploit Public-Facing Application for trigger exploitation, T1059 Command and Scripting Interpreter for code execution, T1552.001 Credentials In Files for key and credential theft, and T1567 Exfiltration Over Web Service for agent-driven data loss.
Practitioner checklist
- Inventory every n8n instance and confirm each runs a release at or above 1.122.0 or a later supported line.
- Set
N8N_ENCRYPTION_KEYexplicitly from a secrets manager and back it up separately from the database. - Keep the editor and REST API off the internet; expose only authenticated webhook, form and MCP paths.
- Require authentication and an IP allowlist on every production Webhook, Form and MCP Server Trigger.
- Enforce MFA or SSO, limit admins, and move production workflows and credentials into projects.
- Stream JSON logs to the SIEM and run
n8n auditweekly. - Apply the hardening baseline: env access blocked, file access restricted, unused nodes excluded, SSRF protection on, task runners external and unprivileged.
- Give each integration its own least-privilege credential and remove credentials the audit flags as unused.
- Require human review on AI Agent tools that send, delete, pay or call external URLs.
- After any suspected compromise, rotate every stored credential and the encryption key, not just the n8n version.
Standards and references
- n8n: Securing n8n
- n8n: Set a custom encryption key
- n8n: Security environment variables
- n8n: Enable SSRF protection
- n8n: Security advisory GHSA-v98v-ff95-f3cp (CVE-2025-68613)
- n8n: Security advisory GHSA-v4pr-fm98-w9pg (CVE-2026-21858)
- CISA: Known Exploited Vulnerabilities Catalog
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Low-Code Agent Platforms Guide · Zapier AI Security Guide · MCP Security Guide · Credential Vaulting for AI Agents Guide · SSRF Prevention Guide