n8n October 2026 Security Update: Self-Hosted Patch Checklist

Quick answer: self-hosted n8n operators should move to at least 1.123.85 on the 1.x branch, 2.43.5 on the stable 2.x branch, or 2.44.1 on the beta branch. n8n's October 14, 2026 bulletin lists 15 newly published advisories covering denial of service, stored cross-site scripting, cross-project data access, credential exposure, server-side request forgery, filter injection, and permission-check bypasses. Back up the database, encryption context, and persisted files; identify workflows and nodes relevant to the advisories; deploy a current fixed patch from your chosen supported channel; then verify credentials, webhooks, executions, projects, workers, and logs.

This is a source-based operator analysis published October 15, 2026. WealthLab did not exploit these issues, run proof-of-concept code, or patch a production n8n instance for this article. It contains no affiliate links.

What n8n disclosed on October 14

The n8n Security Team's bulletin groups five advisories as high severity and ten as medium severity. The fixed-version statement applies to three release tracks: 1.x at 1.123.85, stable 2.x at 2.43.5, and beta 2.x at 2.44.1. n8n Cloud customers are patched automatically according to the bulletin; self-hosted operators below the stated fixed version must upgrade.

The bulletin is a patch notice, not evidence that every instance was exploited or that every issue applies to every deployment. Exposure depends on enabled nodes, webhook reachability, user roles, project boundaries, execution-data retention, local file access, Local Gateway use, and integrations such as Slack, Quick Base, SeaTable, Outlook, or SharePoint.

The 15 advisories, grouped by operator concern

These descriptions are condensed from n8n's bulletin titles. Use the individual GitHub Security Advisories for exact affected ranges, preconditions, package details, and severity metadata; do not infer exploitability from a title alone.

Who should act first?

1. Internet-exposed self-hosted instances below a fixed version. Public editors or webhooks increase the importance of timely containment and patching.
2. Multi-user or multi-project instances. Several advisories concern project boundaries, shared workflows, credential permissions, Chat Hub roles, or inherited execution context.
3. Instances retaining failed execution data. Credential-related advisories make access to error records and logs part of the review.
4. Deployments using implicated integrations. Prioritize Slack Trigger, Read/Write Files, Quick Base, SeaTable Trigger, Outlook v1, SharePoint v1, Local Gateway, sub-workflows, and webhook responses.
5. Single-user private instances. Patch them too. Their practical exposure may be narrower, but a compromised workflow input, public webhook, imported workflow, or excessive network permission can still matter.

Safe patch sequence for Docker and Compose

1. Record the current state. Capture the running n8n version, exact image reference and digest, database engine, queue topology, worker versions, encryption-key handling, and current health result. Keep secrets out of reports.
2. Check the official fixed range. Open the n8n bulletin and relevant GitHub advisories immediately before maintenance. The three versions above are the bulletin's October 14 minima, not a reason to downgrade from a newer fixed patch.
3. Back up recoverable state. Include the database, persisted .n8n or configured storage, binary data, external object-storage configuration, encryption key material, Compose definition, and non-secret configuration inventory.
4. Prove the backup can be read. A successful archive command alone is insufficient. At minimum validate archive integrity and database dump readability; for important instances, restore to isolated resources with synthetic credentials and no production side effects.
5. Choose a current patch in your branch. Prefer the latest supported stable patch compatible with your change policy. Do not move from stable to beta merely because the beta fixed version is numerically higher.
6. Review release notes between versions. Security urgency does not eliminate compatibility risk. Note migrations, removed settings, node changes, and required worker coordination.
7. Stop or drain writes deliberately. Prevent schedules, webhooks, workers, and manual runs from racing a database migration or creating ambiguous duplicate effects.
8. Deploy the pinned image. Pull the exact intended tag, record its digest, recreate all n8n processes that must run the same application version, and inspect startup and migration logs.
9. Run acceptance checks. Verify login, database connectivity, credential decryption, schedules, public webhooks, queue workers, task runners, binary data, error workflows, and one controlled execution for every critical workflow class.
10. Monitor before closing maintenance. Watch failed executions, worker crashes, CPU/event-loop symptoms, outbound requests, unexpected project access, and authentication or permission errors.

