CVE-2026-92588 in n8n
Summary
by MITRE • 09/17/2026
n8n is a workflow automation platform. In n8n versions before 1.123.76, 2.37.7, and 2.38.2, the source control push endpoint derived the set of files to push from the file paths and status supplied in the client request payload instead of from the server-side status computed for the requesting user. An authenticated project-scoped user (e.g., a project admin) could therefore reference files belonging to projects they have no access to and push a deletion of those projects' workflows and credentials, resulting in cross-project data destruction. Exploitation requires the Source Control (Environments) enterprise feature to be licensed, enabled, and connected to a remote repository. The issue is fixed in 1.123.76, 2.37.7, and 2.38.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in n8n workflow automation platforms prior to versions 1.123.76, 2.37.7, and 2.38.2 represents a critical server-side access control failure within the source control integration feature. This flaw allows authenticated users with project-scoped permissions, such as project administrators, to bypass intended isolation boundaries between different projects hosted on the same instance. The core technical deficiency lies in how the application handles file path resolution and status verification during push operations to remote repositories. Instead of validating that the requesting user possesses explicit read or write access to specific workflows and credentials before processing a deletion request, the server blindly trusts the set of files and their associated statuses provided directly within the client-side payload. This architectural oversight effectively decouples the action from the actual authorization state maintained on the server side, creating a significant discrepancy between what the interface permits and what the backend enforces.
From an operational perspective, this misconfiguration enables cross-project data destruction with severe consequences for organizational integrity and security posture. An attacker or malicious insider who has obtained credentials for one project can manipulate the source control push endpoint to target workflows and stored credentials belonging to entirely separate projects within the same n8n instance. By supplying file paths of resources they do not own, the user triggers a deletion operation that removes critical automation logic and sensitive authentication tokens from those unauthorized projects. This results in immediate service disruption for other teams or departments relying on these workflows, as well as potential exposure of secrets if credentials are exfiltrated before destruction or if residual data remains accessible through backup mechanisms. The impact is compounded by the fact that source control features are typically used to manage complex automation pipelines where downtime can halt critical business processes.
The exploitation of this vulnerability requires specific conditions to be met, primarily involving the Source Control feature which is part of the enterprise licensing tier for n8n. The target instance must have this feature enabled and actively connected to a remote repository such as GitHub or GitLab. Without this connection, the push endpoint logic would not be invoked in the same manner, limiting the attack surface. However, once the environment is configured correctly, any authenticated user with project-level access can exploit the flaw without needing elevated global administrator privileges. This highlights a common pitfall in multi-tenant SaaS or self-hosted platform designs where fine-grained permissions are assumed to be enforced at every layer of the stack rather than being strictly validated by authoritative server-side logic during state-changing operations.
To mitigate this risk, organizations running affected versions must immediately upgrade n8n to version 1.123.76, 2.37.7, or 2.38.2 where the issue has been resolved. The fix involves implementing rigorous server-side validation that cross-references every file path and status in a push request against the user's actual access rights within each specific project before allowing any modifications to occur. In addition to upgrading, administrators should review their source control integration settings and ensure that only trusted users have write access to remote repositories linked to n8n instances. Monitoring logs for unusual deletion patterns across multiple projects can also serve as a detection mechanism while patching efforts are underway. This incident underscores the importance of adhering to the principle of least privilege and ensuring that client-side inputs never dictate server-side authorization decisions, aligning with industry standards such as CWE-269 which addresses improper control of administrative privileges and CWE-862 regarding missing authorization checks in critical functions.