AI Threat AlertCVE-2026-110851: n8n: cross-project agent takeover via create endpoint
MEDIUMn8n before 2.41.4 (and 2.42.x before 2.42.1) has an authorization bypass (CWE-639, insecure direct object reference) in the Agents create endpoint: it accepts a caller-supplied Agent ID and checks permissions only against the requested project, never against the project that owns the existing agent. An authenticated user with just read-only agent access in another project can therefore pull that agent into their own project and rewrite its name, schema and version. This matters most for multi-tenant or multi-team n8n instances, because it breaks the project boundary that separates teams and lets an insider tamper with or hijack AI agents that may hold tool access and downstream credentials. No CVSS or EPSS score has been published yet, it is not in CISA KEV, and no public exploit or Nuclei template is known, so this is a patch-in-cycle item rather than an emergency, unless you run shared instances with untrusted or low-trust users. Upgrade to 2.41.4 or 2.42.1 or later, then review agent ownership and change history for unexpected moves between projects.
What is the risk?
Moderate (no official CVSS yet). Exploitation needs authentication plus read-only access to the victim agent, and the attacker must know or enumerate the target Agent ID. Complexity looks low once those conditions are met, since it is a single crafted API request. Integrity impact is high, because the agent definition can be moved and rewritten. Confidentiality and availability impact are not described. There is no evidence of active exploitation (not in KEV, no public exploit, no scanner template). Exposure is concentrated in multi-project and multi-team n8n deployments; single-user instances are largely unaffected.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | — | No patch |
Do you use n8n? You're affected.
How severe is it?
What should I do?
1 step1) Upgrade n8n to 2.41.4, 2.42.1 or a later release. 2) Until patched, restrict accounts with any access to agents in sensitive projects, and remove read-only project access that is not strictly needed. 3) Audit existing agents for unexpected project ownership changes, or for name, schema or version changes you did not make. 4) Review API and audit logs for calls to the Agents create endpoint that carry an existing Agent ID, especially from users who are not members of the owning project. 5) Rotate credentials that the affected agents use if tampering is suspected. 6) Enforce least privilege on project roles and keep instances that hold sensitive agents off shared tenancy where possible.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-110851?
n8n before 2.41.4 (and 2.42.x before 2.42.1) has an authorization bypass (CWE-639, insecure direct object reference) in the Agents create endpoint: it accepts a caller-supplied Agent ID and checks permissions only against the requested project, never against the project that owns the existing agent. An authenticated user with just read-only agent access in another project can therefore pull that agent into their own project and rewrite its name, schema and version. This matters most for multi-tenant or multi-team n8n instances, because it breaks the project boundary that separates teams and lets an insider tamper with or hijack AI agents that may hold tool access and downstream credentials. No CVSS or EPSS score has been published yet, it is not in CISA KEV, and no public exploit or Nuclei template is known, so this is a patch-in-cycle item rather than an emergency, unless you run shared instances with untrusted or low-trust users. Upgrade to 2.41.4 or 2.42.1 or later, then review agent ownership and change history for unexpected moves between projects.
Is CVE-2026-110851 actively exploited?
No confirmed active exploitation of CVE-2026-110851 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-110851?
1) Upgrade n8n to 2.41.4, 2.42.1 or a later release. 2) Until patched, restrict accounts with any access to agents in sensitive projects, and remove read-only project access that is not strictly needed. 3) Audit existing agents for unexpected project ownership changes, or for name, schema or version changes you did not make. 4) Review API and audit logs for calls to the Agents create endpoint that carry an existing Agent ID, especially from users who are not members of the owning project. 5) Rotate credentials that the affected agents use if tampering is suspected. 6) Enforce least privilege on project roles and keep instances that hold sensitive agents off shared tenancy where possible.
What systems are affected by CVE-2026-110851?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation platforms, multi-tenant AI orchestration.
What is the CVSS score for CVE-2026-110851?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012Valid AccountsAML.T0081Modify AI Agent ConfigurationCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
A contractor with read-only access to a shared n8n project learns the ID of a finance team's AI agent, for example from the UI or API responses. They send a create request to the Agents endpoint scoped to their own project, with the victim agent's ID in the body. The server checks only the attacker's permissions on their own project, so it accepts the request and moves the existing agent into the attacker's project. The attacker then rewrites the agent's schema and version, so the finance team loses control of the agent and any workflow that invokes it behaves differently.
Weaknesses (CWE)
CWE-639Authorization Bypass Through User-Controlled KeyPrimaryCWE-639Authorization Bypass Through User-Controlled KeyCWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
- [Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- [Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2026-3366310.0n8n: member role steals plaintext HTTP credentials
Same package: n8nCVE-2026-3366010.0TensorFlow: type confusion NPD in tensor conversion
Same package: n8nCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same package: n8nCVE-2026-274949.9n8n: security flaw enables exploitation
Same package: n8nCVE-2026-274959.9n8n: Code Injection enables RCE
Same package: n8n