Post-patch investigation is risk-based

A fixed container does not erase previously saved execution data or establish that no issue was used. Investigation depth should match exposure. Start with the advisories relevant to your enabled features and the time range for which useful logs exist.

• Credentials: restrict access to failed execution data and error workflows; search for secret material without copying it into chat or tickets. Rotate a credential when evidence or advisory-specific guidance justifies it, updating and verifying consumers before revocation unless immediate containment is required.
• Outbound traffic: review proxy, firewall, DNS, or cloud-flow evidence for unusual destinations from the n8n runtime, especially around public Slack Trigger requests or workflows handling attacker-controlled URLs.
• Projects and tables: examine cross-project access, workflow sharing, data-table reads, and user activity. Unexpected access is more important than a merely vulnerable version.
• Webhook output: inventory workflows returning user-influenced HTML and ensure browser consumers do not grant those responses a trusted application origin.
• File and filter nodes: locate untrusted values flowing into glob or filter expressions. Patching is necessary, but validating data flow reduces the chance of a different injection path surviving.
• Gateway and agent tooling: confirm Local Gateway pairings and Chat Hub tool registrations against an approved inventory.

Rollback without undoing the security fix

Define rollback before deployment, but do not treat prolonged return to a vulnerable version as an acceptable steady state. If the fixed build breaks critical workflows, isolate public access and untrusted inputs, restore the pre-change database and storage only when required by migration behavior, return temporarily to the recorded image, and prepare the next fixed compatible patch. Never point an older image at a database already migrated by a newer release unless n8n documents that exact downgrade path.

If patching cannot happen immediately, reduce exposure: remove public editor access, disable affected nonessential workflows or integrations, restrict webhook ingress, constrain outbound network access, tighten execution-data access, and increase logging. These controls are temporary risk reduction, not substitutes for the vendor fix.

Fit and non-fit

This checklist fits self-hosted n8n operators running Docker, Compose, Kubernetes, npm, or another managed runtime who need to turn the bulletin into an orderly patch and evidence review. The container commands differ by platform, but the state, backup, version, acceptance, and investigation decisions remain relevant.

It is not an exploitation guide, proof of compromise, a complete incident-response playbook, or a promise that an upgrade alone cleans historical secrets from execution data. n8n Cloud customers do not need to patch the service themselves, but they may still need to review workflow design and credential scope if a relevant integration handled untrusted input.

Evidence boundary

WealthLab reviewed n8n's October 14 Security Team bulletin, the n8n GitHub Security Advisories index, n8n's current update guidance, and the Singapore Cyber Security Agency alert listing updated October 14. We did not run proof-of-concept code, inspect private advisory records, determine whether any WealthLab reader was affected, patch an n8n production database, or validate rollback. Exact severity and affected-version details should be taken from each maintained advisory at maintenance time.

Related WealthLab guides

• Map exposure from n8n’s October 28 security batch
• n8n 3.0 Upgrade Checklist for Self-Hosted Instances
• n8n VPS Requirements: RAM, CPU & Docker Sizing
• Docker VPS Production Checklist
• VPS Firewall Setup for Docker Apps
• Ghost Docker Backup and Restore Guide

Sources checked October 15, 2026

• n8n Security Team: October 14 security update — primary source for the advisory list, fixed branches, and Cloud versus self-hosted action.
• n8n GitHub Security Advisories — maintainer-published advisory index for individual issue details.
• n8n Docs: Update n8n — primary operational guidance to update frequently, review release notes, and test in an environment first.
• Cyber Security Agency of Singapore: Multiple Vulnerabilities in n8n Platform — independent government alert updated October 14; its page blocked this run's direct browser fetch, so no extra technical claim depends on inaccessible body text.