Skip to main content
VulnerabilityPublished

CVE-2026-27493: n8n · Code Injection

Affects n8nSource CVE Database V5

0

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

CVSS 4.0 base score
9.5Critical
How severe the flaw is on the 0–10 CVSS scale.
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:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 25 Feb 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
n8n-ion8nAffected
  • >=2.10.0 <2.10.1
Fixed in
  • 2.10.1
n8n-ion8nAffected
  • >=2.0.0 <2.9.3
Fixed in
  • 2.9.3
n8n-ion8nAffected
  • <1.123.22
Fixed in
  • 1.123.22
npmn8n-io/n8npkg:npm/n8n-io/n8nOther threatsAffected
  • <1.123.22
  • <2.9.3
  • <2.10.1
Fixed in
  • 1.123.22
  • 2.9.3
  • 2.10.1

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

Community reviews

Loading reviews…