n8n CVE-2026-65589

Exploitation requires: (1) an authenticated n8n session with at least read access to workflow execution data; (2) the target n8n instance must be running a version prior to 1.123.64; (3) one or more workflows must use LLM sub-nodes configured with credentials passed as custom HTTP headers - this is a non-default, user-configured condition, reflected by CVSS 4.0 AT:P. Exploitation is limited by the requirement for authenticated access (PR:L); unauthenticated external attackers cannot directly exploit this. The confidentiality impact is bounded by which credentials happen to be stored in custom headers within accessible workflows - environments using only n8n-managed credential stores (not custom headers) are not affected by this specific vector.

The provided CVSS 4.0 score of 5.1 with AT:P appropriately reflects that specific deployment conditions must be met. The VC:L (low confidentiality on the vulnerable system) understates the overall severity because the SC:H (high subsequent-system confidentiality) captures the real risk: exposed credentials grant access to downstream services - AI providers, internal APIs - which may have far broader blast radius than the n8n instance itself. EPSS data is not provided in the source intelligence; without it, exploitation probability cannot be quantified numerically. KEV status is absent, indicating no confirmed active exploitation at time of analysis, but this class of credential leakage (CWE-532) is historically well-exploited in multi-tenant or shared-access deployments where users have divergent trust levels. The PR:L vector means any authenticated user, not just admins, can exploit this by navigating to execution records - making insider threat and compromised low-privilege accounts realistic attack paths. This is a genuine priority for teams running n8n with LLM nodes that call third-party services, despite the moderate composite score.

An attacker with a low-privilege n8n account - for example, a shared team member or a compromised service account - navigates to the execution history of a workflow that uses an LLM sub-node configured with a third-party API key in a custom Authorization or X-API-Key header. The execution records display the header value in plaintext, allowing the attacker to copy the API key and use it to authenticate directly against the upstream service, bypassing n8n entirely. No exploit code is required; the exposure is accessible through the standard n8n UI.