n8n CVE-2026-110851

Requires an authenticated n8n account on an affected version (before 2.41.4, or 2.42.x before 2.42.1) that holds at least read-only Agent access to the victim project, plus knowledge or possession of a valid existing Agent ID belonging to that other project. The attacker then invokes the Agents create endpoint with that caller-supplied foreign Agent ID. Limiting factors: exploitation is authenticated (not anonymous), is scoped to Agent objects only, and depends on the attacker already having cross-project read-only Agent visibility and a known target Agent ID - it cannot be performed by a fully unauthenticated external attacker against a default install.

This is a medium-severity authenticated authorization flaw (IDOR, CWE-639), not a critical pre-auth RCE. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) tells a consistent story with the description: network-reachable API, but it requires an authenticated account (PR:L) and an attack requirement is present (AT:P), reflecting the need to possess a valid existing Agent ID from another project. Impact is skewed toward integrity (VI:H - attacker can rewrite an Agent's name, schema and version and reassign ownership) with only low confidentiality and availability impact, so this is primarily a data-integrity/tenant-isolation problem rather than a system-compromise issue. No EPSS score was provided in the input, there is no CISA KEV listing, and no public POC was referenced, so exploitation probability signals are absent rather than elevated - status is 'no public exploit identified at time of analysis.' Net: a genuine multi-tenant isolation bug worth patching on normal cycles, but not an emergency given that it is authenticated, bounded to Agent objects, and shows no evidence of active exploitation. No conflicting signals were found between the CVSS vector and the description; both agree exploitation is authenticated and network-based.

A legitimate n8n user who has only read-only Agent access to a second project obtains the ID of an Agent owned by that project and calls the Agents create endpoint supplying that foreign Agent ID. Because the endpoint checks permissions against the requested (attacker's) project but not against the project that actually owns the Agent, the Agent is moved into the attacker's project and its name, schema and version are overwritten. No public exploit code was referenced in the provided data.