CVE-2025-68697: When n8n Workflows Gain Direct Access to the Host Filesystem

Vulnerability Overview

CVE Name: n8n Privileged File System Access via Legacy JavaScript Code Node
CVE ID: CVE-2025-68697
CWE ID: CWE-693 – Protection Mechanism Failure
Disclosure Date: December 2025

Severity & Risk Rating

CVSS v3.1 Score: 8.8 / 10 (High)
Severity: HIGH
Attack Vector: Network
Attack Complexity: Low
Privileges Required: Low (authenticated user with workflow edit permissions)
User Interaction: None
Scope: Changed
Impact Type: Unauthorized file read and write on host system

Affected Product Details

Product: n8n (Open Source Workflow Automation Platform)
Deployment Type: Self-hosted n8n instances
Affected Versions: All versions prior to 2.0.0
Affected Configuration:
- Code node running in legacy (non–task-runner) JavaScript execution mode
Fixed Version: 2.0.0

Exploitability & Threat Status

Exploitability: High
Exploit Availability:
- No public proof-of-concept available at the time of writing
- Exploitation technique is straightforward and reproducible
Likely Threat Actors:
- Insider threats
- Users with excessive workflow permissions
- Attackers using compromised credentials

This vulnerability is particularly risky in environments where workflow editors are not fully trusted and where n8n runs with broad filesystem access.

Vulnerability Description

CVE-2025-68697 is caused by insufficient isolation of internal helper functions exposed to the JavaScript Code node when running in legacy execution mode.

In vulnerable configurations, the Code node allows workflow authors to invoke internal n8n helper functions that were not intended to be exposed to user-supplied code. This breaks a critical trust boundary between workflow logic and the underlying platform.

As a result, an authenticated user with workflow editing permissions can read and write files on the host system using the same privileges as the n8n process. File access is limited only by operating system or container permissions and any file access restrictions explicitly configured in n8n.

How the Vulnerability Can Be Exploited

Attack Prerequisites

An attacker must have:

Valid authentication to the n8n instance
Permission to create or modify workflows
Access to the JavaScript Code node
n8n running in legacy JavaScript execution mode
n8n version earlier than 2.0.0

Exploitation Steps

The attacker logs into the n8n web interface using valid credentials.
A new workflow is created or an existing workflow is modified.
A JavaScript Code node is added to the workflow.
Internal helper functions are invoked from within the Code node.
These functions are abused to read or write files on the host filesystem.
The workflow is executed, triggering file system operations on the n8n server.

Abuse Scenarios

Reading application configuration files
Accessing environment variables or secret files
Writing malicious scripts or backdoors
Modifying files used by other services
Dropping persistence artifacts on the host

All actions are performed with the privileges of the n8n process.

Proof of Concept (PoC) Status

Public PoC: Not available
Exploit Difficulty: Low

The vulnerability can be exploited by directly calling internal helper functions that expose file read and write capabilities within the legacy execution context.

Detection & Monitoring

Recommended Log Sources

n8n application logs
Workflow execution logs
Host-based file access logs (auditd on Linux, file integrity monitoring tools)
Container runtime logs (Docker or Kubernetes)
SIEM or EDR telemetry

Suspicious Indicators

Code node workflows performing file input/output operations
File reads from unexpected or sensitive directories
File writes outside approved workflow directories
Workflow changes by non-administrative users
Repeated workflow executions accessing the filesystem

Sample Detection Logic

Suspicious file activity pattern:

Parent process: n8n
Operation: File read or file write
Target path not within approved workflow directory

High-risk paths to monitor:

/etc/
Application configuration directories
Mounted secrets or credential volumes
User home directories
n8n configuration paths

MITRE ATT&CK Mapping

Technique ID	Technique Name	Relevance
T1078	Valid Accounts	Abuse of authenticated access
T1059	Command and Scripting Interpreter	JavaScript execution via Code node
T1083	File and Directory Discovery	Reading host filesystem
T1105	Ingress Tool Transfer	Writing files to host
T1190	Exploit Public-Facing Application	n8n often exposed externally

Remediation & Mitigation

Primary Remediation

Upgrade to n8n version 2.0.0 or later. This release removes legacy execution paths and enforces safer task-runner-based isolation.

Temporary Workarounds (If Upgrade Is Not Immediately Possible)

Restrict file access scope

N8N_RESTRICT_FILE_ACCESS_TO=~/.n8n-files

Ensure this directory contains no sensitive data.

Block access to n8n internal configuration files

N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=true

This setting is enabled by default and should remain enabled.

Disable high-risk nodes if users are not fully trusted

NODES_EXCLUDE='["n8n-nodes-base.code"]'

Official Patch Information

Fixed in: n8n 2.0.0
Official Patch / Security Advisory:
https://github.com/n8n-io/n8n/security/advisories

Final Takeaway

CVE-2025-68697 allows authenticated workflow editors to bypass intended security boundaries and interact with the host filesystem using n8n’s own privileges.

While this issue does not directly enable arbitrary command execution, it creates a powerful foothold for data exposure, persistence, and follow-on attacks. Organizations running self-hosted n8n instances should prioritize patching or apply strict mitigations without delay.