Raw vector
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-27493 is a critical-severity Code Injection (CWE-94) vulnerability in N8N N8N. Its CVSS base score is 9.5 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique JavaScript (T1059.007); ranked in the top 33% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-27493 is a second-order expression injection vulnerability in n8n, an open source workflow automation platform. It affects Form nodes in versions prior to 2.10.1, 2.9.3, and 1.123.22. The flaw arises when a form node interpolates a value from an unauthenticated user submission, and that value begins with an equals sign (=), triggering n8n to treat it as an expression and perform a double evaluation of the content. This allows injection and evaluation of arbitrary n8n expressions within the platform's expression context.
An unauthenticated attacker can exploit this by submitting crafted form data to a vulnerable n8n instance hosting a workflow with the specific preconditions: a form node field that interpolates unauthenticated input and interprets a leading = as an expression trigger. Discovery of such a form requires either prior knowledge of the target configuration or chance enumeration, as intentional prefixing with = is unlikely and noticeable to workflow designers. While the injection is confined to data accessible in the n8n expression context, chaining it with a separate expression sandbox escape vulnerability can escalate to remote code execution on the n8n host. The CVSS v3.1 score is 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H), reflecting high impact under constrained conditions.
The vulnerability is fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22, with users advised to upgrade immediately. Temporary mitigations include manually reviewing form node usage for the preconditions, disabling the Form node via the NODES_EXCLUDE environment variable with "n8n-nodes-base.form", or disabling the Form Trigger node with "n8n-nodes-base.formTrigger". These workarounds are short-term only and do not fully eliminate the risk. Details are available in the fixing commit, related GitHub issue, and release notes for the patched versions.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-8756
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.3.1V1.3.2
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation finds code paths that accept and execute externally influenced strings.
Input validation directly stops untrusted data from being used to construct executable code without neutralization.
Least privilege limits the damage an injected code fragment can perform once executed.
Requiring documented secure development standards and tools enforces use of safe code-generation APIs and escaping.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
PR.PS-06's SDLC practices directly target injection flaws via secure coding and testing (mostly), yet as a single broad outcome it leaves many code-generation specifics unaddressed (partial).
PR.DS-10 protects runtime data confidentiality/integrity but has no bearing on neutralizing externally influenced input during code generation, so neither direction shows any preventive effect.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect eval injection vulnerabilities before deployment.
Secure development life cycle mandates input validation and safe coding practices that directly prevent eval injection.
Application security requirements include rules against dynamic code execution of untrusted input.
Secure architecture principles discourage unsafe dynamic evaluation constructs.
Banning unapproved code samples and unauthenticated web services, combined with secure-coding standards and SAST, prevents the dynamic generation or inclusion of attacker-supplied code.
Separation of environments limits the blast radius if eval injection occurs in non-production.