CVE-2026-56350: SSO Enforcement Bypass in n8n via API Parameter Pollution / Mass Assignment

The vulnerability, tracked as CVE-2026-56350 and GHSA-vjf3-2gpj-233v, represents an improper authorization (CWE-285) and mass assignment (CWE-915) flaw in the self-service settings API of the n8n workflow automation platform. In affected versions prior to 2.8.0, authenticated users who log in using Single Sign-On (SSO) can modify administrative-level authentication preferences. By executing a crafted API call, users can disable SSO enforcement policies assigned to their specific account profiles.

The vulnerability resides within the /me/settings endpoint, which is exposed to handle standard user configuration updates. The endpoint failed to restrict inputs to non-sensitive user parameters. This exposure allows a standard user to manipulate internal flags that govern identity verification and credential policies, extending their privilege limits beyond designed constraints.

The exploitation of this flaw does not require administrative rights, making it accessible to any authenticated standard user. The primary consequence is the subversion of centralized access controls, including Multi-Factor Authentication (MFA) and Identity Provider (IdP) revocation policies, posing a significant risk to enterprise tenant security.

The root cause of CVE-2026-56350 lies in the direct mapping of request payloads to a high-privilege Data Transfer Object (DTO) model without contextual validation. When a user submits a configuration update, the backend processes the request via the MeController using the NestJS framework. The application handles requests to the PATCH /me/settings route by binding the body of the HTTP request directly to the SettingsUpdateRequestDto class.

This shared SettingsUpdateRequestDto schema contains both standard, low-privilege settings (such as onboarding status) and high-privilege configuration parameters. Among these high-privilege parameters is allowSSOManualLogin, a boolean flag designed to control whether a user can bypass the organization's enforced SSO policy to log in with a local password.

Because the endpoint did not implement validation to strip unprivileged parameters or utilize a context-specific DTO, the binding engine processed any provided key-value pairs matching the schema. When the controller updated the database record, it saved the attacker-supplied allowSSOManualLogin flag. This direct binding mechanism constitutes a classic mass assignment vulnerability (CWE-915).

The vulnerable implementation of the settings update endpoint utilized the general SettingsUpdateRequestDto model, which exposed administrative fields directly to self-service updates. Below is the vulnerable controller implementation before the application of the patch.

// Vulnerable Controller Path: packages/cli/src/controllers/me.controller.ts
@Patch('/settings')
async updateCurrentUserSettings(
    req: AuthenticatedRequest,
    _: Response,
    @Body payload: SettingsUpdateRequestDto, // Vulnerable: Binds request directly to the administrative DTO
): Promise<User['settings']> {
    const { id } = req.user;
    // Database update operations process the entirety of the payload

To remediate this issue, the development team created a specialized, restricted DTO named UserSelfSettingsUpdateRequestDto. This new schema defines only a strict subset of safe properties that a standard user is authorized to modify, omitting the high-privilege administrative settings.

// Patched DTO: packages/@n8n/api-types/src/dto/user/user-self-settings-update-request.dto.ts
import { z } from 'zod';
import { Z } from 'zod-class';
 
export class UserSelfSettingsUpdateRequestDto extends Z.class({
	easyAIWorkflowOnboarded: z.boolean().optional(),
	dismissedCallouts: z.record(z.string(), z.boolean()).optional(),
}) {}

The controller was then modified to restrict the input parameter binding type to this newly introduced UserSelfSettingsUpdateRequestDto class.

// Patched Controller Path: packages/cli/src/controllers/me.controller.ts
@Patch('/settings')
async updateCurrentUserSettings(
	req: AuthenticatedRequest,
	_: Response,
	@Body payload: UserSelfSettingsUpdateRequestDto, // Patched: Binds request to the restricted DTO
): Promise<User['settings']> {
	const { id } = req.user;

This structural separation ensures that any attempt by a user to submit unauthorized parameters like allowSSOManualLogin will be caught during the schema parsing phase and stripped from the input object before reaching the database logic.

An attacker must first possess a valid, authenticated session within the target n8n instance, typically established via the standard Single Sign-On (SSO) login flow. Once logged in, the attacker can leverage standard browser developer tools or command-line HTTP clients to extract their active session identifier or JSON Web Token (JWT).

With the active session identifier, the attacker constructs an HTTP PATCH request directed at the /me/settings endpoint. In the JSON body of this request, the attacker appends the administrative parameter "allowSSOManualLogin": true alongside expected configuration parameters.

PATCH /me/settings HTTP/1.1
Host: n8n.target.org
Authorization: Bearer <JWT_TOKEN>
Content-Type: application/json
 
{
  "easyAIWorkflowOnboarded": true,
  "allowSSOManualLogin": true
}

Upon processing the request, the vulnerable n8n backend accepts the payload and updates the database row corresponding to the attacker's user profile. The attacker can then utilize the local credential creation or recovery endpoints to associate a local password with their email address. Following this modification, the attacker can log in directly using conventional credentials, completely bypassing the external identity provider controls and any configured Multi-Factor Authentication (MFA) mechanisms.

To visually illustrate this process, the following diagram depicts the message exchange leading to the unauthorized policy update and subsequent authentication bypass.

The security implications of CVE-2026-56350 are centered on the subversion of centralized authentication and identity enforcement policies. When an attacker successfully overrides the SSO enforcement flag, the centralized Identity Provider (IdP) loses control over the user's access path to the n8n application.

This bypass undermines organizational security posture by rendering standard offboarding procedures ineffective. If an administrator disables or revokes an employee's account within the centralized IdP (such as Okta or Entra ID), the employee can still maintain persistent access to the n8n workspace via their direct email and password credentials.

Furthermore, this vulnerability renders any IdP-level security policies, such as conditional access rules, IP geofencing, or mandatory hardware-token multi-factor authentication (MFA), completely obsolete for the affected account. The impact of the vulnerability is reflected in its CVSS score of 6.3, highlighting the severe integrity compromise resulting from unauthorized authentication policy modification.

The primary and recommended mitigation is the immediate upgrade of all n8n instances to version 2.8.0 or later. This version contains the specialized validation schemas that prevent unauthorized parameter assignment. For container-based environments, this is achieved by specifying the fixed tag in the deployment configuration.

If an immediate upgrade is not feasible, security administrators should perform a direct audit of the database to identify compromised accounts. Executing a query to inspect the user settings table can pinpoint any standard accounts that have successfully disabled the SSO requirement.

SELECT id, email, settings FROM "user" WHERE settings::jsonb ->> 'allowSSOManualLogin' = 'true';

Additionally, organizations can implement temporary Web Application Firewall (WAF) rules to inspect traffic heading to the /me/settings and /api/v1/me/settings endpoints. The WAF should block any PATCH requests that contain the string "allowSSOManualLogin" within the request body, effectively mitigating the exploit vector until a patch can be applied.