CVE-2026-27493: n8n · Code Injection
Affects n8nSource CVE Database V5
Not known to be exploited · CVSS 9.5 Critical · fixed in 2.10.1 : patch n8n as a priority.
Data as of 26 Oct 2026, 10:12 UTC
- EPSS
- 1.3% chance of exploitation in 30 days – higher than 72% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.10.1, 2.9.3, 1.123.22
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:HExploitation evidence
Disclosed: evidence found.
CVE published 25 Feb 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade n8n and n8n-io/n8n to 2.10.1, 2.9.3 or 1.123.22.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| n8n-ion8n | Affected
| Fixed in
|
| n8n-ion8n | Affected
| Fixed in
|
| n8n-ion8n | Affected
| Fixed in
|
npmn8n-io/n8npkg:npm/n8n-io/n8nOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
The primary mitigation is to upgrade n8n installations to versions 2.10.1, 2.9.3, or 1.123.22 or later, where the vulnerability is fixed. Until upgrades can be performed, administrators should conduct a thorough manual audit of workflows to identify any form nodes that interpolate unauthenticated user input and check for fields starting with '='. If such workflows exist, consider redesigning them to avoid this pattern or restrict access to trusted users only. As a temporary measure, disable the vulnerable Form node by adding 'n8n-nodes-base.form' and the Form Trigger node by adding 'n8n-nodes-base.formTrigger' to the 'NODES_EXCLUDE' environment variable to prevent their use. This reduces attack surface but does not fully eliminate risk, so it should only be a short-term solution. Additionally, monitor n8n logs and network traffic for suspicious activity indicative of exploitation attempts. Implement network segmentation and host-based protections to limit potential damage from a successful compromise. Stay informed about any sandbox escape vulnerabilities that could be chained with this issue and apply patches promptly.
Description
n8n is an open source workflow automation platform. Prior to versions 2.10.1, 2.9.3, and 1.123.22, a second-order expression injection vulnerability existed in n8n's Form nodes that could allow an unauthenticated attacker to inject and evaluate arbitrary n8n expressions by submitting crafted form data. When chained with an expression sandbox escape, this could escalate to remote code execution on the n8n host. The vulnerability requires a specific workflow configuration to be exploitable. First, a form node with a field interpolating a value provided by an unauthenticated user, e.g.a form submitted value. Second, the field value must begin with an `=` character, which caused n8n to treat it as an expression and triggered a double-evaluation of the field content. There is no practical reason for a workflow designer to prefix a field with `=` intentionally — the character is not rendered in the output, so the result would not match the designer's expectations. If added accidentally, it would be noticeable and very unlikely to persist. An unauthenticated attacker would need to either know about this specific circumstance on a target instance or discover a matching form by chance. Even when the preconditions are met, the expression injection alone is limited to data accessible within the n8n expression context. Escalation to remote code execution requires chaining with a separate sandbox escape vulnerability. The issue has been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations. Review usage of form nodes manually for above mentioned preconditions, disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable, and/or disable the Form Trigger node by adding `n8n-nodes-base.formTrigger` to the `NODES_EXCLUDE` environment variable. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
References
- github.com/n8n-io/n8n/security/advisories/GHSA-75g8-rv7v-32f7 (opens in a new tab)
- github.com/n8n-io/n8n/issues/19 (opens in a new tab)
- github.com/n8n-io/n8n/commit/562d867483e871b0f1e31776252e23bd721df75b (opens in a new tab)
- github.com/n8n-io/n8n/releases/tag/n8n@1.123.22 (opens in a new tab)
- github.com/n8n-io/n8n/releases/tag/n8n@2.10.1 (opens in a new tab)
- github.com/n8n-io/n8n/releases/tag/n8n@2.9.3 (opens in a new tab)