Skip to content

GHSA-vjf3-2gpj-233v CVE-2026-56350

n8n has an SSO Enforcement Bypass in its Self-Service Settings API

High npm
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.38%
Chance of exploitation in the next 30 days. Higher than 31.92% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-269 Improper Privilege Management
CWE-284 Improper Access Control
CWE-287 Improper Authentication
Fix
2.8.0
Upgrade n8n to this version or later

Description

Impact

An authenticated user signed in through Single Sign-On (SSO) could disable SSO enforcement for their own account through the n8n API. This allowed the user to create a local password and authenticate directly with email and password, completely bypassing the organization's SSO policy, centralized identity management, and any identity-provider-enforced multi-factor authentication.

Patches

The issue has been fixed in n8n version 2.8.0. Users should upgrade to this version or later to remediate the vulnerability.

Workarounds

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

  • Monitor audit logs for users who create local credentials after authenticating via SSO.
  • Restrict the n8n instance to fully trusted users only.

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

Affected versions

npm

PackageVulnerableFixed in
n8n
< 2.8.0
2.8.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

n8n npm → 2.8.0

npm
npm install n8n@2.8.0
yarn
yarn add n8n@2.8.0
pnpm
pnpm add n8n@2.8.0

Severity breakdown

CVSS 4.0 0.0

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

Attack vector
Network
Attack complexity
Low
Attack requirements
Present
Privileges required
Low
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
High
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

CVSS 3.1 6.3

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

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
None
Integrity
High
Availability
None

Weakness

CWE-269: Improper Privilege Management

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

How to prevent it
  • Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  • Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system.
  • Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

CWE-284: Improper Access Control

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

How to prevent it
  • Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

CWE-287: Improper Authentication

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

How to prevent it
  • Architecture and Design: Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-v98v-ff95-f3cp
n8n Vulnerable to Remote Code Execution via Expression Injection
High Known exploited Also affects n8n
GHSA-qgpw-8g46-w95v
n8n: Git Node branch.<name>.remote Config Key Bypasses Sandbox Path Restriction, Enabling Local Git Repository Read
Medium Also affects n8n
GHSA-65xw-2v52-jhxc
n8n: Cross-User Active Workflow ID and Lifecycle Event Disclosure via Missing userId Filter
Medium Also affects n8n
GHSA-pq6c-vh67-xpm3
n8n: Log Streaming Event Destinations Decrypt Generic-Auth Credentials Without Ownership Check
Medium Also affects n8n
GHSA-cqr2-h44g-v75v
n8n: Cross-Tenant Project-Member PII Disclosure via Missing Per-Project Scope Check on Role Assignment Endpoints
Medium Also affects n8n
GHSA-pf83-w3f9-8m37
n8n: Disabled OIDC SSO Endpoints Remain Active and Issue Valid Sessions
Medium Also affects n8n
GHSA-6xcw-7xm6-48c6
n8n: Expression Sandbox Escape via Shared Builtin Tampering and Code-Printer Injection Leads to Code Execution
High Also affects n8n
GHSA-34ff-336r-5q23
n8n: Domain-Restriction Bypass via Unguarded Model-Search Endpoint in OpenAI Chat Model Node
Medium Also affects n8n
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor