Self-Hosted n8n After the October 2026 Security Fixes: What to Patch and a Patch Policy You Can Copy

On October 14, 2026, n8n published 15 security advisories on GitHub: 4 rated High and 11 Medium, none with a CVE ID. To clear all of them on the 2.x line, run 2.43.5 or later on 2.43.x, or 2.44.1 or later on 2.44.x (current stable is 2.44.7). On the 1.x line, 1.123.85 or later clears the 11 advisories that list a 1.x fix; the other 4 list fixes on 2.x only. If you self-host n8n, nobody does this upgrade for you, and n8n now ships a new batch of advisories every two weeks.

We counted every advisory on n8n's GitHub security advisories page on 2026-10-27. Below you get the full list for the October 14 batch, which versions fix what, why a CVE-based scanner misses most of it, and a one-page patch policy you can copy into your own runbook.

What did n8n fix on October 14, 2026?

n8n released three fixed builds that morning: 1.123.85 and 2.43.5 as normal releases, and 2.44.1 as a pre-release. Later that morning (UTC) it published the 15 advisories. Four of the 15 had been fixed about two weeks earlier and were only disclosed on October 14: three in 2.41.4, 2.42.1 and 1.123.83 (September 30), and one in 2.41.5 and 2.42.2 (October 1).

The nine Medium advisories grouped in the last row are GHSA-8vrr-mgc5-jg55, GHSA-v9cx-v88r-42vw, GHSA-8crx-5h96-q72q, GHSA-pcr3-v5vr-qppf, GHSA-qmvv-q3c9-wpp7, GHSA-crfj-5wv6-8v86, GHSA-65mv-v8rp-54wc, GHSA-mgpr-56r4-5c67 and GHSA-43v8-hjhm-chjp. One of them, GHSA-pcr3-v5vr-qppf (per-user credential theft through error workflows), lists fixes only on the 2.x lines: 2.41.5 and 2.42.2.

What we found: 13 of the 15 advisories are rated CVSS PR:L: the attacker needs an account on the instance. In 8 of them that account must be able to create, edit or run workflows; others need only a chat-user account or access to execution logs. The other 2 are rated PR:N (no login). So next to "what version are we on", ask "who has an account on our n8n, and what can they do".

Which n8n version should you run now?

Use the line you are already on and move to its newest patch release. As of 2026-10-27, the GitHub releases page shows:

If you are on 2.42.x or older, no patch on your line fixes this batch: at least 11 of the 15 stay open (all 15 below 2.41.4), and older batches may be open too. Jumping several minor versions is where upgrades break, which is why n8n's own update guide says to "update frequently" so you avoid "having to jump multiple versions at once".

Watch out: the latest image tag is not a pin. If your Docker Compose file says n8nio/n8n or n8nio/n8n:latest, the version you run depends on when the container was last pulled. Pin an exact version such as n8nio/n8n:2.44.7 so you always know what you run, and change it on purpose.

Why can a CVE-based scanner miss most n8n advisories?

Because most of them never get a CVE ID. Every advisory n8n publishes has a GHSA ID and names the n8n npm package, so scanners that read GitHub (GHSA) or OSV advisory data can match them. Tools that match only on CVE IDs see a small share.

We pulled all 225 advisories in the n8n repository through the GitHub API on 2026-10-27:

Since July, 17 of the 19 advisories with a CVE came from one batch (September 2-3); the other two came on July 8 and July 22. If your security review is "the scanner shows no critical CVEs for n8n", that review has missed most of what n8n disclosed this year. Watch the GHSA list itself: check the advisories page after each batch, or poll it with gh api repos/n8n-io/n8n/security-advisories. On the repository page, Watch, then Custom, then Releases at least tells you when fixed builds ship.

This is not a new problem for n8n. January 2026 brought two critical CVEs, CVE-2026-21858 (unauthenticated file access through webhook handling, CVSS 3.1 score 10.0) and CVE-2026-21877 (RCE through arbitrary file write, CVSS 3.1 score 9.9). In July, an expression sandbox escape let any workflow editor run OS commands. What changed in the second half of 2026 is the volume and the rhythm.

