n8n CVE-2026-65596

Exploitation requires all of the following to be true simultaneously: (1) the attacker must be an authenticated n8n user with permission to create or edit workflows - unauthenticated access is insufficient; (2) the targeted credential must be a non-owner shared credential of type Header Auth, Basic Auth, Query Auth, or OAuth; (3) that credential must have 'Allowed HTTP Request Domains' configured - credentials without this restriction are outside the vulnerable policy boundary; and (4) the attacker must control or access an external HTTP server reachable from the n8n instance to receive the forwarded credential. Deployments where all credential usage is restricted to the credential owner, deployments without any 'Allowed HTTP Request Domains' restriction configured, and single-user n8n instances are entirely not affected. The AT:P metric in the provided CVSS 4.0 vector confirms a specific configuration prerequisite is required for exploitation.

The CVSS 4.0 score of 5.1 with vector AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:H/SI:L/SA:N accurately captures the risk profile. The AT:P (Attack Requirements: Present) metric is the key limiting factor - exploitation requires a specific, non-default configuration where credentials have 'Allowed HTTP Request Domains' set AND are shared with non-owner users; this is not a universal condition. PR:L confirms that authentication is required, ruling out unauthenticated internet-facing risk. SC:H (high subsequent-system confidentiality impact) is the most significant metric: exfiltrated credentials can grant access to downstream systems well beyond n8n itself, potentially enabling lateral movement. This vulnerability is not listed in CISA KEV, no public exploit code is referenced, and no EPSS data was provided in the input - real-world risk is therefore primarily an insider threat or compromised-account scenario in multi-user n8n deployments. Single-user deployments and instances without domain-restricted shared credentials are entirely unaffected. This is a meaningful but narrowly scoped issue: elevated priority for organizations running collaborative n8n environments, lower urgency for solo or owner-only deployments.

An authenticated n8n user with non-owner workflow editing access creates or modifies a workflow containing a GraphQL node, configures the node's endpoint to point to an attacker-controlled HTTP server, and associates a domain-restricted shared credential (e.g., a Header Auth or OAuth credential) with the node. On workflow execution, n8n sends the full credential to the attacker's server without checking it against the 'Allowed HTTP Request Domains' allowlist - the check that would block this in the HTTP Request node is simply absent in the GraphQL node. No public exploit code has been identified at time of analysis.