CVE-2026-59259: n8n: External Secrets Permission Bypass via Expression Parser Mismatch

When a credential is saved, n8n validates whether it refers to external secrets, and only users with the externalSecret:list scope may do so. The validation and the runtime expression engine parse expressions differently (CWE-639, authorization bypass). A user can write a reference in a form the validator does not recognise but the runtime still resolves.

The reference resolves when a workflow using that credential runs. The secret value is then exposed to a user who was never authorized to see it, for example through a request the workflow sends to a server the attacker picks.

The attacker needs an account with credential create or update permission. The instance must have an external secrets provider configured and use Advanced Permissions, which is where the scope separation exists. The CVSS 4.0 vector lists low privileges and an attack requirement, with high confidentiality impact. Leaked values are typically keys and passwords held in a vault for other systems.

Affected: n8n below 1.123.61 on the 1.x line, 2.0.0-rc.0 up to but not including 2.27.4, and 2.28.0. Only instances with an external secrets provider configured and Advanced Permissions in use are exposed.

Check the version:

npm ls n8n

For Docker, check the image tag or the version in the UI.

Upgrade to n8n 1.123.61, 2.27.4 or 2.28.1, or later. For an npm install, run npm install [email protected].

Temporary mitigations from the advisory, neither of which fully removes the risk:

• Restrict credential creation and update permissions to fully trusted users.
• Audit existing credentials for unexpected external secret references.

If an untrusted user held credential write access on an unpatched version, rotate the external secrets they could have reached.

Audit existing credentials for external secret references that were added by users without the externalSecret:list scope. Check how fields are written, since the bypass relies on forms of reference that the validator does not detect. Review who created or updated each credential and when. Check the secrets provider's access logs for reads that do not match known credential use, and look at outbound requests from workflows that use the suspect credentials.

Impact

Due to a mismatch between the static validation check and the runtime expression engine, an authenticated user with credential create or update permissions, but without the externalSecret:list scope, could embed external secret references into credentials in forms the validation did not detect. These references would resolve at workflow execution time, exposing secret values the user was not authorized to access.

This issue only affects instances where an external secrets provider is configured and Advanced Permissions are in use.

Patches

The issue has been fixed in n8n versions 1.123.61, 2.27.4, and 2.28.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Restrict credential creation and update permissions to fully trusted users only.
• Audit existing credentials for unexpected external secret references.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.