Is there a patch available for EUVD-2026-38480?

Yes, a patch is available for EUVD-2026-38480. Update the affected software to the latest version immediately.

n8n EUVD-2026-38480

Q: What is the CVSS score of EUVD-2026-38480?

EUVD-2026-38480 has a CVSS 4.0 base score of 6.0 (Medium). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.5%.

| CVE-2026-49465 MEDIUM

Path Traversal (CWE-22)

2026-06-16 https://github.com/n8n-io/n8n

GHSA-5xp3-2w67-427v

Path Traversal

6.0

CVSS 4.0 · Vendor: https://github.com/n8n-io/n8n

Severity by source

Vendor (https://github.com/n8n-io/n8n) PRIMARY

6.0 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.7 HIGH

Network-reachable via n8n UI/API; PR:L because workflow edit permission is required; S:C because git bypass escapes the n8n sandbox boundary to read host filesystem data; C:H only, no integrity or availability impact demonstrated.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

Primary rating from Vendor (https://github.com/n8n-io/n8n).

CVSS VectorVendor: https://github.com/n8n-io/n8n

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

CVSS changed

Jun 23, 2026 - 18:22 NVD

7.7 (MEDIUM) 6.0 (MEDIUM)

Source Code Evidence Fetched

Jun 16, 2026 - 18:26 vuln.today

Analysis Generated

Jun 16, 2026 - 18:26 vuln.today

DescriptionCVE.org

Impact

An authenticated user with permission to create or modify workflows could supply a local filesystem path as the source repository in the Git node's Clone operation, or as the target repository in the Push operation, bypassing the N8N_RESTRICT_FILE_ACCESS_TO file sandbox. This allowed the contents of any local git repository accessible to the n8n process to be cloned into an allowed path and read, circumventing the access restrictions that correctly blocked direct file reads to the same paths.

Patches

The issue has been fixed in n8n versions 1.123.48, 2.21.8, and 2.22.4. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

Limit workflow creation and editing permissions to fully trusted users only.
Disable the Git node by adding n8n-nodes-base.git to the NODES_EXCLUDE environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

AnalysisAI

The Git node in n8n's workflow automation platform allows authenticated workflow editors to exfiltrate arbitrary host filesystem contents by supplying local paths as git repository sources in Clone or Push operations, bypassing the N8N_RESTRICT_FILE_ACCESS_TO sandbox entirely. Any git repository readable by the n8n process - including directories containing SSH keys, environment files, or database credentials - can be cloned into an allowed output path and read back through normal workflow outputs. No public exploit identified at time of analysis, but the attack complexity is genuinely low for any user holding workflow editing permissions, and vendor-confirmed patches are available in versions 1.123.48, 2.21.8, and 2.22.4.

Technical ContextAI

n8n is a Node.js-based workflow automation platform distributed as the npm package n8n. Its 'Git node' exposes native git operations - Clone and Push - as configurable workflow steps, accepting a repository path as a user-supplied parameter. The platform enforces filesystem access restrictions via the N8N_RESTRICT_FILE_ACCESS_TO environment variable, which is intended to sandbox direct file reads to approved directories. The root cause (CWE-22: Improper Limitation of a Pathname) is a failure to validate whether the repository path argument resolves to a remote URL or a local filesystem path before passing it to git operations. Because git natively supports file:// and bare local paths as valid repository sources, the Clone operation functions as an indirect read channel that bypasses path validation checks applied to direct file reads. This is a classic sandbox escape via a trusted subsystem that was not subject to the same access controls as the primitives it was designed to protect.

RemediationAI

Vendor-released patches are available: upgrade n8n to version 1.123.48 (1.x series), 2.21.8 (for 2.x deployments prior to 2.22), or 2.22.4 (for 2.22.x deployments), or any later release, as confirmed by the GitHub Security Advisory GHSA-5xp3-2w67-427v at https://github.com/n8n-io/n8n/security/advisories/GHSA-5xp3-2w67-427v. If immediate upgrade is operationally infeasible, two compensating controls exist with explicit trade-offs: first, restrict workflow creation and editing permissions to fully trusted users only - this reduces the attack surface but is often disruptive in collaborative environments and does not patch the underlying flaw; second, disable the Git node entirely by adding n8n-nodes-base.git to the NODES_EXCLUDE environment variable - this fully blocks the vulnerable code path but removes all git-based workflow functionality from the instance. The vendor explicitly states that neither workaround fully remediates the vulnerability, and both should be treated strictly as short-term interim measures until patching is completed.