CVE-2026-110851 in n8n
Summary
by MITRE • 10/15/2026
n8n before 2.41.4 and 2.42.x before 2.42.1 contains an authorization bypass in the Agents create endpoint, which accepts a caller-supplied Agent ID, checks permissions only against the requested project, and updates an existing Agent without verifying which project owns it. An authenticated user with read-only Agent access to another project can supply an existing Agent ID to move that Agent into their own project and rewrite its name, schema and version.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in n8n versions prior to 2.41.4 and the 2.42.x series before 2.42.1 represents a critical authorization bypass within the Agents create endpoint. This flaw stems from an insufficient verification of resource ownership during state modification operations. Specifically, when a user initiates a request to update or move an Agent, the system validates that the caller possesses read-only permissions for the target project but fails to verify whether the source agent actually belongs to that same project. Consequently, an authenticated attacker with limited privileges can manipulate resources outside their authorized scope by supplying a caller-supplied Agent ID associated with another user's project. This lack of cross-project ownership validation allows the attacker to effectively hijack agents from other projects and integrate them into their own workspace without proper administrative oversight or permission checks for resource transfer.
From a technical perspective, this issue is classified under CWE-269 Improper Privilege Management due to the failure to enforce role-based access controls correctly during state changes. The operational impact of this vulnerability is significant as it allows an authenticated user with read-only Agent access in one project to rewrite critical attributes such as the agent's name, schema definition, and version number for agents belonging to other projects. This capability undermines data integrity by allowing unauthorized modifications to shared resources and compromises confidentiality since sensitive workflow configurations stored within these agents can be altered or potentially exfiltrated if combined with other vulnerabilities. Furthermore, this behavior aligns with MITRE ATT&CK technique T1078 Valid Accounts as it leverages legitimate credentials to perform actions beyond their intended scope, effectively escalating privileges through logical flaws rather than exploiting software bugs in authentication mechanisms directly.
Mitigation strategies must prioritize immediate patching of the n8n installation to version 2.41.4 or later for stable releases and 2.42.1 or later for development branches where this issue has been resolved. In addition to updating, organizations should implement strict input validation on server-side logic to ensure that any resource modification request verifies both the caller's permissions and the current ownership status of the target resource against a trusted database record rather than relying solely on client-supplied identifiers. Implementing principle of least privilege access controls across all projects ensures that users cannot even attempt such operations if they lack explicit write or admin rights for specific resources. Regular security audits focusing on authorization logic in multi-tenant environments are essential to detect similar logical flaws where resource boundaries are not strictly enforced during update and move operations.