GHSA-w673-8fjw-457c: n8n stored XSS enables

Q: Is GHSA-w673-8fjw-457c actively exploited?

No confirmed active exploitation of GHSA-w673-8fjw-457c has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-w673-8fjw-457c?

1. Patch: Upgrade to n8n 1.123.24, 2.10.4, or 2.12.0 immediately. 2. Restrict permissions: Limit workflow creation and editing to fully trusted users—perform an IAM review of who holds editor roles. 3. Disable if unused: Add 'n8n-nodes-base.form' and 'n8n-nodes-base.formTrigger' to the NODES_EXCLUDE environment variable if Form nodes are not required. 4. Audit existing workflows: Review all Form Node configurations for unsanitized HTML in description fields (iframe tags, script tags) or suspicious external URLs. 5. Detection: Monitor n8n audit logs for workflow edits introducing external URL references or raw HTML in Form Node description fields.

Q: What systems are affected by GHSA-w673-8fjw-457c?

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

Q: What is the CVSS score for GHSA-w673-8fjw-457c?

GHSA-w673-8fjw-457c has a CVSS v3.1 base score of 4.1 (MEDIUM).

CISO Take

Authenticated n8n users with workflow editor permissions can inject malicious HTML into Form Node descriptions or redirect form visitors to arbitrary external URLs, enabling targeted phishing attacks against your workforce. The low privilege bar—any workflow editor—makes this an insider-accessible threat in n8n deployments used for AI automation. Patch to 1.123.24, 2.10.4, or 2.12.0 immediately; if upgrading is blocked, restrict Form node access to fully trusted staff only.

What is the risk?

CVSS rates this medium (4.1), but contextual risk is higher in enterprise n8n deployments where workflow editing is broadly permissioned. The scope-changed flag (S:C) indicates cross-boundary impact: a Form Node visitor—distinct from the authenticated attacker—becomes the victim. In AI orchestration contexts, n8n forms frequently collect sensitive inputs for LLM pipelines, making the phishing surface more valuable to adversaries targeting AI workflow credentials or API keys.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.11.0, < 2.12.0	`2.12.0`
194.3K OpenSSF 6.6 Pushed 6d ago 53% patched ~7d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

4.1 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI Required

S Changed

C None

I Low

A None

What should I do?

5 steps

Patch: Upgrade to n8n 1.123.24, 2.10.4, or 2.12.0 immediately.
Restrict permissions: Limit workflow creation and editing to fully trusted users—perform an IAM review of who holds editor roles.
Disable if unused: Add 'n8n-nodes-base.form' and 'n8n-nodes-base.formTrigger' to the NODES_EXCLUDE environment variable if Form nodes are not required.
Audit existing workflows: Review all Form Node configurations for unsanitized HTML in description fields (iframe tags, script tags) or suspicious external URLs.
Detection: Monitor n8n audit logs for workflow edits introducing external URL references or raw HTML in Form Node description fields.

How is it classified?

Social Engineering Data Extraction Agent Framework AML.T0011.003 - Malicious Link AML.T0048.003 - User Harm AML.T0049 - Exploit Public-Facing Application AML.T0052 - Phishing

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk Management System

ISO 42001

A.9.4 - AI System Security

NIST AI RMF

MANAGE-2.2 - AI Risk Response Mechanisms

OWASP LLM Top 10

LLM05 - Improper Output Handling

Frequently Asked Questions

What is GHSA-w673-8fjw-457c?

Authenticated n8n users with workflow editor permissions can inject malicious HTML into Form Node descriptions or redirect form visitors to arbitrary external URLs, enabling targeted phishing attacks against your workforce. The low privilege bar—any workflow editor—makes this an insider-accessible threat in n8n deployments used for AI automation. Patch to 1.123.24, 2.10.4, or 2.12.0 immediately; if upgrading is blocked, restrict Form node access to fully trusted staff only.

Is GHSA-w673-8fjw-457c actively exploited?

No confirmed active exploitation of GHSA-w673-8fjw-457c has been reported, but organizations should still patch proactively.

How to fix GHSA-w673-8fjw-457c?

1. Patch: Upgrade to n8n 1.123.24, 2.10.4, or 2.12.0 immediately. 2. Restrict permissions: Limit workflow creation and editing to fully trusted users—perform an IAM review of who holds editor roles. 3. Disable if unused: Add 'n8n-nodes-base.form' and 'n8n-nodes-base.formTrigger' to the NODES_EXCLUDE environment variable if Form nodes are not required. 4. Audit existing workflows: Review all Form Node configurations for unsanitized HTML in description fields (iframe tags, script tags) or suspicious external URLs. 5. Detection: Monitor n8n audit logs for workflow edits introducing external URL references or raw HTML in Form Node description fields.

What systems are affected by GHSA-w673-8fjw-457c?

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

What is the CVSS score for GHSA-w673-8fjw-457c?

GHSA-w673-8fjw-457c has a CVSS v3.1 base score of 4.1 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

agent frameworksAI workflow orchestrationhuman-in-the-loop pipelinesLLM integration platforms

MITRE ATLAS Techniques

AML.T0011.003 Malicious Link

AML.T0048.003 User Harm

AML.T0049 Exploit Public-Facing Application

AML.T0052 Phishing

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.9.4

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

## Impact An authenticated user with permission to create or modify workflows could configure a Form Node with an unsanitized HTML description field or exploit an overly permissive iframe sandbox policy to perform stored cross-site scripting or redirect end users visiting the form to an arbitrary external URL. The vulnerability could be used to facilitate phishing attacks. ## Patches The issue has been fixed in n8n versions 1.123.24, 2.10.4 and 2.12.0. Users should upgrade to one of these versions or later to remediate the vulnerability. ## Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Limit workflow creation and editing permissions to fully trusted users only. - Disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable. - 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.

Exploitation Scenario

A malicious insider or compromised workflow editor account creates or modifies an n8n workflow. In the Form Node description, they inject an HTML payload with a credential-harvesting iframe or a JavaScript-based redirect. Legitimate employees receive a link to the internal n8n form—plausibly an AI data collection step or approval gate in an LLM pipeline—and are silently redirected to a convincing SSO phishing page. Harvested credentials are then used to pivot into cloud AI infrastructure, steal LLM API keys, or compromise connected SaaS integrations. The attack is amplified by the fact that the form URL originates from a trusted internal n8n instance.

Weaknesses (CWE)

CWE-601 URL Redirection to Untrusted Site ('Open Redirect') Primary CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Primary

CWE-601 — URL Redirection to Untrusted Site ('Open Redirect'): The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Source: MITRE CWE corpus.