How often does n8n publish security fixes?

Every two weeks. Since May 13, 2026, n8n has published its advisories in batches 14 days apart, on Wednesdays (one September advisory landed a day late): May 13 and 27, June 10 and 24, July 8 and 22, August 5 and 19, September 2, 16 and 30, and October 14.

n8n's docs suggest you "try to update at least once a month". With a batch every two weeks, a monthly upgrade means you can sit two batches behind at any time, often with a dozen or more High advisories open. Our view is that the monthly rule is the floor, not the target. The policy below assumes a two-week rhythm that follows n8n's own.

Who patches a self-hosted n8n instance?

You do. Self-hosting means every upgrade, with its backup and its test run, belongs to your team. It often goes like this: n8n starts as one person's side project, and that person later moves on or gets busy. The instance keeps running, the workflows keep firing, and nobody owns the version number.

There are three honest options:

If you pick the third option, our n8n agency team runs this for clients as part of automation maintenance and support, from tracking new advisories to checking workflows after each staged upgrade. If you have a platform team with the time, you don't need us for this. Copy the policy below and give it an owner.

A self-hosted n8n patch policy you can copy

Paste this into your runbook and fill in the brackets. It is written for a Docker Compose install with one production instance and one staging instance.

# n8n patch policy: [company name]

Owner: [name]            Backup owner: [name]
Production: [URL], version pinned in [path/to/docker-compose.yml]
Staging: [URL], same pinned image, copy of production workflows

## Watch
- GitHub: Watch n8n-io/n8n > Custom > Releases, sent to [team inbox],
  plus a check of the security advisories page (or
  gh api repos/n8n-io/n8n/security-advisories) after each batch.
- Check the advisory list every second Wednesday after a batch lands.
- Do not rely on CVE-only scanners for n8n: most advisories have no CVE.

## Patch windows
- Critical, or any advisory that needs no login (CVSS PR:N) and touches
  a node or feature we use: staging same day, production within 24 hours.
- High: production within 7 days.
- Medium: next regular upgrade, at most 14 days.
- Stay on the stable line. Never run beta or next in production.
- Never fall more than one minor version behind stable.

## If we can't patch in the window
- Apply the workarounds listed in the advisory (for example
  NODES_EXCLUDE for an affected node, or a signing secret on triggers).
- Write down why, and set a date.

## Upgrade steps
1. Read the release notes for every version between ours and the target.
   Note breaking changes and community-node compatibility.
2. Back up: database dump, the encryption key (N8N_ENCRYPTION_KEY),
   and the .n8n volume.
3. Change the pinned tag in staging, then:
   docker compose pull && docker compose down && docker compose up -d
4. On staging, run our smoke list: [5-10 business-critical workflows],
   one webhook, one schedule trigger, one credential test.
5. Same steps in production, in the agreed window.
6. Check the execution log for errors for 24 hours.
7. Log it: date, old version, new version, advisories closed, who did it.

## Rollback
- Re-pin the previous tag and restart. If the upgrade ran a database
  migration, restore the backup taken in step 2.

## Quarterly
- Review who has n8n accounts and who can create or edit workflows.
- Remove community nodes nobody uses.
- Test a full restore from backup on a spare machine.

Two parts of this deserve extra care.

The encryption key. n8n encrypts stored credentials with an encryption key: the N8N_ENCRYPTION_KEY variable if you set one, otherwise a key n8n generated and saved in the .n8n directory (/home/node/.n8n in Docker). A database backup without that key restores workflows whose credentials can't be decrypted. Back up both, and store them apart.

Accounts and roles. Since 13 of the 15 October advisories need an account on the instance, and 8 need one that can build workflows, user access sits close to version number on the list of what matters. If 40 people can create workflows on your instance and 5 need to, trimming that list shrinks your exposure to a batch like this one, even before you patch.

How to upgrade n8n without breaking your workflows

