GHSA-2vx9-7wpg-88jq

What it actually does

The legacy ExecuteWorkflow node in n8n did not correctly enforce file path restrictions when resolving workflow files. A user who can create or edit workflows can supply a path that escapes the intended workflow directory, causing n8n to load workflow definitions (and potentially other files readable by the n8n process) from locations that should have been blocked. Impact is limited to what the n8n service account can read or execute on disk and to tenants where untrusted users can configure that node.

Why it matters to the business

Workflow files often contain API keys, OAuth tokens, and business-process logic. A successful bypass can leak those secrets or cause unintended automations to run, disrupting operations or exposing customer and partner data. This is a medium-severity issue (CVSS 6.4), not listed in CISA KEV, with no reported in-the-wild exploitation or ransomware use. It has been public for about five months; treat it as a planned patch for internet-facing or multi-user n8n instances, and as lower urgency where only trusted admins can edit workflows.

How an attack unfolds

An attacker who already has permission to create or modify n8n workflows configures the legacy ExecuteWorkflow node with a destination path that evades the node’s directory allowlist. n8n then reads a workflow file from outside the intended folder. Depending on filesystem layout and process privileges, the attacker may obtain other users’ workflow definitions (including stored credentials) or trigger execution of a workflow they should not be able to invoke. No public exploit is known; abuse requires an authenticated workflow editor and a reachable n8n instance still running a vulnerable release.

How to fix it

Upgrade n8n (npm) to 2.19.3 or later, which restores path enforcement on the legacy ExecuteWorkflow node. Prefer current Execute Workflow behavior over the legacy node and remove or disable the legacy node in shared projects. Restrict workflow-edit rights to trusted operators, run the n8n process with a least-privilege OS user and tight filesystem permissions on workflow and credential stores, and rotate any credentials that may have lived in workflow files on exposed instances.

How to confirm the fix worked

Confirm the running n8n package version is 2.19.3 or newer (npm list n8n, container image tag, or the in-app version string). Inventory workflows for the legacy ExecuteWorkflow node and reject any remaining path parameters that leave the approved workflow directory. After upgrade, in a non-production instance, verify that out-of-scope paths are denied and that only authorized workflow files load. Review IAM so untrusted users cannot publish or edit workflows.

Typical attack path

1. Obtain an n8n account that can create or edit workflows (stolen credentials, over-privileged invite, or shared editor access).
2. Add or alter a workflow that uses the legacy ExecuteWorkflow node.
3. Point the node at a path that escapes the restricted workflow directory instead of a sanctioned file.
4. Trigger the workflow so the process reads or runs the out-of-scope file.
5. Harvest secrets or logic from the loaded workflow, or cause follow-on automations that call internal APIs and data stores.

How to detect it

There is no public exploit campaign, so look for suspicious authenticated use rather than a known malware family. Review n8n audit, execution, and application logs around ExecuteWorkflow runs; flag executions whose file path is outside the configured workflows directory or contains parent-directory segments. Inspect exported workflow JSON for the legacy ExecuteWorkflow node and unusual path parameters. On the host, correlate n8n process file-open events (auditd, EDR, or container runtime logs) against the workflow store path. Check authentication logs for new or rarely used editors shortly before those executions. Successful abuse leaves legitimate-looking workflow runs rather than a distinct implant, so focus on path anomalies and unexpected credential use afterward.

• n8n-nodes-base.executeWorkflow
• "type":"n8n-nodes-base.executeWorkflow"
• ExecuteWorkflow
• executeWorkflow
• execute-workflow
• "path":
• ../
• ..\\
• workflows/../

What your security team should do

• Patch all n8n deployments to 2.19.3 or later, prioritizing multi-tenant and internet-reachable editors.
• Disable or migrate off the legacy ExecuteWorkflow node; allow only the current Execute Workflow node.
• Limit workflow create/edit to a small admin group; treat editor access as equivalent to code execution on connected systems.
• Lock down the n8n service account so it cannot read unrelated home directories, secrets stores, or other tenants’ workflow folders.
• Hunt historical workflow JSON and audit logs for ExecuteWorkflow usage and unexpected file paths, then rotate credentials found in those workflows.