CVE-2026-56350 Root-Cause Fix for n8n /me/settings Mass Assignment SSO Bypass

Vulnerability

CVE-2026-56350 describes an SSO enforcement bypass in n8n where an authenticated SSO user could update their own settings through /me/settings using a payload shape that accepted privileged fields. The core issue is mass assignment: the self-service endpoint consumed the broader SettingsUpdateRequestDto, allowing client-controlled input to reach settings fields that should be reserved for administrative or backend-only workflows.

The most security-sensitive field called out by the patch is allowSSOManualLogin. If a user can set this flag on their own account, they can weaken or bypass the intended SSO-only authentication policy and regain email/password login capability. The patch notes also identify userActivated as backend-only, indicating the vulnerable endpoint exposed a wider trust boundary problem than a single field. This aligns with the CVE summary and public records at CVE/MITRE and NVD.

// vulnerable controller binding
@Body payload: SettingsUpdateRequestDto

// attacker-controlled field in self-service request
{
  "allowSSOManualLogin": true
}

Because the flaw sits at the DTO and endpoint contract layer, the exploit does not require breaking authentication; it abuses an authenticated user's ability to submit overbroad state changes to their own settings object.

Patch

The fix in the official commit a70b2ea379086da3de103bb84811e88cadf29976 introduces a dedicated UserSelfSettingsUpdateRequestDto for the /me/settings endpoint. This DTO explicitly allowlists only self-service fields:

export class UserSelfSettingsUpdateRequestDto extends Z.class({
	easyAIWorkflowOnboarded: z.boolean().optional(),
	dismissedCallouts: z.record(z.string(), z.boolean()).optional(),
}) {}

The controller is updated to bind /me/settings to this narrower DTO instead of the generic settings DTO. The frontend API client and store typings are also switched to the same restricted type, reducing accidental reintroduction from client code and keeping the contract consistent across layers.

Tests were added at both DTO and integration levels. The DTO tests verify that restricted and unknown fields are stripped rather than persisted, including allowSSOManualLogin, userActivated, and arbitrary extra properties. Integration tests confirm that requests containing those fields still succeed for allowed data while the forbidden fields remain absent from both the response and stored user settings.

Review

Pros

The patch fixes the vulnerability at the correct trust boundary: the self-service endpoint no longer accepts the admin-capable DTO. That is a strong design correction because it removes the dangerous field from the endpoint contract rather than trying to special-case one property after parsing.

The allowlist model is appropriate for user-controlled settings updates. By defining only easyAIWorkflowOnboarded and dismissedCallouts in UserSelfSettingsUpdateRequestDto, the patch reduces future exposure from newly added settings fields that might otherwise become writable through DTO reuse.

Test coverage is meaningful. The added unit tests validate schema behavior, and the integration tests verify persistence semantics against the repository. The security assertions specifically check that allowSSOManualLogin and userActivated are not stored, which directly maps to the reported exploit path.

The frontend type changes are also beneficial. While not a security control by themselves, they align client expectations with the hardened server contract and reduce developer confusion around which settings are self-service versus privileged.

Cons

The patch appears to rely on stripping unknown fields rather than rejecting them with an explicit validation error. That is acceptable for mitigation, but it can make abuse attempts less visible to clients and operators. A rejected request with audit logging would provide stronger detection and clearer API semantics.

The reviewable diff is tightly scoped to /me/settings. That is good for the immediate CVE, but it leaves an open engineering question: whether other endpoints reuse broad DTOs for mixed-trust operations. The vulnerability pattern is architectural, so similar mass-assignment risks may exist elsewhere if endpoint-specific DTOs are not consistently enforced.

No server-side authorization assertion is shown beyond DTO narrowing. If downstream persistence logic merges arbitrary nested settings objects in other code paths, defense in depth would benefit from explicit field-level authorization checks near the write layer as well.

Verdict

Root-cause.

This patch addresses the underlying cause of CVE-2026-56350 by replacing an overbroad request model with a dedicated self-service DTO for /me/settings. That change removes privileged fields such as allowSSOManualLogin from the writable surface, which is the correct remediation for a mass-assignment flaw enabling SSO enforcement bypass. The added tests materially support the fix, and the endpoint contract is now aligned with least privilege.

Recommended follow-up: audit other user- and admin-facing endpoints for DTO reuse across trust boundaries, consider rejecting unknown fields instead of silently stripping them, and add telemetry for attempted writes to restricted settings. Based on the supplied patch and references, however, the fix is technically sound and directly addresses the reported exploit path.

References: official patch, NVD, CVE record.