CVE-2026-56352: n8n legacy node bypasses file path

CISO Take

n8n's legacy ExecuteWorkflow node still exposes a localFile option through the REST API that skips the file-access checks the UI enforces elsewhere, letting an authenticated user with workflow-edit rights ignore N8N_RESTRICT_FILE_ACCESS_TO and probe for arbitrary files on the host, and load and execute any valid workflow JSON it finds. There's no CISA KEV listing, no public exploit or Nuclei template, and EPSS data isn't available, so this reads as a low-noise, authenticated-only bug rather than an internet-mass-exploitation risk — but n8n sits at the center of many AI agent pipelines with 16 downstream dependents and an OpenSSF Scorecard of only 6.6/10, so a single over-privileged user account (contractor, low-trust teammate, or compromised credential) becomes a path to host file disclosure and arbitrary workflow execution. The bug requires low privileges and no user interaction (CVSS 6.4, AV:N/AC:L/PR:L), meaning any workflow-editor role is enough to trigger it. Patch to n8n 2.19.3 or later; until then, audit who holds workflow create/edit permissions, tighten N8N_RESTRICT_FILE_ACCESS_TO scoping at the OS/filesystem level rather than relying on the app-layer check, and monitor REST API calls invoking ExecuteWorkflow with a localFile source for anomalous path values.

Sources: NVD GitHub Advisory OpenSSF ATLAS

What is the risk?

Medium severity (CVSS 6.4) but non-trivial in practice: exploitation requires only low privileges (a workflow-editor role) and no user interaction, and it's reachable purely via REST API even though hidden from the UI since v1.2 — meaning any authenticated abuse-of-privilege or credential compromise scenario can trigger it without needing UI access. No active exploitation signals exist (not in CISA KEV, no EPSS score, no public exploit or scanner template), so this is a patch-priority item rather than an emergency, but n8n's role as an AI agent orchestration platform (16 dependents, 136 other CVEs in the package, OpenSSF Scorecard 6.6/10) raises the blast-radius ceiling if left unpatched in multi-tenant or loosely-permissioned deployments.

How does the attack unfold?

Initial Access

An adversary obtains or already holds an authenticated n8n account with workflow create/edit permissions.

AML.T0012

Discovery

Using the REST API, the adversary configures the legacy ExecuteWorkflow node's localFile option to bypass N8N_RESTRICT_FILE_ACCESS_TO and probe for arbitrary files on the host.

AML.T0037

Execution

When a probed path resolves to a valid workflow JSON file, n8n loads and executes it via the ExecuteWorkflow node.

AML.T0053

Impact

The adversary gains disclosure of host file existence/paths and executes attacker-reachable workflow logic outside their intended permission scope, risking credential exposure or cross-tenant workflow compromise.

Initial Access

An adversary obtains or already holds an authenticated n8n account with workflow create/edit permissions.

AML.T0012

Discovery

Using the REST API, the adversary configures the legacy ExecuteWorkflow node's localFile option to bypass N8N_RESTRICT_FILE_ACCESS_TO and probe for arbitrary files on the host.

AML.T0037

Execution

When a probed path resolves to a valid workflow JSON file, n8n loads and executes it via the ExecuteWorkflow node.

AML.T0053

Impact

The adversary gains disclosure of host file existence/paths and executes attacker-reachable workflow logic outside their intended permission scope, risking credential exposure or cross-tenant workflow compromise.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
205.4K OpenSSF 6.7 Pushed 2d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

6.4 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 26% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C Low

I Low

A None

What should I do?

1 step

Upgrade n8n to 2.19.3 or later, where the legacy ExecuteWorkflow localFile path enforces the same access checks as other file-reading nodes. Until patched, review and restrict who holds workflow create/modify permissions — treat that role as equivalent to file-system access on the host. Harden N8N_RESTRICT_FILE_ACCESS_TO with OS-level controls (containerization, chroot, read-only mounts) rather than relying solely on the application-layer restriction. Add detection for REST API calls to ExecuteWorkflow nodes specifying a localFile source, especially with path traversal patterns (../, absolute paths outside the workflows directory), and review n8n audit/access logs for workflow-permission users making unusual API calls outside the normal editor UI.

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?

