The n8n vulnerability we would put in front of every team running AI automation is not the one in CISA’s catalog. It is a contact form. In March, Pillar Security showed that a public “Contact us” form built in n8n would run shell commands typed into its Name field. The Form node evaluated visitor input as an expression (CVE-2026-27493, CVSS 9.5), and a separate sandbox escape (CVE-2026-27577) turned that expression into code on the host. Nobody had to log in. The form only ever asked for a name.
If you self-host n8n, the short version is this. Upgrade to the current patch on your branch, which as of the September 16 security update is 1.123.80 on 1.x and 2.39.6 on stable 2.x. Treat anyone who can edit a workflow as an administrator of the host. Then keep reading, because the most useful lesson in this story is the one failure that survives every patch.
What happened: a year of n8n vulnerabilities
The sequence matters more than any single bug. In December 2025, n8n patched CVE-2025-68613 (CVSS 9.9), an expression injection that lets an authenticated workflow editor run code with the privileges of the n8n process. On January 7, 2026, Cyera disclosed Ni8mare, CVE-2026-21858 (CVSS 10.0), which needs no account at all. Within days the Canadian Centre for Cyber Security warned of public proofs of concept, including one that chains both bugs into unauthenticated remote code execution.
February brought CVE-2026-25049, a bypass of the December fix, and late February brought four more critical flaws, the contact form among them. On March 11, CISA added CVE-2025-68613 to the Known Exploited Vulnerabilities catalog, the first n8n entry, after Shadowserver had counted more than 24,700 unpatched instances online in early February. Stormshield also reports exploitation attempts against Ni8mare, although CISA had not listed it as of September 30.
The pace has not slowed since. In May, CVE-2026-42226 let a user with access to a shared workflow send another user’s credential to an attacker’s server. n8n now publishes a bi-weekly bulletin, and the September 2 and September 16 releases alone carried 34 advisories, 17 of them rated High.
n8n affected versions and fixed releases
| Issue | Who can exploit it | Fixed in |
|---|---|---|
| CVE-2025-68613, expression injection (KEV) | Workflow editor | 1.120.4, 1.121.1, 1.122.0 |
| CVE-2026-21858, Ni8mare file read to RCE | Anyone who can reach a form | 1.121.0 |
| CVE-2026-25049, bypass of the 68613 fix | Workflow editor | 1.123.17, 2.5.2 |
| CVE-2026-27577 and CVE-2026-27493, sandbox escape plus form evaluation | Anyone who can reach a form, when chained | 1.123.22, 2.9.3, 2.10.1 |
| CVE-2026-42226, credential exfiltration | User with shared workflow access | 1.123.33, 2.17.5, 2.18.0 |
| September 2 bulletin, 18 advisories | Mixed | 1.123.76, 2.37.7 stable, 2.38.2 beta |
| September 16 bulletin, 16 advisories | Mixed | 1.123.80, 2.39.6 stable, 2.40.1 beta |
There is a version trap hiding in that table. n8n still ships security releases on the 1.x line, which is good news for teams that have not migrated and bad news for anyone who reads a January advisory, sees “fixed in 1.121.0”, and stops there. Version 1.121.0 closes Ni8mare and nothing that came after it. n8n Cloud instances are patched automatically, so the trap belongs to self-hosters. CVSS scores in this post are n8n’s own ratings from its GitHub advisories, which NVD sometimes scores differently (it rates CVE-2025-68613 at 8.8).
How the attacks work: the expression sandbox is not a boundary
Most of the authenticated half of that table traces back to one component. Expressions, the {{ }} snippets inside node parameters, run as JavaScript in a sandbox that rewrites code before evaluating it. CVE-2025-68613 escaped that sandbox, and CVE-2026-25049 escaped the fix; the researcher who found both describes the second as a bypass of the first patch. Endor Labs traced it to TypeScript. The sanitizer trusted a compile-time promise that a property would be a string, so at runtime an attacker passed an object or array and skipped the check. Then Pillar found CVE-2026-27577, a missing case in the syntax-tree rewriter that let process through untouched, and the September 2 bulletin added two more escapes.
Four rounds in nine months is not bad luck. A sandbox that rewrites JavaScript is a filter, and filters lose to the next piece of syntax nobody anticipated. In the words of Pillar’s Eilon Cohen, “If you can create a workflow, you can own the server,” which is why we tell teams to read the edit permission literally.
The unauthenticated half of the story runs through forms and webhooks, which are public by design. Ni8mare works because the Form handler never checked that a submission really was multipart/form-data, so an attacker who sends JSON controls the uploaded-file object and can point it at any local file. Where the workflow hands content back, as the knowledge-base chat in Cyera’s demonstration did, that means reading /home/node/.n8n/database.sqlite and the secret in /home/node/.n8n/config from a Docker deployment. Together those forge a valid n8n-auth session cookie, and from an administrator session an Execute Command node finishes the job. The contact form chain is shorter still, because the Form node evaluated the Name field twice and the sandbox escape did the rest.
What the attacker walks away with is the real story. Pillar showed that code execution exposes N8N_ENCRYPTION_KEY, and with it every credential the instance stores, from AWS keys and database passwords to OAuth tokens and API keys. An automation hub is where an organization keeps the keys to everything else it automates.
Why AI automation platforms became a target class
n8n is not alone. As of the September 30 catalog, CISA lists one n8n flaw and six in Langflow, the open-source builder for LLM applications, five of them added during 2026. The oldest, CVE-2025-3248, is flagged for known ransomware use. In July, Sysdig documented what that looks like when an LLM agent drives the intrusion. The operator it calls JADEPUFFER entered through an internet-facing Langflow instance and swept the host for LLM provider keys and cloud credentials. It then dumped Langflow’s own database, opened an internal MinIO store with default credentials, and pivoted to a production database for extortion. At one point it went from a failed login to a working fix in 31 seconds.
Sysdig’s reasons for why Langflow made a good entry point apply to n8n word for word. These servers sit next to AI workloads, hold provider API keys and cloud credentials, and often go up quickly without network controls. JADEPUFFER adds a ransomware case to the attacker shift we covered in offensive agentic AI.
The September bulletins also show where n8n’s newest bugs live, which is in its AI features. One advisory let an inline Agent node tool decrypt any credential on the instance without an ownership check. A NoSQL injection in the MongoDB Chat Memory node exposed other sessions’ chat history without authentication. Three more undermined human approval steps, including one that let an anonymous user reuse a resume token over the chat WebSocket. Approval gates are the control many teams lean on to make AI automation acceptable at all, so three failures in one month says that control needs testing, not assuming.
The flaw a patch will not fix: workflow identity hijacking
Go back to the contact form, and this time assume every patch above is installed. Suppose the form feeds an AI step that reads the message, searches the CRM or a shared mailbox with a service credential, and drafts the reply. Noma Labs calls what happens next Workflow Identity Hijacking. An outsider asks an ordinary question, say for the quarterly figures in the finance director’s last email. The model does exactly what it was built to do, and the workflow answers with privileges the requester never had. There is no injected instruction and no jailbreak, so a guardrail has nothing to catch, which is Noma’s central point. Guardrails filter phrasing, and they were never designed to be an authorization boundary.
That is why our prompt injection defense advice does not cover this case on its own. The test we use instead is the least-trusted party who can influence what an automation acts on. A workflow that only administrators can edit, running at 8 a.m. against a public support inbox, has a least-trusted party of anyone with an email address.
Academic work reached the same conclusion from the other direction. CaMeL separates an agent’s control flow from the untrusted data it reads and checks capabilities at every tool call, so retrieved content can never change what the program does next. In the AgentDojo benchmark it completed 77% of tasks with provable security, against 84% for an undefended agent, which is a fair price for a real boundary. OWASP’s Excessive Agency entry names the same root causes in plainer terms, too much functionality, too many permissions and too much autonomy.
In n8n terms the fixes are concrete. Pass the requester’s identity through the workflow and act with short-lived tokens scoped to that person, the same propagation we argued for in AI agent identity management. Put an authorization check between any LLM output and the action it triggers. Keep the branch that retrieves sensitive data apart from the branch that replies to the outside world. Mapping those boundaries is most of the work in a secure AI deployment review.
How to detect n8n exploitation
Every code-execution chain in this story ends at a shell on the n8n host, whether through an Execute Command node or a sandbox escape. On n8n 2.x that is unusual by design, because version 2.0 disabled the Execute Command node by default, so a shell or downloader under the n8n process tree deserves a look.
Data source: Linux process creation from EDR, auditd or Falco on hosts and containers running n8n, any Sigma backend
title: Shell or Network Utility Spawned by n8n Workflow Automation
id: 017c4c05-ddd9-43da-8c4a-e6f1fedbeb32
status: experimental
description: >
Detects a shell, scripting interpreter or network utility started by the
n8n process or one of its internal task runners. Published research on
CVE-2025-68613, CVE-2026-21858, CVE-2026-25049 and CVE-2026-27577 shows
each chain ending in command execution on the host. n8n 2.x disables the
Execute Command node by default, so matches there are rare.
references:
- https://www.cyera.com/research/ni8mare-unauthenticated-remote-code-execution-in-n8n-cve-2026-21858
- https://thehackernews.com/2026/03/critical-n8n-flaws-allow-remote-code.html
author: MarkCyber Research
date: 2026-10-01
tags:
- attack.initial-access
- attack.t1190
- attack.execution
- attack.t1059.004
- cve.2025-68613
- cve.2026-21858
logsource:
product: linux
category: process_creation
detection:
selection_parent:
ParentImage|endswith: '/node'
ParentCommandLine|contains: 'n8n'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/ash'
- '/busybox'
- '/python3'
- '/perl'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/socat'
- '/base64'
condition: selection_parent and selection_child
falsepositives:
- Workflows that use the Execute Command node on purpose (enabled by default on 1.x)
- Entrypoint or health-check scripts that run inside the n8n process tree
level: highTune it against what your containers actually report before you trust the silence. Alpine-based images often log /bin/busybox for shell commands, which is why it is in the list. With external task runners, code runs in the n8nio/runners sidecar under a separate launcher, so check the parent process name there and add it. If you rely on Execute Command, allowlist those workflows’ exact command lines rather than dropping the rule. For an instance that ran a vulnerable version while exposed, search back to December 2025, when the first of these advisories went public. The rule is also blind to an attacker who never spawns a process and instead reads credentials through workflows or the API, which is why the signals below matter.
Two signals sit outside process telemetry. In reverse proxy logs, a form submission that arrives as application/json where the form expects multipart/form-data is the Ni8mare request shape, and Stormshield’s network signature keys on the same confusion. After any suspected compromise, watch the systems behind your stored credentials. Use of an n8n-held AWS key or OAuth token from an unfamiliar address can be the first sign anyone sees (ATT&CK T1552.001 covers the theft).
n8n security best practices and mitigation
Patching is the floor, and the n8n hardening guide covers the rest well. These are the steps we would take first, in order.
- Upgrade to the latest patch on your branch, and subscribe to the bi-weekly bulletin so the next one is a routine change rather than an incident.
- Restrict workflow creation and editing to people you would trust with a shell on the host, which is n8n’s own workaround for the sandbox escapes.
- Run task runners in external mode. n8n’s documentation calls them the only isolation layer between workflow code and the instance, and internal mode runs as n8n’s own user.
- Keep the editor and public API off the internet, put SSO with MFA in front, and turn on SSRF protection so nodes cannot reach internal addresses you have not approved.
- While a fix is pending, disable public forms and webhooks you do not need, or exclude the Form, Form Trigger and Merge nodes with
NODES_EXCLUDE. n8n says plainly that these workarounds reduce risk without removing it. - If a vulnerable version ever ran with public forms or webhooks, rotate the stored credentials at their source systems. n8n’s key rotation replaces the data key but never
N8N_ENCRYPTION_KEY, and it cannot recall secrets an attacker has already decrypted.
Frequently asked questions
Is n8n safe to self-host?
It can be, if you run it like any other system that holds production credentials. n8n patches quickly and publishes on a fixed schedule, and version 2.0 made the defaults much safer. The risk sits in instances deployed as side projects, internet-facing, on old versions, with every user able to edit workflows. Fix those four things and n8n carries no more risk than the systems it connects to.
Which n8n vulnerabilities are exploited in the wild?
CVE-2025-68613, the expression injection, has been in CISA’s KEV catalog since March 11, 2026. Stormshield reports exploitation attempts against CVE-2026-21858 (Ni8mare), which has public exploits but no KEV listing as of September 30. With public proofs of concept for the chained bugs, we treat every critical n8n flaw on an exposed instance as exploitable.
Does n8n Cloud need patching?
No, n8n patches Cloud instances automatically. Your exposure there lies in who can edit workflows, which credentials they hold, and whether a public form or inbox feeds an AI step that can reach sensitive data, which no vendor patch addresses.
Does upgrading to n8n 2.x fix these by default?
Not by itself. Version 2.0 enabled task runners, blocked environment variable access from the Code node and disabled the Execute Command node, all of which shrink what an exploit can do. But 2.x has needed its own security fixes in 2.5.2, 2.9.3, 2.17.5 and every bulletin since, so staying current on your branch matters as much as the migration.
Bottom line
Patch to 1.123.80 or 2.39.6, treat workflow editors as host administrators, and run task runners in external mode. Then open every public form and inbox that feeds an AI step and ask who the least-trusted sender is and what your workflow will fetch on their behalf. The contact form in Pillar’s research needed a bug to cause harm. The one in your own instance might not.