The n8n repository published 58 security advisories between 15 August and 30 September 2026 (33 high, 25 medium, none critical) in four batches of 9, 19, 16 and 14, out of 210 in its history. Only 17 of the 58 carry a CVE ID, so a scanner keyed on CVEs or the global GitHub Advisory Database sees 41 fewer than exist. The minimum fixed version for the window is 1.123.83 on the 1.x line, 2.41.4 on 2.41 and 2.42.1 on 2.42, but 2.42.1 was a prerelease: the first stable 2.42.x is 2.42.3, released on 5 October. On 6 October the versions to run are 2.42.3, 2.41.7 or 1.123.83, and any 2.x line at 2.40 or below has no fix for the 30 September batch. 24 advisories list no 1.x fix at all. Most of the 58 need a specific configuration: five bypass a human approval step, one turns write access to Redis in queue mode into npm installs on every worker, and 13 expose credentials to someone with editor or member access. Start by checking the version on every n8n instance you run against the per-line table.
n8n security vulnerabilities arrived faster in September 2026 than in any month of the project's history: 49 repository advisories in one month, against 30 in July, the previous high. Count from 15 August to 30 September and the n8n repository published 58 advisories, 33 high and 25 medium, with nothing rated critical. The repository now carries 210 in total.
If you run n8n inside a bank, insurer or hospital network, two questions land on your desk at once: which version are we on, and which of these apply to us. A severity-sorted list answers neither. Most of the 58 only matter if you run a particular configuration: queue mode, a public Chat or Form trigger in front of an approval step, the Git node, a database node fed by webhook input, or editors sharing workflows that hold the owner's credentials.
Triage by configuration first and severity second, then run the newest stable release in your line. The Ni8mare chain from earlier in the year is out of scope here; our n8n CVE-2026-21858 hardening guide covers it, along with a general hardening checklist.
n8n security vulnerabilities: 58 advisories in six weeks
The advisories came in four batches, each with a fixed release on three lines on the same day:
One 19 August advisory, GHSA-jp9j-jr97-w9pj (an SSRF check that validated a different field from the one the request used), was fixed earlier, in 2.33.4 and 2.34.1.
Look at the CVE column. Only 17 of the 58 have a CVE ID, all from the early September batch, and those 17 are exactly the window advisories that appear in the global GitHub Advisory Database. The other 41 exist only on the n8n repository's own advisory list. The global database lists 174 n8n advisories against the repository's 210.
That gap is the first thing to explain to your vulnerability management team. A scanner that matches installed packages against CVEs, or against the global advisory feed, saw 17 n8n issues in this window when there were 58. Your dashboard is not lying about what it knows. It just does not know about 41 of them. Use the repository count, record findings by GHSA ID, and say "advisories", not "CVEs", in the change request.
| Published | Advisories | With a CVE ID | 1.x fix | Stable 2.x fix that day | Higher 2.x fix (prerelease that day) |
|---|---|---|---|---|---|
| 19 August | 9 | 0 | 1.123.73 | 2.35.4 | 2.36.2 |
| 2 and 3 September | 19 | 17 | 1.123.76 | 2.37.7 | 2.38.2 |
| 16 September | 16 | 0 | 1.123.80 | 2.39.6 | 2.40.1 |
| 30 September | 14 | 0 | 1.123.83 | 2.41.4 | 2.42.1 |
Which n8n version to run on each release line
The last two columns of the batch table hide a trap. On every advisory day in this window, the higher 2.x version named as the fix was a prerelease. The stable-channel fix was the lower number. On 30 September, a team that read "fixed in 2.42.1" and upgraded put a prerelease into production; the stable fix that day was 2.41.4.
The 2.42 line stayed in prerelease for a week: 2.42.0 (29 September), 2.42.1 (30 September) and 2.42.2 (1 October) were all prereleases. The first stable 2.42.x was 2.42.3 on 5 October, and its release notes list bug fixes and a feature, no security entries. On 6 October, 2.43.0 shipped as a prerelease.
Run the newest stable release in your line, not the version named in the advisory and not whatever a moving tag resolves to this morning. The same rule applies to every self-hosted component with several maintained lines; we walked through it for model serving in the Triton Inference Server version floor guide.
The 1.x line
The 1.123.x line still gets point releases, and it got a fix in every batch. But 24 of the 58 advisories list no 1.x range at all. Several of them concern the Agents module or Instance AI, which are not module names on the 1.x line, yet none of those advisories says 1.x is unaffected. Write them in your register as "no 1.x fix listed" and do not close them as not applicable. Three advisories go the other way and list only a 1.x range: GHSA-r6g9-5cpp-ppwr and GHSA-866p-xg8v-g2q7 (fixed in 1.123.83) and GHSA-7gjv-rcf8-x5qc (fixed in 1.123.80). All three let someone with editor or member access reach credentials or identity they should not. If the CVE-2026-21858 post is your reference for a safe version, note that its 1.121.0 is no longer one: every 1.x fix in this window is 1.123.73 or later, and the floor is now 1.123.83.
| Release line | Minimum fixed for the 58 | Newest stable on 6 October 2026 | Notes |
|---|---|---|---|
| 1.x | 1.123.83 | 1.123.83 | 24 advisories list no 1.x fix |
| 2.41 | 2.41.4 | 2.41.7 | 2.41.4 was the stable fix on 30 September |
| 2.42 | 2.42.1 (prerelease) | 2.42.3 | 2.42.0 to 2.42.2 were prereleases |
| 2.40 and older 2.x | no fix for the 30 September batch | not applicable | Move to 2.41.7 or 2.42.3 |
| 2.43 | not applicable | none (2.43.0 is a prerelease) | Not for production yet |
n8n vulnerability list by configuration
Every one of the 58 sits in exactly one row below. Read down the first column and mark the rows that describe your deployment; those are the advisories to prioritise if you cannot upgrade today.
The counts add to 58. The largest row needs no unusual configuration at all: 13 advisories turn on who can edit a workflow that holds someone else's credentials. GHSA-9rhv-fhr8-7q5r (high, 8.3) lets an ordinary member register a node tool on an inline agent, name any credential ID, including the owner's, and have the decrypted secret sent to a host of their choosing. The advisory states that credential IDs are not secret: they appear in workflow JSON, exports and editor URLs. GHSA-x25p-9mr6-cwgp (high, 7.2) is the shared-workflow version: the save-time credential check looked at a node's credentials field, while the agent node keeps model and per-tool credential IDs in its parameters. Several of these send a secret to a host the attacker chooses, which is why outbound control on the n8n host matters as much as the patch; the AI agent data exfiltration channels audit covers that side.
In the database row, GHSA-5qpp-pqww-h7fp (high, 7.0) is SQL injection in version 1 of the Microsoft SQL node, which substitutes expressions in the Query field straight into SQL, and it lists no 1.x fix. The advisory's workaround for anyone who cannot upgrade yet is to re-add the node so it is created at type version 1.1 or later and to pass values through Query Parameters. Parameterised values are the right pattern on any version, so list every workflow still on version 1 of that node.
The public trigger row includes GHSA-4c7j-qff5-r9cx (medium, 6.3): webhook resolution matched dynamic-path webhooks on the path alone, so a request that omitted the server-generated ID still ran the workflow under its project's credentials. Node-level authentication (Basic, Header or JWT) still applied. The same resolver serves form and MCP routes.
| Your configuration | Advisories | Worst impact | Stopgap until you upgrade |
|---|---|---|---|
| Human approval steps (Send-and-Wait, Wait, chat approvals, agent tool approvals) | 5 | Approval released without the approver | Remove public triggers in front of approval steps that gate high-consequence actions |
| Workflows shared with editors or members while holding the owner's credentials | 13 | Owner credentials decrypted or used by another user | Cut editor access on workflows holding owner credentials |
| Database and query nodes with webhook, chat or form fields bound into the query by expression | 8 | SQL, NoSQL and filter injection, bulk data read | Bind untrusted input through query parameters, not expressions |
| Public Chat, Form or Webhook triggers | 5 | Anonymous workflow execution, chat history read, stored XSS | Node-level authentication on every public trigger |
| Git node | 5 | Command execution as the n8n user | Exclude the Git node (full list, see below) |
| Anyone who can author workflows (expression sandbox) | 4 | Code execution in the main n8n process | Restrict workflow authoring to fully trusted users |
| MCP server and OAuth server endpoints | 4 | Owner account takeover, unauthenticated storage exhaustion | Disable the instance-level MCP server if unused, MFA on owner and admin accounts |
| Queue mode with Redis | 1 | Any npm package installed on every worker | Redis authentication and network controls, community packages off |
| Instance AI credential setup | 1 | Credential sent to an attacker-chosen URL, with user interaction | Disable the instance-ai module |
| OIDC configured once, then disabled | 1 | Valid sessions from a disabled login path | Revoke the client at the identity provider |
| Everything else: member-level authorization gaps, XSS, SSRF, denial of service | 11 | Cross-project data disclosure, stored XSS | Upgrade |
n8n Send and Wait approval bypass: five advisories
Send-and-Wait and the Wait node are how an n8n workflow puts a human sign-off in front of a payment, a record change or an outbound message. Five advisories in the window bypass that step, each with a different precondition. They matter more than their scores suggest because of one sentence in GHSA-728h-pmr2-7cgh: once the approval is released, everything downstream runs under the workflow owner's credentials, which depending on the workflow can reach command execution.
GHSA-728h-pmr2-7cgh carries the title "unauthenticated approval", and that needs reading carefully. The waiting-webhook endpoint accepts a Send-and-Wait node reference in two forms, and it decided which validation to apply before normalising the second form, so requests in that form skipped the HMAC check. The caller still needs the execution's resume token. "Unauthenticated" here means no n8n account, not anyone on the internet.
GHSA-35jj-42hp-8gmq shows where such a token comes from. The /chat WebSocket route resumed a paused execution from a resume token without checking that the waiting node was a chat node, and n8n hands that token to anonymous Form submitters. A Form Trigger feeding a Send-and-Wait, Slack, Telegram or Gmail approval, or a plain Wait, on a public instance let someone with no account release the gate. GHSA-342v-gmh6-738j is simpler: Approve Within Chat mode accepted a resume request without checking it came from Slack or Telegram and without applying the approver allow-list, so anyone who could see the approval message could advance the execution.
The last two need an account. GHSA-597w-c3jh-g8fg let anyone able to save a workflow mint a signed approval URL for a gate in a project they cannot read, valid for every future execution, because the signature was not bound to the workflow, project or owner. GHSA-p3pg-xw4f-m72c let any project member read another member's private agent conversations and answer their pending tool approval.
If an approval step is a documented control in your environment, the exposure to look for is a public trigger anywhere upstream of it. For how to design the approval itself, see our guide to human-in-the-loop approval for AI agents; this section is only about the n8n mechanics.
| Advisory | Severity | What the attacker needs | Fixed in |
|---|---|---|---|
| GHSA-728h-pmr2-7cgh | High, 7.0 | The execution's resume token | 2.41.4, 2.42.1 (no 1.x fix listed) |
| GHSA-35jj-42hp-8gmq | Medium, 6.3 | A public Form Trigger in front of a non-chat approval gate | 2.37.7, 2.38.2 (no 1.x fix listed) |
| GHSA-342v-gmh6-738j | Medium, 6.3 | Sight of the approval message, Approve Within Chat mode, public HTTPS instance | 2.39.6, 2.40.1 (no 1.x fix listed) |
| GHSA-597w-c3jh-g8fg | High, 7.0 | Permission to save any workflow | 1.123.80, 2.39.6, 2.40.1 |
| GHSA-p3pg-xw4f-m72c | Medium, 6.1 | Membership of the same project | 2.41.4, 2.42.0 (no 1.x fix listed) |
n8n AI Agent, $fromAI and MCP server vulnerabilities
One of the three highest-scored advisories in the window, GHSA-9x83-43r8-5hwc (high, CVSS 4.0 8.7), sits in an AI feature. $fromAI resolved a placeholder name without an own-property check and returned a live reference to a host prototype. From there an expression could reach the Function constructor and run code in the main n8n process "from workflow-build privilege alone". It is fixed in 1.123.73, 2.35.4 and 2.36.2.
Three more expression sandbox escapes landed in the same window: GHSA-fg85-4wv2-p98j (a SpreadElement bypass, no 1.x fix listed), GHSA-hw8v-xxg5-vvvx (class-field sanitizer rebinding, 8.7) and GHSA-6xcw-7xm6-48c6 (shared builtin tampering plus code-printer injection), the last two fixed in 1.123.76, 2.37.7 and 2.38.2. All four need someone who can author workflows, which is why the advisories repeat the same workaround: restrict instance access to fully trusted users. Treat "can edit a workflow" as "can run code on the n8n host", and decide what isolation sits beneath the application sandbox; our smolvm vs Firecracker comparison covers that layer.
MCP, Instance AI and chat memory
GHSA-5jr4-xmvf-frmj (high, 7.7) is the one to read if you enabled the instance-level MCP server. Its workflow-validation tool evaluated caller code in the main process through an interpreter that allowed assignment onto shared prototypes, so a member with only a read grant could make a permission check pass, and the reporter took it to full owner account takeover. The advisory states that accounts protected by MFA are not affected. Its workarounds are to disable the instance-level MCP server, turn on MFA for owner and admin accounts, and revoke MCP OAuth grants that carry workflow:read. Broader MCP hardening is in our MCP server security checklist. GHSA-q5wm-mgqx-fv2f (medium, 5.9) is SSRF to exfiltration in Instance AI credential setup, which accepted a probe URL that did not match the node's origin. It requires the user to bring an attacker-controlled URL into the setup flow, so it is not an unauthenticated SSRF. GHSA-w24g-6454-7w7f (high, 7.0) affects only workflows that combine a Chat Trigger with no authentication and a MongoDB Chat Memory node: the session ID came from the request body unvalidated, and a MongoDB operator in its place let a visitor read, write or delete other users' chat histories.
The module switch that does not work as written
The workarounds for GHSA-q5wm-mgqx-fv2f and GHSA-p3pg-xw4f-m72c say to disable Instance AI or the Agents module by removing it from N8N_ENABLED_MODULES. On 2.42.1, instance-ai, agents, mcp and community-packages are all default modules, and n8n loads the defaults plus N8N_ENABLED_MODULES, minus N8N_DISABLED_MODULES. Removing a name from the enabled list does nothing when it was never there. The switch that works is N8N_DISABLED_MODULES=instance-ai,agents, comma-separated. Module names are validated, and an unknown name stops n8n at startup. On the 1.x line, agents and instance-ai are not valid module names, so this setting is for 2.x only.
n8n queue mode, Redis, community packages and the Git node
GHSA-fmmv-p585-7c8x (high, CVSS 4.0 7.5, adjacent network) only applies in queue mode, where EXECUTIONS_MODE=queue puts Redis between the main instance and its workers. The internal PubSub handler that installs a community package skipped name and prefix validation, the install-permission check, checksum verification and the npm safety check. Anyone able to write to that Redis could make every instance in the cluster download, install and load any npm package, with no n8n account. It is fixed in 1.123.80, 2.39.6 and 2.40.1.
The upgrade closes the handler. The underlying lesson does not change with the version: write access to the Redis behind n8n queue mode is a control plane for your whole cluster, so it needs authentication, TLS and a network policy that admits only n8n processes. N8N_COMMUNITY_PACKAGES_ENABLED defaults to true, so turn it off unless you use community nodes, and audit the packages already installed.
# Upgrade first. These settings narrow exposure while you schedule it. # Modules you do not use: disable them. N8N_ENABLED_MODULES only ADDS to the # defaults, so removing a name from it does nothing. Unknown names fail at startup. N8N_DISABLED_MODULES=agents,instance-ai,community-packages # Community packages off (GHSA-fmmv-p585-7c8x) N8N_COMMUNITY_PACKAGES_ENABLED=false # Exclude the Git node. Setting NODES_EXCLUDE replaces the default list, # so keep Execute Command and Local File Trigger in it. NODES_EXCLUDE=["n8n-nodes-base.executeCommand","n8n-nodes-base.localFileTrigger","n8n-nodes-base.git"] # Queue mode: Redis must require auth and use TLS EXECUTIONS_MODE=queue QUEUE_BULL_REDIS_HOST=redis.internal QUEUE_BULL_REDIS_USERNAME=n8n QUEUE_BULL_REDIS_PASSWORD=<from your secret store> QUEUE_BULL_REDIS_TLS=true
Five Git node advisories
The Git node collected five advisories. Two lead to code execution as the n8n user: GHSA-mwp5-2m32-r54h, through repository config keys for content filters and merge drivers during Add, Commit, Checkout and Pull, and GHSA-x8wx-g24x-3549, through the Log operation, which skipped config neutralisation. The second advisory adds that the node is also usable as an agent tool. The others are GHSA-j535-v25q-vx3q (ReDoS through a clone path), GHSA-fm93-2x43-6676 (file sandbox escape through a relative remote URL) and GHSA-qgpw-8g46-w95v (local repository read through branch.<name>.remote). The advisories' workaround is to add n8n-nodes-base.git to NODES_EXCLUDE. Do not set it to that alone. On 2.42.1 and 2.41.7, the default value is ["n8n-nodes-base.executeCommand","n8n-nodes-base.localFileTrigger"], and setting the variable replaces the default rather than extending it. NODES_EXCLUDE=["n8n-nodes-base.git"] blocks Git and quietly re-enables Execute Command and Local File Trigger. Always print the full list. If you keep the Git node, leave N8N_GIT_NODE_ENABLE_HOOKS and N8N_GIT_NODE_ENABLE_ALL_CONFIG_KEYS at their default of false.
A stopgap block for 2.41 and 2.42
This block is for a 2.41.x or 2.42.x instance in queue mode that does not use the Agents module, Instance AI, community packages or the Git node. Every name in it exists at 2.42.1. Remove any line that disables something you use, and do not treat it as a substitute for the upgrade. The MCP server is deliberately absent. The advisory wording is to disable the instance-level MCP server if you do not use it, and the OAuth server that backs it is a separate default module, so check your own routes after any change rather than assuming one module name removes both.
Self-hosted n8n in regulated environments: what changes
Running n8n inside a regulated perimeter changes the triage in four places.
First, the anonymous rows shrink, but only if the triggers really are internal. The public trigger, Form-plus-approval and OAuth endpoint advisories need an attacker who can reach the instance. If your Chat, Form and Webhook triggers are behind the corporate network with node-level authentication, those rows drop in priority. If one webhook is published to a partner or a customer portal, they come straight back.
Second, much of what remains needs only a member or editor account. The 13 credential-exposure advisories, the four sandbox escapes and the project-membership bugs are insider and least-privilege findings. An auditor will ask who holds editor access to workflows that carry the owner's database or payment-system credentials, and "everyone in the automation team" is not an answer that survives the review.
Third, the approval bypasses go straight at the control. Where a human sign-off before a consequential action is a documented control under your finance or healthcare framework, a bypass of that step is a control failure, not just a software bug, and it belongs in the risk register with the five GHSA IDs.
Fourth, the CVE gap matters most where vulnerability management runs on CVE-keyed tooling and its reports go to a board or a regulator. On the post date, 41 of the 58 had no CVE. Owner and admin MFA blocks the account takeover in GHSA-5jr4-xmvf-frmj, which states that MFA-protected accounts are not affected, and it needs no upgrade window.
If Open WebUI is the chat front end beside your n8n, it has the same shape of problem; our Open WebUI vulnerabilities triage maps its advisories the same way. For the wider set of controls across self-hosted AI services, the AI security pillar collects them.
n8n security updates: what to do this week
N8N_DISABLED_MODULES for the modules you do not use, and if you exclude the Git node, keep the two default entries in NODES_EXCLUDE.The first item decides how urgent the rest are.
FAQ
Quick answers to the questions this post tends to raise.