Auth Bypass Code Execution Data Leakage Agent Plugin AML.T0012 - Valid Accounts AML.T0037 - Data from Local System AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluation

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-56352?

n8n's legacy ExecuteWorkflow node still exposes a localFile option through the REST API that skips the file-access checks the UI enforces elsewhere, letting an authenticated user with workflow-edit rights ignore N8N_RESTRICT_FILE_ACCESS_TO and probe for arbitrary files on the host, and load and execute any valid workflow JSON it finds. There's no CISA KEV listing, no public exploit or Nuclei template, and EPSS data isn't available, so this reads as a low-noise, authenticated-only bug rather than an internet-mass-exploitation risk — but n8n sits at the center of many AI agent pipelines with 16 downstream dependents and an OpenSSF Scorecard of only 6.6/10, so a single over-privileged user account (contractor, low-trust teammate, or compromised credential) becomes a path to host file disclosure and arbitrary workflow execution. The bug requires low privileges and no user interaction (CVSS 6.4, AV:N/AC:L/PR:L), meaning any workflow-editor role is enough to trigger it. Patch to n8n 2.19.3 or later; until then, audit who holds workflow create/edit permissions, tighten N8N_RESTRICT_FILE_ACCESS_TO scoping at the OS/filesystem level rather than relying on the app-layer check, and monitor REST API calls invoking ExecuteWorkflow with a localFile source for anomalous path values.

Is CVE-2026-56352 actively exploited?

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

How to fix CVE-2026-56352?

Upgrade n8n to 2.19.3 or later, where the legacy ExecuteWorkflow localFile path enforces the same access checks as other file-reading nodes. Until patched, review and restrict who holds workflow create/modify permissions — treat that role as equivalent to file-system access on the host. Harden N8N_RESTRICT_FILE_ACCESS_TO with OS-level controls (containerization, chroot, read-only mounts) rather than relying solely on the application-layer restriction. Add detection for REST API calls to ExecuteWorkflow nodes specifying a localFile source, especially with path traversal patterns (../, absolute paths outside the workflows directory), and review n8n audit/access logs for workflow-permission users making unusual API calls outside the normal editor UI.

What systems are affected by CVE-2026-56352?

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

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

CVE-2026-56352 has a CVSS v3.1 base score of 6.4 (MEDIUM). The EPSS exploitation probability is 0.33%.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0037 Data from Local System

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

n8n before 2.19.3 contains a file path restriction bypass in the legacy ExecuteWorkflow node's localFile source option, which reads workflow files from disk without the file-access checks enforced by other file-reading nodes. Although hidden from the UI since v1.2, it remains reachable via the REST API. An authenticated user with permission to create or modify workflows can supply an arbitrary file path to bypass the N8N_RESTRICT_FILE_ACCESS_TO restriction and determine whether arbitrary files exist on the host; where the targeted path contains a valid workflow JSON file, that file can additionally be loaded and executed.

Exploitation Scenario

An authenticated user who has been granted workflow-create or workflow-edit permissions in n8n — but not admin or host access — uses the REST API directly (bypassing the UI, where the legacy node is hidden) to configure an ExecuteWorkflow node with the localFile source option pointing at an arbitrary host path. They iterate over likely paths (config directories, credential stores, other tenants' workflow exports) to determine which files exist based on n8n's response behavior. Upon finding a path that resolves to a valid workflow JSON file — for example another user's or tenant's exported workflow — they trigger it to load and execute, inheriting whatever logic, credentials, or integrations that workflow contains, effectively escalating from a low-privilege editor role to executing arbitrary automation logic on the shared host.

Weaknesses (CWE)

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Primary CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[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] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.