Is there a patch available for CVE-2026-56778?

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

n8n CVE-2026-56778

Q: What is the CVSS score of CVE-2026-56778?

CVE-2026-56778 has a CVSS 4.0 base score of 5.3 (Medium). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/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.2%.

EUVD-2026-42264 MEDIUM

Incorrect Authorization (CWE-863)

2026-07-08 disclosure@vulncheck.com

GHSA-g7vr-5v44-rqf5

Authentication Bypass N8n

5.3

CVSS 4.0 · Vendor: vulncheck

Severity by source

Vendor (vulncheck) PRIMARY

5.3 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/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

6.4 MEDIUM

Network-accessible API requiring authenticated read-only token (PR:L); scope change (S:C) as unauthorized executions affect downstream systems beyond n8n itself.

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

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

Primary rating from Vendor (vulncheck).

CVSS VectorVendor: vulncheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jul 08, 2026 - 15:14 vuln.today

Patch available

Jul 08, 2026 - 15:01 EUVD

DescriptionCVE.org

n8n before 2.25.7 and 2.26.x before 2.26.2 contains an authorization bypass in the Public API execution retry endpoint, which authorizes access using the workflow:read scope instead of workflow:execute. An authenticated user with read-only access to a shared workflow can use the Public API to retry executions of that workflow, bypassing the intended permission boundary between read and execute access. This affects instances where workflows are shared with other users or across projects.

AnalysisAI

Authorization bypass in n8n's Public API execution retry endpoint allows authenticated read-only users to trigger workflow executions they should not be permitted to run. The endpoint incorrectly authorizes requests against the workflow:read scope rather than the required workflow:execute scope, collapsing the intended permission boundary between read and execute access. This affects n8n instances before 2.25.7 and 2.26.x before 2.26.2 where workflows are shared across users or projects; no public exploit has been identified at time of analysis, and a vendor patch is available.

Technical ContextAI

n8n is a self-hosted open-source workflow automation platform with a REST-based Public API and a role-based access control model using OAuth-style scopes (e.g., workflow:read, workflow:execute). The vulnerability (CWE-863: Incorrect Authorization) resides in the execution retry endpoint's authorization guard, which checks the workflow:read scope instead of workflow:execute before allowing a retry operation. This is a logic flaw in the authorization middleware layer - the endpoint exists to replay prior executions, but its gate was wired to the read permission rather than the execute permission. Affected CPE covers n8n versions prior to 2.25.7 on the 2.x branch and all 2.26.x versions prior to 2.26.2, per EUVD-2026-42264.

RemediationAI

Upgrade n8n to version 2.25.7 (for 2.x deployments) or 2.26.2 (for 2.26.x deployments), which contain the vendor-released patch correcting the scope check on the execution retry endpoint. These versions are confirmed as fix targets per EUVD-2026-42264. Details are available in the GitHub Security Advisory at https://github.com/n8n-io/n8n/security/advisories/GHSA-h3jj-5f3v-3685. If immediate patching is not possible, the most effective compensating control is to disable workflow sharing with users who should not have execute privileges - this removes the attack surface entirely since the vulnerability only manifests in shared-workflow contexts. Restricting Public API access to trusted IP ranges via network controls or a reverse proxy ACL will further reduce exposure, though this does not eliminate the flaw for authorized API users who retain read-only access.