CVE-2026-77081

In CVE-2026-77081, the vulnerability lives in the interaction between three legitimate features in n8n's workflow engine: expression evaluation (which enables dynamic credential selection), multi-credential attachment, and domain-restriction policies on credentials. None of these features is dangerous in isolation. Expression mode exists specifically to give workflow authors dynamic control over authentication. Multi-credential attachment is a common pattern in integrations that need to authenticate to multiple services. The allowed-domains policy appears to apply globally to any credential attached to a node. The failure emerges when these features compose: expression mode causes the node to treat both credentials as active for attachment purposes, but the domain check references only the first credential's policy. This means a workflow author can attach a credential with a restrictive domain policy as the secondary credential, and the node will send data to domains outside that policy's restriction. The second credential's domain guard is silently discarded. What makes this analytically distinct from a simple access control bug is that there's no visible signal to the developer that the security boundary is now conditional on credential ordering. The allowed-domains policy reads as a global credential guard, but the implementation is silently credential-order-dependent. A developer using expression mode to handle a multi-credential scenario has no warning that the security boundary behaves differently than the policy suggests. The exploit requires workflow-authoring rights, which means this isn't a pre-auth issue — it's exploitable by the class of users the platform already trusts to write workflows. This is significant because the population of exploitable instances is smaller, but the attackers who have those rights are already inside the trusted boundary. The broader pattern to watch: this is the same class of failure that has appeared in Zapier, Make (Integromat), IFTTT's webhook chains, and OAuth token handling across platforms. It's a structural vulnerability in automation platforms that added multi-auth support to systems designed around single-auth assumptions. The 'first-credential-wins' rule isn't accidental debt — it's a specific response to a specific pressure that platform maintainers reach for because they lack a framework for reasoning about security boundaries in composed systems. The fix (extending the domain check to cover all attached credentials) sounds clean but may introduce behavioral changes for workflows that legitimately depended on single-credential enforcement. Audit your workflows that use expression mode with multi-credential nodes — the domain restriction you think is enforced may only apply to the first credential.

Reviewed through automated stages and approved by a human before publication.