n8n Security Vulnerabilities 2026: Fixes and Self-Hosted Checks

Updated on: 31 October 2026. Added the October 28 advisory batch; the snapshot now includes advisories through 28 October, checked 31 October 2026.

Originally published 1 September 2026. Last reviewed 31 October 2026 against the official GitHub advisories linked below. This is a selected advisory review, not a complete security assessment.

The October 28 advisory batch is covered below, in the 28 October 2026 advisories section.

Use this as a self-hosted checklist: version, public entry points, editors, credentials, and a tested restore — in that order.

n8n security vulnerabilities affect different versions and configurations. To check a self-hosted instance, record its installed version, read the relevant official advisory and compare the affected range with the features your workflows use. A headline or one old patch number is not enough.

This guide gives you a practical n8n self-hosted security checklist: patch checks, workflow exposure, access, credentials and restore testing. It does not certify an instance as secure or claim that every deployment is exposed to every advisory.

Which n8n version should you run?

Use a supported release that fixes the advisories relevant to your deployment. Do not stop at an October 1 patch number: newer notices were published on October 14. This snapshot records three of them, checked on October 20, 2026.

Read each advisory’s affected range and patch instructions. A fix for one issue does not cover every other issue or repair an unsafe workflow. This guide does not test exploits against your instance.

28 October 2026 advisories

On 28 October 2026, n8n published a new batch of security advisories. This is a selected advisory review, not a complete security assessment. This batch is separate from the October 14 batch above: a fix for one issue does not cover every other issue, and patching does not repair an unsafe workflow. Check each advisory’s affected range against the features your workflows use.

What is CVE-2026-21858 in n8n?

CVE-2026-21858 is the critical file-access issue disclosed on January 7, 2026. n8n lists versions 1.65.0 up to, but not including, 1.121.0 as affected. Certain form-based workflows could let an unauthenticated attacker read server files. Version 1.121.0 fixed this issue.

That January fix is historical context, not today’s update target. Later advisories require newer patches. If you may have been exposed, review the relevant execution history and connected credentials as part of your incident process; updating alone does not undo earlier access.

2026 advisories by what they put at risk

n8n’s 16 September batch was fixed in 1.123.80, 2.39.6 and 2.40.1. The 1 October batch used fixes 1.123.83, 2.41.4 and 2.42.1; the October 14 notices above require newer fixes. This table is a selection, not the full list.

A patched engine can still have unsafe workflow settings. Confirm current advisories and release notes using the n8n security advisories category and the GitHub advisories. Upgrade steps are in the n8n update guide.

Quick check: what to review first

Read an n8n advisory against your own setup

Start with n8n’s official security advisories. For each relevant notice, record the affected package, version range, required permissions, vulnerable feature, fixed versions and any temporary mitigation. Do not treat a mitigation as a permanent substitute for patching.

A recent example is GHSA-5qpp-pqww-h7fp, published on September 30, 2026. It concerns expression interpolation of untrusted input into the Query field of the Microsoft SQL node. The advisory lists fixes in 2.42.1 and 2.41.4 and explains the affected node behaviour. Its recommended node and query changes should be checked against the specific workflow.

That example does not mean either version fixes every n8n vulnerability. It also does not mean an instance without that node is free of other risks. Review the advisories for the branch and features you actually use, then choose a supported patched release.

Keep a simple record: “instance version, advisory, relevant workflow, required action, date checked.” This is more useful than an undated list of CVEs with one general “safe version.”

Update without losing the workflows you depend on

1. Identify the deployment. Record whether it uses Docker, npm, queue workers or a managed host.
2. Back up before changing it. Include the database, persistent files, configuration and the encryption key needed to read stored credentials.
3. Read release notes. Check breaking changes and migration instructions for your current version.
4. Test a separate copy where possible. Use sample data and test destinations rather than sending real customer messages.
5. Apply the supported update. Keep the main process and workers compatible with the chosen release.
6. Verify essential flows. Test triggers, credentials, code, branches and error alerts after the update.

Document the rollback plan as well as the upgrade. A database migration may make “just start the old image” an incomplete recovery plan. Do not overwrite your only backup while testing.

Use the built-in n8n security audit

n8n supports an audit through the CLI, API or n8n node. For the node route, select Resource Audit and Operation Generate. The reports cover credentials, database queries, file-system access, nodes and instance settings. They can flag unprotected webhooks or outdated configuration. See the audit documentation.

Treat the report as a starting point. Inspect why each flagged node exists and what it can access. A legitimate file-processing workflow may need file access; the question is whether it has more access than the job requires.

An empty report is not a penetration test or a guarantee that every connected service is configured safely. Keep advisory checks and workflow review as separate activities.

Separate editor access from public workflow endpoints

If you use approval gates, check them first

