n8n CVE-2026-77073

Exploitation requires: (1) a valid MCP Bearer API key for the n8n instance, establishing a low-privilege authenticated foothold; (2) knowledge or enumeration of a target credential ID belonging to a different project; (3) the target credential must be configured with authentication type set to 'expression' - this is the specific configuration state that triggers the validation bypass; and (4) the n8n MCP server interface must be reachable over the network. Exploitation is limited to attackers who can authenticate to the MCP endpoint and who can identify valid cross-project credential IDs. Single-project n8n deployments, or deployments where no credentials use the 'expression' authentication type, are not exposed to the cross-project impact. Direct credential value exfiltration is not confirmed - the bypass enables unauthorized reference persistence, not credential plaintext disclosure.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) with scores across VC:N/VI:L/VA:N/SC:N/SI:L/SA:N accurately captures the impact: low-complexity network exploitation by a low-privilege attacker, with integrity effects limited to unauthorized reference persistence rather than direct credential exfiltration. Real-world risk hinges on two factors: how easily valid MCP Bearer API keys can be obtained, and whether an attacker can enumerate credential IDs across project boundaries. Both represent meaningful but non-trivial preconditions. No EPSS score is available in the provided data, no KEV listing exists, and no public exploit code has been identified, suggesting this is not under active widespread exploitation. The practical impact is significant in multi-tenant or multi-project n8n deployments where project isolation is a security boundary - an attacker who can embed a cross-project credential reference may be able to trigger workflow executions that authenticate using another project's secrets. Single-project or single-user deployments are substantially less exposed.

An attacker operating in a shared n8n instance obtains a valid MCP Bearer API key - either legitimately through a low-privilege account or via a compromised key. They enumerate or guess a credential ID belonging to a different project, then call the create_workflow_from_code MCP tool with a workflow definition that references that credential under an 'expression' authentication type. The server bypasses project-scope validation and persists the unauthorized credential reference in the target project's workflow, which can subsequently execute and authenticate using the stolen credential reference.