GHSA-xmc9-4f2h-jf9c: n8n Edit Image node path

Q: Is GHSA-xmc9-4f2h-jf9c actively exploited?

No confirmed active exploitation of GHSA-xmc9-4f2h-jf9c has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-xmc9-4f2h-jf9c?

1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later immediately. 2) If upgrade isn't immediate, restrict n8n instance access to fully trusted users only and set `NODES_EXCLUDE` to include `n8n-nodes-base.editImage` to disable the vulnerable node. 3) Audit existing workflows for Edit Image node usage and review recent executions for unexpected output paths or file writes outside the working directory. 4) Review user/role permissions to minimize the number of accounts that can create or edit workflows. 5) Monitor file-integrity on the n8n host for unexpected writes to config or startup directories as a detection signal.

Q: What systems are affected by GHSA-xmc9-4f2h-jf9c?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration.

Q: What is the CVSS score for GHSA-xmc9-4f2h-jf9c?

No CVSS score has been assigned yet.

CISO Take

n8n's Edit Image node passes a user-supplied output format straight to the underlying image library without validating the path, letting any authenticated workflow author write arbitrary files outside the node's working directory (CWE-73, path traversal). This requires an authenticated account able to run workflows, not an anonymous attacker, but n8n is a widely used AI agent/automation backbone — the package carries 166 other disclosed CVEs and a below-average OpenSSF Scorecard of 6.6/10, signaling a codebase with a large, active attack surface that's frequently exposed to third-party integrations and low-trust users. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so opportunistic mass exploitation is unlikely today, but an authenticated arbitrary-file-write primitive is a well-known stepping stone to config overwrite, credential theft, or full remote code execution once chained. Patch immediately to n8n 1.123.67, 2.31.5, or 2.32.1; if you can't patch now, restrict instance access to fully trusted users and add `n8n-nodes-base.editImage` to `NODES_EXCLUDE`, and audit who currently holds workflow-editing rights on internet-facing n8n instances.

Sources: GitHub Advisory ATLAS OpenSSF

What is the risk?

Severity is rated high, but real-world exploitability is gated by the requirement for an authenticated user with workflow-execution rights — this is not a pre-auth remote vulnerability. The risk profile is elevated by n8n's role as an AI agent orchestration platform (frequently exposed to less-trusted collaborators, contractors, or automated integrations building workflows) and by broader package health signals: 166 other CVEs recorded in this package and an OpenSSF Scorecard of 6.6/10 suggest a security posture that warrants ongoing scrutiny beyond this single advisory. Absent KEV listing, EPSS scoring, or public PoC, treat this as a priority patch item rather than an active-exploitation emergency.

How does the attack unfold?

Authenticated Access

Attacker obtains or already holds an n8n user account with permission to create or edit workflows.

AML.T0012

Malicious Node Configuration

Attacker configures an Edit Image node with a path-traversal payload in the output format field.

Arbitrary File Write

Workflow execution passes the unvalidated value to the image library, writing attacker-controlled bytes outside the node's working directory.

AML.T0079

Persistence / Impact

Written files overwrite configuration or plant new files, enabling persistence or broader compromise of the n8n instance.

AML.T0112

Authenticated Access

Attacker obtains or already holds an n8n user account with permission to create or edit workflows.

AML.T0012

Malicious Node Configuration

Attacker configures an Edit Image node with a path-traversal payload in the output format field.

Arbitrary File Write

Workflow execution passes the unvalidated value to the image library, writing attacker-controlled bytes outside the node's working directory.

AML.T0079

Persistence / Impact

Written files overwrite configuration or plant new files, enabling persistence or broader compromise of the n8n instance.

AML.T0112

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.67	`1.123.67`
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later immediately. 2) If upgrade isn't immediate, restrict n8n instance access to fully trusted users only and set NODES_EXCLUDE to include n8n-nodes-base.editImage to disable the vulnerable node. 3) Audit existing workflows for Edit Image node usage and review recent executions for unexpected output paths or file writes outside the working directory. 4) Review user/role permissions to minimize the number of accounts that can create or edit workflows. 5) Monitor file-integrity on the n8n host for unexpected writes to config or startup directories as a detection signal.

How is it classified?

Code Execution Agent AML.T0079 - Stage Capabilities AML.T0081 - Modify AI Agent Configuration AML.T0112 - Machine Compromise

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MANAGE 4.1 - Post-deployment monitoring and incident response for AI system risks

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is GHSA-xmc9-4f2h-jf9c?

n8n's Edit Image node passes a user-supplied output format straight to the underlying image library without validating the path, letting any authenticated workflow author write arbitrary files outside the node's working directory (CWE-73, path traversal). This requires an authenticated account able to run workflows, not an anonymous attacker, but n8n is a widely used AI agent/automation backbone — the package carries 166 other disclosed CVEs and a below-average OpenSSF Scorecard of 6.6/10, signaling a codebase with a large, active attack surface that's frequently exposed to third-party integrations and low-trust users. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so opportunistic mass exploitation is unlikely today, but an authenticated arbitrary-file-write primitive is a well-known stepping stone to config overwrite, credential theft, or full remote code execution once chained. Patch immediately to n8n 1.123.67, 2.31.5, or 2.32.1; if you can't patch now, restrict instance access to fully trusted users and add `n8n-nodes-base.editImage` to `NODES_EXCLUDE`, and audit who currently holds workflow-editing rights on internet-facing n8n instances.

Is GHSA-xmc9-4f2h-jf9c actively exploited?

No confirmed active exploitation of GHSA-xmc9-4f2h-jf9c has been reported, but organizations should still patch proactively.

How to fix GHSA-xmc9-4f2h-jf9c?

1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later immediately. 2) If upgrade isn't immediate, restrict n8n instance access to fully trusted users only and set `NODES_EXCLUDE` to include `n8n-nodes-base.editImage` to disable the vulnerable node. 3) Audit existing workflows for Edit Image node usage and review recent executions for unexpected output paths or file writes outside the working directory. 4) Review user/role permissions to minimize the number of accounts that can create or edit workflows. 5) Monitor file-integrity on the n8n host for unexpected writes to config or startup directories as a detection signal.

What systems are affected by GHSA-xmc9-4f2h-jf9c?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration.

What is the CVSS score for GHSA-xmc9-4f2h-jf9c?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration

MITRE ATLAS Techniques

AML.T0079 Stage Capabilities

AML.T0081 Modify AI Agent Configuration

AML.T0112 Machine Compromise

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

## Impact The n8n Edit Image node passed its output format to the underlying image library without validation, so a crafted value could write bytes to a location outside the node's working directory. An authenticated user able to run workflows could use this to write arbitrary files in the n8n instance. ## Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. 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: - Restrict n8n instance access to fully trusted users only. - Disable the Edit Image node by adding `n8n-nodes-base.editImage` 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 contractor or low-privileged employee with workflow-editing access to a shared n8n instance creates or modifies a workflow containing an Edit Image node, supplying a crafted output format value containing path-traversal sequences (e.g., `../../../`). When the workflow executes, the underlying image library writes the processed image bytes to the attacker-chosen path instead of the node's sandboxed working directory — potentially overwriting the n8n `.env` file, injecting a script into a location loaded at startup, or dropping a web-accessible file if the instance serves static content from a writable path, giving the attacker a foothold or persistence beyond their original workflow permissions.

Weaknesses (CWE)

CWE-73 External Control of File Name or Path Primary

CWE-73 — External Control of File Name or Path: The product allows user input to control or influence paths or file names that are used in filesystem operations.

[Architecture and Design] When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.
[Architecture and Design, Operation] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.