Three 2026 advisories involve Send and Wait or agent tool approvals. The worst case in n8n’s own wording for the HMAC bypass is that a caller holding an execution’s resume token can approve an action meant for someone else, and downstream steps run with the workflow owner’s credentials. Before patching, n8n’s temporary workarounds are to limit instance access to trusted users, avoid approval nodes guarding high-impact actions behind a public trigger, and review execution history for unexpected approvals or declines. These do not fully remediate the risk. Patching does. For building a safer approval flow, see the human-in-the-loop tutorial.

Make a list of the endpoints that must receive outside traffic. Your team’s editor and an incoming payment webhook have different access needs. Use HTTPS, appropriate account protections and a documented network design for the deployment.

For each public workflow, check the provider’s authentication or signature method, expected request shape, payload size and accepted events. A secret-looking webhook URL is not the same as verified request authentication.

Do not add a rule that silently blocks legitimate provider callbacks. Test valid and invalid requests in a safe environment, then confirm the workflow receives expected production events. Keep logs that help identify rejected requests without exposing credentials or full customer payloads.

Limit what users and credentials can do

Give each connection the permissions needed for its task. A workflow that reads leads does not normally need permission to delete all contacts. Use separate service accounts where that improves separation and the connected provider supports it.

Review who can edit a workflow as well as who can view it. Editing can change where data goes and what connected credentials are used for. Check the roles and sharing behaviour available in your edition rather than assuming a “viewer” or “editor” label means the same thing in every tool.

Keep tokens in n8n credentials or an appropriate secret-management setup. Avoid pasting them into examples, exports, screenshots or error notifications. Rotate exposed credentials using the provider’s process; patching the workflow engine does not revoke a leaked API key.

Harden code execution and review community nodes

Review code, command, file-access, custom and community nodes before importing a workflow. Understand the package source, version and permissions. A template imported from the internet is executable workflow logic, not just a diagram.

For self-hosted deployments using Code nodes, n8n documents external task runners, reduced-image options, unprivileged execution and filesystem controls in its hardening guide. Apply settings appropriate to your environment and test the workflows they affect. Isolation reduces exposure; it does not remove the need for updates.

Avoid broad access to the host, internal network or environment secrets when a workflow only needs one service. Do not disable a protection just to make an untrusted imported workflow run.

Keep AI input separate from authority

An incoming email or web page can contain instructions meant to influence an agent. Treat it as data. The workflow should define which tools exist, what those tools can access and which actions need review.

For example, an email-extraction flow can return suggested fields without being allowed to change account permissions or send arbitrary messages. Validate the output before a write. A JSON Schema checks shape; it does not make an instruction trustworthy.

Use human approval for consequential actions and a small tool list for agents. The MCP setup guide explains the difference between connecting an agent to tools and exposing workflow access to a client.

Test your backup and incident process

n8n encrypts stored credentials using an encryption key. Its key documentation explains the generated key and worker configuration. Preserve the correct key with your recovery materials and protect it as a secret.

Restore into a separate environment, check that credentials can be read and run a harmless sample workflow. Do not enable restored production triggers automatically. They can replay events or send messages while the original instance is still running.

If you suspect compromise, preserve useful logs, limit the affected access and follow the incident process for your environment. Review connected accounts as well as the n8n host. Credentials, stored data and downstream actions may need separate investigation.

n8n Cloud versus self-hosted responsibility

Managed hosting changes who operates the infrastructure. It does not remove your responsibility for account access, integration permissions, public workflows or the logic that sends and changes data. Do not assume a specific advisory affects or excludes Cloud customers unless n8n’s notice establishes that.

Self-hosted operators also manage server configuration, updates, storage, monitoring and recovery. If nobody on your team can maintain those tasks, include managed hosting in your decision. See our deployment guide.

Frequently asked questions

Is self-hosted n8n safe?

Security depends on the version, configuration, workflows and access controls. Check relevant advisories, apply patches and test recovery. No checklist can certify every installation.

Does n8n Cloud need patching?

n8n states that Cloud instances are patched automatically and need no action. Self-hosted instances must be upgraded by you.

Which n8n version is safe?

No version is safe against every future advisory. Compare your installed release with current official affected and fixed ranges. The October 14 examples above list newer fixes than the October 1 batch; keep checking for later notices.

Does updating fix every workflow security problem?

No. An update can patch a software vulnerability, while a workflow may still expose an unauthenticated endpoint or use an overpowered credential.

Is an old patched version enough?

A version that patched one advisory can be affected by a later one. Check current advisories and a supported release for your branch.

Does self-hosting keep all AI data local?

Not if the workflow sends it to an external API. Review each connected provider and what input the workflow transmits.

The five directly linked advisory explanations above were checked on 20 October 2026, and the three 14 October advisories (Data Tables, webhook responses, credential errors) were rechecked against GitHub on 30 October 2026. The September advisory table is retained as historical context. Recheck official notices before making a version-specific decision.

You can read this article without subscribing. Want the next tested article?