CVE-2025-68697: n8n · Improper Privilege Management
Affects n8nSource CVE Database V5
Not known to be exploited · CVSS 7.1 High : upgrade to 2.0.0 soon.
Data as of 26 Oct 2026, 07:57 UTC
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 18% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.0.0
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:NExploitation evidence
Disclosed: evidence found.
CVE published 26 Dec 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-26.
What to do
Upgrade n8n-io/n8n to 2.0.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
GitHubn8n-io/n8npkg:github/n8n-io/n8nOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
European organizations should immediately upgrade all self-hosted n8n instances to version 2.0.0 or later to fully remediate this vulnerability. Until upgrades can be performed, implement the following mitigations: 1) Configure the environment variable N8N_RESTRICT_FILE_ACCESS_TO to restrict file operations to a dedicated directory that contains no sensitive data, minimizing the risk of unauthorized file access. 2) Ensure N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES is set to true (default) to block access to the .n8n directory and user-defined configuration files, protecting critical configuration data. 3) Disable the Code node and other high-risk nodes using the NODES_EXCLUDE environment variable if workflow editors are not fully trusted, thereby reducing the attack surface. 4) Enforce strict access controls and monitor workflow editor accounts for suspicious activity to prevent unauthorized privilege escalation. 5) Employ network segmentation and host-level security controls to limit the impact of any potential compromise. 6) Regularly audit and review workflow permissions and user roles to ensure least privilege principles are maintained. 7) Implement logging and alerting on file access and workflow changes to detect exploitation attempts promptly.
Description
n8n is an open source workflow automation platform. Prior to version 2.0.0, in self-hosted n8n instances where the Code node runs in legacy (non-task-runner) JavaScript execution mode, authenticated users with workflow editing access can invoke internal helper functions from within the Code node. This allows a workflow editor to perform actions on the n8n host with the same privileges as the n8n process, including: reading files from the host filesystem (subject to any file-access restrictions configured on the instance and OS/container permissions), and writing files to the host filesystem (subject to the same restrictions). This issue has been patched in version 2.0.0. Workarounds for this issue involve limiting file operations by setting N8N_RESTRICT_FILE_ACCESS_TO to a dedicated directory (e.g., ~/.n8n-files) and ensure it contains no sensitive data, keeping N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=true (default) to block access to .n8n and user-defined config files, and disabling high-risk nodes (including the Code node) using NODES_EXCLUDE if workflow editors are not fully trusted.