n8n CVE-2026-72763

Exploitation requires three concurrent conditions, all confirmed by the vendor advisory: (1) workflow sharing must be administratively enabled on the n8n instance - this is an opt-in feature, not a default; (2) the attacker must have been explicitly granted the Editor role on a specific shared workflow - read-only Members or users with no sharing access are not affected; and (3) the attacker must know the numeric or UUID ID of the target credential they wish to exfiltrate - this may require prior enumeration, insider knowledge, or a secondary vulnerability. The CVSS PR:L confirms that an authenticated, low-privilege session is required; unauthenticated exploitation is not possible. The exploitation path is further limited to the 1.x and 2.x version ranges described in the affected products; instances already on 1.123.67, 2.31.5, or 2.32.1 are not vulnerable.

The CVSS 4.0 score of 7.2 with vector AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:L reflects a realistic threat picture. AT:P (attack requirements present) is the primary severity limiter: exploitation requires workflow sharing to be administratively enabled AND the attacker to have been explicitly granted Editor access to a specific shared workflow. This is not a default-configuration issue - organizations that do not use workflow sharing are not exposed. However, for organizations using n8n's collaboration features (a core use case), the risk is material: any Editor-level team member who can discover a credential ID can silently exfiltrate credentials they were never authorized to use, with no runtime anomaly distinguishing legitimate from malicious use. PR:L confirms authenticated access is required, but the Editor role is a standard, non-privileged collaboration role. The subsequent-system impact (SC:H/SI:H) reflects that exfiltrated credentials can be replayed against downstream services. No EPSS score was provided in the input data; no KEV listing and no public POC exist at time of analysis, suggesting exploitation remains opportunistic or insider-threat-driven rather than widespread automated scanning.

An internal team member with legitimately granted Editor access to a shared workflow discovers or social-engineers a target credential's ID (for example, a cloud provider API key stored in the same n8n project). The attacker opens the shared workflow, adds an Execute Sub-workflow node configured to Source = Parameter, and crafts the inline JSON to reference the target credential ID. Upon saving and executing the workflow, n8n resolves the credential in the parent project's context without re-checking the Editor's own credential permissions, passing the resolved secret to an attacker-controlled HTTP endpoint embedded in the same workflow. No public proof-of-concept code is known, but the technique requires no special tooling beyond editing a workflow through the standard n8n UI.