MINI-COURSE · LESSON 3 OF 3
- Self-Hosted n8n Security: 7 Checks to Run Now
- What the October 2026 n8n update says
- Self-hosted n8n security checklist
- Check your version and update path
- Run n8n’s built-in security audit
- Review every public webhook
- Protect the credential-encryption key
- Reduce sensitive execution data and set retention
- Inventory nodes that can reach files or the host
- Review accounts, sharing, and recovery
- What an update notice does—and does not—tell you
- Security is a routine, not a single toggle.
Self-Hosted n8n Security: 7 Checks to Run Now
A practical review of versions, webhooks, credentials, execution data, nodes, and access—plus the fixed releases listed in n8n’s October 2026 security update.
Start with the version. Check the security notices for your release branch, update to a fixed release, then review the instance with n8n’s security audit. After that, inspect public webhooks, stored credentials, execution history, installed nodes, and who can access the instance.
Why this checklist is timely: n8n’s October 14, 2026 update included a high-severity advisory about credential secrets appearing in execution error data for several nodes, alongside other issues. The notice lists fixed releases by branch. This does not mean every self-hosted instance was affected or exploited; verify your own version and the advisory details. Read the n8n security update.
What the October 2026 n8n update says
The October 14 security update lists several high- and medium-severity issues. Among them is an issue involving credential secrets in execution error data for several nodes. The notice gives fixed versions for the affected release branches.
Self-hosted n8n security checklist
Check your version and update path
Find the version running in your instance and identify its release branch. Compare it with n8n’s advisory and update documentation. Plan an update using the procedure for your deployment, and verify the running version afterward.
Do not assume that a container tag, package manager, or deployment dashboard has updated the instance just because an update was available. Confirm what version is actually running.
Run n8n’s built-in security audit
n8n can generate a security audit from the CLI, its API, or the n8n node. The report can highlight unused credentials, risky or community nodes, file-system-related nodes, unprotected webhooks, missing security settings, and an outdated instance.
Treat the report as a starting point for investigation, not a certificate that the instance is secure. Review each finding in the context of the workflows and services you actually use. See the official security-audit guide.
Review every public webhook
List active webhook workflows and confirm why each endpoint needs to be reachable. Where the sending service supports it, configure a suitable authentication method. n8n’s Webhook node supports Basic auth, Header auth, JWT auth, or no authentication; it can also use an IP allowlist.
Check the fields the workflow accepts, the actions it can trigger, and the response it returns. CORS settings are not a replacement for authenticating webhook callers.
The Webhook node documentation describes its authentication options and allowlist behavior.
Protect the credential-encryption key
n8n encrypts credentials before saving them to its database. Its documentation
says the instance creates an encryption key on first launch and stores it in
the ~/.n8n folder unless you configure a custom key.
Restrict access to the key and its backups. If you run queue mode, n8n requires the configured key to be available to all workers. Do not put the key in a public repository, a shared workflow, or an unprotected support screenshot.
Review n8n’s encryption-key guidance before changing how your instance stores it.
Reduce sensitive execution data and set retention
Execution records can be useful for debugging, but they may contain data received or produced by workflow nodes. Decide which successful, failed, manual, or in-progress data the instance needs to retain. Keep enough to troubleshoot, and avoid saving information you do not need.
n8n lets you configure execution-data saving and prune older records. Check the retention settings for the instance and, where appropriate, individual workflows. The execution-data guide explains the available controls.
Inventory nodes that can reach files or the host
Review built-in, community, and custom nodes. Pay particular attention to nodes that interact with the file system or can execute code, and confirm that each one is needed by an active workflow.
- Remove what is unused. Unneeded integrations add maintenance and review work.
- Check where community nodes come from. Review their source, purpose, and update history before relying on them.
- Review host access. Understand which nodes can read or change files and what environment they run in.
n8n’s security audit includes reports for risky, community, and custom nodes, along with file-system-related nodes. Use those findings to guide a manual review of each workflow.
Review accounts, sharing, and recovery
Check who can sign in, which projects and workflows they can access, and whether that access is still needed. Remove accounts that no longer need access and review which credentials are used by shared workflows.
Keep a protected backup of the database and the required instance configuration, including the credential-encryption key. Know how you would restore the instance before you need to do it. A backup that has never been checked may not be enough to recover workflows and credentials.
n8n’s workflow-sharing documentation explains how access to a workflow affects what an editor can view, run, and use.
What an update notice does—and does not—tell you
A security notice identifies issues and the versions where they were fixed. It does not tell you whether a particular instance was exposed, whether a vulnerable feature was enabled, or whether an attacker accessed it. Those questions require reviewing the affected version, configuration, logs, and applicable advisory details.
If your version falls below a fixed release, prioritize the update. If you suspect unauthorized access or exposed credentials, follow your incident response process: preserve relevant records, restrict access as appropriate, and rotate affected credentials after assessing where they were used.
Security is a routine, not a single toggle.
Keep n8n patched, run its security audit, review public webhooks, protect the encryption key, limit retained execution data, inventory powerful nodes, and remove unnecessary access. Revisit the checklist after upgrades, workflow changes, or new security advisories.
The useful outcome: you can explain what is exposed, what data may be retained, who can use the instance, and which update or configuration needs attention next.
