CVE-2026-56354: n8n stored XSS + phishing redirect

CISO Take

n8n's Form Node fails to sanitize HTML in description fields and applies an overly permissive iframe sandbox policy, letting an authenticated user with workflow-creation rights inject persistent JavaScript or craft an open-redirect that end users hit when they open the form. The severity is capped at medium (CVSS 4.1) precisely because the prerequisites are real: the attacker needs a valid low-privilege account and the victim must interact with the malicious form, and impact is limited to integrity (no confidentiality or availability loss) — there's no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei template, so this is not being mass-exploited today. The practical risk concentrates in shared or multi-tenant n8n deployments where workflow-creation access isn't tightly scoped — a malicious insider, contractor, or compromised low-privilege account could stage stored XSS or brand-convincing phishing redirects against employees or customers who trust the instance's domain. Patch to n8n 1.123.24, 2.10.4, or 2.12.0 as soon as it fits the change window; in the interim, restrict who can create or edit workflows and audit existing Form Node description fields for embedded HTML/script tags.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium severity by CVSS (4.1, AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:L/A:N) — network-reachable and low attack complexity, but gated by a privilege requirement (authenticated user with workflow-creation permission) and user interaction (a victim must open the crafted form). No confidentiality or availability impact; integrity impact is low, reflecting the client-side/social-engineering nature of stored XSS and open redirect rather than server compromise. No EPSS score is available, it is not in CISA KEV, and there is no known public exploit or Nuclei template — so real-world exploitation likelihood is currently low, but the barrier to abuse (a script-kiddie-level web vuln class) is trivial once an attacker has the required low-privilege access, which makes this most relevant to multi-tenant or loosely-permissioned n8n environments.

How does the attack unfold?

Malicious Form Creation

An authenticated attacker with workflow-creation permission injects unsanitized HTML/JavaScript into a Form Node's description field and crafts an open-redirect parameter.

Delivery

The attacker shares the form link with a higher-trust victim, framed as a legitimate internal or customer-facing workflow step.

AML.T0052

Client-Side Exploitation

When the victim opens the form, the stored XSS executes in their browser and/or the permissive iframe sandbox allows the redirect to fire, sending them to an attacker-controlled page.

Impact

The attacker harvests session tokens or credentials via the XSS payload or a spoofed phishing page impersonating the legitimate n8n instance.

AML.T0048.000

Malicious Form Creation

An authenticated attacker with workflow-creation permission injects unsanitized HTML/JavaScript into a Form Node's description field and crafts an open-redirect parameter.

Delivery

The attacker shares the form link with a higher-trust victim, framed as a legitimate internal or customer-facing workflow step.

AML.T0052

Client-Side Exploitation

When the victim opens the form, the stored XSS executes in their browser and/or the permissive iframe sandbox allows the redirect to fire, sending them to an attacker-controlled page.

Impact

The attacker harvests session tokens or credentials via the XSS payload or a spoofed phishing page impersonating the legitimate n8n instance.

AML.T0048.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
201.9K OpenSSF 6.7 Pushed 3d ago 51% patched ~6d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

5.4 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 15% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI Required

S Changed

C Low

I Low

A None

What should I do?

1 step

Upgrade n8n to 1.123.24 (1.x branch) or 2.10.4 / 2.12.0 (2.x branch), which fix the HTML sanitization and iframe sandbox policy in the Form Node. Until patched: restrict workflow-creation permissions to trusted, vetted users only (principle of least privilege), and treat any external or low-trust collaborator with workflow-edit access as a risk. Audit existing workflows by exporting workflow JSON and grepping Form Node description fields for <script>, javascript:, onerror=, or other HTML/event-handler patterns. Review form-sharing links for redirect parameters and validate they point only to allow-listed destinations. Add monitoring/alerting on workflow creation or modification events touching Form nodes, and consider a CSP on any page that embeds n8n forms to blunt XSS impact even pre-patch.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Social Engineering Code Execution Agent Plugin AML.T0052 - Phishing

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

ISO 42001

Annex A.6 (System Security) - AI system security controls

Frequently Asked Questions

What is CVE-2026-56354?

n8n's Form Node fails to sanitize HTML in description fields and applies an overly permissive iframe sandbox policy, letting an authenticated user with workflow-creation rights inject persistent JavaScript or craft an open-redirect that end users hit when they open the form. The severity is capped at medium (CVSS 4.1) precisely because the prerequisites are real: the attacker needs a valid low-privilege account and the victim must interact with the malicious form, and impact is limited to integrity (no confidentiality or availability loss) — there's no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei template, so this is not being mass-exploited today. The practical risk concentrates in shared or multi-tenant n8n deployments where workflow-creation access isn't tightly scoped — a malicious insider, contractor, or compromised low-privilege account could stage stored XSS or brand-convincing phishing redirects against employees or customers who trust the instance's domain. Patch to n8n 1.123.24, 2.10.4, or 2.12.0 as soon as it fits the change window; in the interim, restrict who can create or edit workflows and audit existing Form Node description fields for embedded HTML/script tags.

Is CVE-2026-56354 actively exploited?

No confirmed active exploitation of CVE-2026-56354 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-56354?

Upgrade n8n to 1.123.24 (1.x branch) or 2.10.4 / 2.12.0 (2.x branch), which fix the HTML sanitization and iframe sandbox policy in the Form Node. Until patched: restrict workflow-creation permissions to trusted, vetted users only (principle of least privilege), and treat any external or low-trust collaborator with workflow-edit access as a risk. Audit existing workflows by exporting workflow JSON and grepping Form Node description fields for `<script>`, `javascript:`, `onerror=`, or other HTML/event-handler patterns. Review form-sharing links for redirect parameters and validate they point only to allow-listed destinations. Add monitoring/alerting on workflow creation or modification events touching Form nodes, and consider a CSP on any page that embeds n8n forms to blunt XSS impact even pre-patch.

What systems are affected by CVE-2026-56354?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration, human-in-the-loop forms.

What is the CVSS score for CVE-2026-56354?

CVE-2026-56354 has a CVSS v3.1 base score of 5.4 (MEDIUM). The EPSS exploitation probability is 0.24%.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestrationhuman-in-the-loop forms

MITRE ATLAS Techniques

AML.T0052 Phishing

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6 (System Security)

What are the technical details?

Original Advisory

n8n before 1.123.24, 2.10.4, and 2.12.0 (across its 1.x and 2.x branches) contains cross-site scripting and open redirect vulnerabilities in the Form Node due to unsanitized HTML description fields and overly permissive iframe sandbox policies. Authenticated users with workflow creation permissions can inject malicious scripts or redirect parameters to perform stored XSS attacks or phishing redirects against end users.

Exploitation Scenario

An attacker holds a low-privilege n8n account with workflow-creation rights — e.g., a contractor, a shared-tenant customer, or a compromised low-privilege credential. They create or edit a workflow containing a Form Node and embed malicious JavaScript in the HTML description field, plus a crafted redirect parameter exploiting the permissive iframe sandbox. They then share the form link (via email, Slack, or an embedded approval workflow) with a higher-trust employee or external customer. When the victim opens the form — believing it's a legitimate internal automation step — the stored XSS executes in their browser, potentially exfiltrating session tokens, or the open redirect silently forwards them to an attacker-controlled page cloned to look like the organization's n8n instance, harvesting credentials via a convincing phishing flow.

Weaknesses (CWE)

CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Primary CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.