Upgrade problems on self-hosted n8n tend to come from three places: version jumps, community nodes, and untested credentials.

1. Upgrade in small steps. A move from 2.43 to 2.44 is routine. A move from 1.x to 2.x is a major version, and n8n's release notes say a major version is for "incompatible changes which can require user action". Treat it as a project with its own test plan.
2. Check community nodes first. Custom and community nodes are built outside n8n's own release testing, so check them first. List every community node you run before you upgrade, and test each one on staging.
3. Test credentials, not only workflows. Several October advisories tightened credential permission checks around sub-workflows and some node types. A workflow that relied on one of those gaps, even by accident, could now be blocked. Test it on staging. The Quick Base fix also adds a Where Parameters option; per the advisory, a Where filter built with an expression stays unsafe, so move dynamic values there.
4. Keep the smoke list short and real. Five to ten workflows that would cost money or customers if they stopped. Run them on staging after every upgrade, not every workflow you have.

Tip: to see the exact version a container runs, check the version shown in the n8n UI (Help, then About n8n) or look at the image tag in your Compose file. If the tag is latest, that tag alone doesn't tell you the version.

If your instance has grown into something the business runs on, with many teams, queue mode or high availability, the upgrade process gets heavier. That is the work of n8n enterprise automation: a staging copy of production and worker rollouts, with monitoring that catches a failed upgrade before users do. For a one-off cleanup (pinning, staging, a first upgrade from an old version), n8n consulting is the smaller step.

FAQ

How many security advisories did n8n publish in October 2026?

n8n published 15 GitHub security advisories on October 14, 2026: 4 High and 11 Medium, none with a CVE ID. We counted them on n8n's GitHub security advisories page on 2026-10-27. Note that 4 of the 15 had already been fixed in releases from September 30 and October 1.

Which n8n version fixes the October 2026 vulnerabilities?

Version 2.43.5 or 2.44.1 and later fix the whole October 14 batch on the 2.x line. The current stable release is 2.44.7 (October 26, 2026). On 1.x, 1.123.85 or later covers the 11 advisories that list a 1.x fix; 4 list fixes on 2.x only.

Is self-hosted n8n secure?

Self-hosted n8n can be run securely, but only if someone patches it on a schedule. n8n publishes a batch of advisories every two weeks, most of them need an account on the instance. A pinned version, a staging instance, a named owner and tight user roles make the difference.

Does n8n Cloud need patching?

Not by you: n8n Cloud updates automatically, at least every two weeks according to n8n's docs, and instance owners can pick a faster cadence or a maintenance window. The patch policy in this post is for self-hosted installs. You still own who has accounts and what credentials your workflows hold. If you need self-hosting for data or compliance reasons, plan for the upgrade work or hand it to a maintenance team.

Why doesn't my scanner show these n8n vulnerabilities?

Most n8n advisories never get a CVE ID, and scanners that match only on CVE IDs won't see them. Of the 120 n8n advisories published from July 1 to October 14, 2026, 19 had a CVE ID. Scanners that read GitHub (GHSA) or OSV advisory data can match them; otherwise check the advisories page on the n8n GitHub repository after each batch.

How often should I update self-hosted n8n?

Every two weeks, in line with n8n's advisory batches, with a faster path for anything critical or reachable without a login. n8n's own guide says at least once a month, which can leave you two batches behind. If nobody on your team owns this, hand it to someone outside who will.

Who can help maintain a self-hosted n8n instance?

You can give it to a named internal owner, move to n8n Cloud, or hire an outside team. Our n8n team handles staged upgrades, version pinning and post-upgrade checks for self-hosted instances, and our guide to hiring n8n developers covers what to ask any provider. Ask any provider to put the patch window for High and Critical advisories in the contract.

Sources: n8n GitHub security advisories (all 225 pulled via the GitHub API, 2026-10-27), n8n releases on GitHub, n8n docs: Updating self-hosted n8n, n8n docs: Docker installation and image tags, n8n release notes and versioning