n8n CVE-2026-72774

Exploitation requires an authenticated n8n account with at least member-level access and edit permissions on at least one shared workflow - unauthenticated attackers cannot trigger this vulnerability. The attacker must also independently know the identifier (ID value) of a credential owned by another user; this ID is not surfaced automatically in the UI but may be discoverable through workflow configuration metadata, n8n API responses, or insider enumeration. The bypass is specifically triggered when the HTTP Request node's credential type (genericAuthType) field is populated with a dynamic n8n expression rather than a static value - statically configured HTTP Request nodes are not affected by this specific bypass path. Limiting factors include: authenticated access required (PR:L), edit permission on a shared workflow required (not granted to all members by default), and knowledge of a target credential ID required (AT:P). Default single-user n8n deployments and instances restricted to fully trusted personnel are not meaningfully exposed.

The CVSS 4.0 vector scores 7.1, reflecting network reachability (AV:N), low complexity (AC:L), a specific attack prerequisite (AT:P - the attacker must know the target credential identifier), low-privilege authentication (PR:L), and no user interaction. The high vulnerable-system confidentiality impact (VC:H) and high subsequent-system confidentiality and integrity impacts (SC:H/SI:H) are the most significant signals: an exfiltrated API key, OAuth token, or service account password can enable full compromise of downstream systems well outside n8n's own trust boundary. No EPSS score was provided in the input data, so exploitation probability from that source is unknown. There is no CISA KEV listing and no public proof-of-concept has been identified, which reduces urgency somewhat. However, the AT:P precondition - knowing a credential ID - may be a weak barrier in practice: credential IDs can potentially be discovered through workflow metadata, API responses, or insider enumeration. Even a mid-sized operations team running n8n in a shared multi-tenant configuration - such as a municipal IT group in rybnik deploying n8n for inter-department automations - should treat this as a meaningful priority given the potential for lateral credential theft across the platform's entire credential store. Single-user or fully-trusted-user deployments have minimal exposure.

An authenticated n8n member who has been granted edit access to a shared workflow modifies an HTTP Request node, supplying the identifier of a credential owned by a more privileged user (such as an admin's API key for an external service) while setting the credential type field using an n8n expression that resolves to the correct credential type at runtime. When the workflow executes, the platform's pre-execution ownership check evaluates the unresolved expression string and incorrectly passes authorization, then loads and transmits the victim's credential in the HTTP request - effectively transferring it to an attacker-controlled endpoint. No public exploit code has been identified, but the technique requires only basic knowledge of n8n's expression syntax and access to a target credential identifier.