Skip to main content
VulnerabilityPublished

CVE-2025-68697: n8n · Improper Privilege Management

Affects n8nSource CVE Database V5

0

Not known to be exploited · CVSS 7.1 High : upgrade to 2.0.0 soon.

Data as of 26 Oct 2026, 10:12 UTC

CVSS 3.1 base score
7.1High
How severe the flaw is on the 0–10 CVSS scale.
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:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 26 Dec 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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 26 Oct 2026.

What to do

Upgrade n8n-io/n8n to 2.0.0.

Affected software

ProductAffectedFixed in
GitHubn8n-io/n8npkg:github/n8n-io/n8nOther threatsAffected
  • <2.0.0
Fixed in
  • 2.0.0

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.

References

Community reviews

Loading reviews…