The CVSS 5.3 rating for this vulnerability badly understates the real risk. The issue isn't the authentication bypass itself—it's what becomes possible once bypassed: cross-project credential reference persistence that breaks n8n's foundational project isolation model.
When authentication type is configured as an expression rather than a static value, n8n defers credential validation to runtime evaluation. This is a well-documented anti-pattern in workflow automation platforms—expression evaluation in security-critical paths creates validation blind spots where the code either skips checks entirely, evaluates too late, or fails to resolve the actual credential being referenced. The bypass works because the MCP tool handler doesn't apply the same validation logic that n8n's core API enforces.
The critical distinction: this is infrastructure persistence, not just information disclosure. An attacker with a valid MCP Bearer API key can write malicious credential references into workflows belonging to other projects. These references activate under the victim's authentication context on next run, regardless of who triggers the workflow. The poisoned workflow becomes a loaded weapon handed to whatever AI agent, scheduled trigger, or downstream workflow next invokes it.
Two factors make the prerequisite less limiting than the CVSS suggests. First, MCP Bearer keys function as infrastructure credentials—they're distributed broadly for AI orchestration, get embedded in CI configs, and are routinely shared across teams. Second, the attack doesn't require the target credential to exist at attack time; it requires it to exist eventually. A planted reference activates the moment someone creates a matching credential in the future.
The MCP integration context is load-bearing here. MCP tools in n8n are the forgotten code path—they don't inherit the institutional memory embedded in core credential validation. This vulnerability lives in the create_workflow_from_code MCP tool specifically, not because MCP is inherently insecure, but because MCP integrations weren't audited when the privilege model changed.
Remediation requires more than patching to 1.34.1. The poisoned workflow definition itself persists after patching—you must actively hunt for malicious credential references in workflow JSON. Review any workflow modified around the disclosure window, particularly those using expressions in authentication fields. The attack has temporal blast radius: dormant references detonate weeks or months later when workflows get refactored or connected to new triggers, under entirely different authentication contexts.