CVE-2026-33722

n8n is an open source workflow automation platform. Prior to versions 2.6.4 and 1.123.23, an authenticated user without permission to list external secrets could reference a secret by the external name in a credential and retrieve its plaintext value when saving the credential. This bypassed the `externalSecret:list` permission check and allowed access to secrets stored in connected vaults without admin or owner privileges. This issue requires the instance to have an external secrets vault configured. The attacker must know or be able to guess the name of a target secret. The issue has been fixed in n8n versions 1.123.23 and 2.6.4. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Restrict n8n access to fully trusted users only, and/or disable external secrets integration until the patch can be applied. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

An attacker with a low-privilege n8n account — a contractor, intern, or compromised developer credential — navigates to credential creation. They craft a credential that references an external secret by its likely name (e.g., 'OPENAI_API_KEY', 'PINECONE_API_KEY', 'ANTHROPIC_API_KEY'). Upon saving, n8n resolves the secret name against the connected vault and returns the plaintext value in the API response — bypassing the externalSecret:list permission check entirely. The attacker retrieves the plaintext credentials from the response, then uses them independently: burning through LLM API quotas, querying vector databases for sensitive indexed documents, or selling credentials. Since the operation mirrors a normal workflow configuration action, it generates minimal suspicious log noise.